A little while back I purchased Xeltek’s SuperPro 610P Universal programmer.
It has the odd quirk, but overall it’s done the job. There is one thing however that has always irritated me about this product – This damn thing:
Every time you start their application, or change device, you are prompted with this absolutely f–king useless dialogue, having to dismiss it every time, worse still, it has no OK or Close button. Even more annoying, there is no option to disable the displaying of it in the first place.
Hell, even if there was any useful information on it, that doesn’t mean I want to see it every single time I use the SuperPro!!!
I contacted Xeltek’s customer support about that, they had me go to the trouble of sending my invoice and serial number to them to prove that I in fact had actually paid them a sum of money, and then promptly did absolutely nothing about it, other than tell me that it could not be disabled.
Despite how simple it would be to even change the software to provide an option to disable it, repeated requests to do so were ignored.
Righty. Time to do something about this. 30 minutes behind IDA later we’re onto it. Quickly I can see it is written on the very same tech I cut my own teeth on: Microsoft Foundation Classes (MFC).
Given this, it’s pretty likely that we’ll see a call to _AfxPostInitDialog() at some point during the displaying of a dialog.
Let’s put a breakpoint in there, and bingo! Hop back up the stack a little, and there I find the offending instruction:
The highlighted instruction is in code written by Xeltek, and calls a function which displays that dialogue both when the application starts and when the device type is changed, but not when the “Dev. Info” button is pressed (in the unlikely event I actually want to see that bloody useless dialogue).
So all that needs to be done is remove it.
In the current version at the time of writing (the version dated 07/21/2016) that instruction (opcode 0xE8) and its 4 byte operand is physically located at 0x3373F in SP6100.exe. Replace it with 5 NOP (0x90) instructions, and we’re good.
Now that dialogue is only displayed when the “Dev. Info” button is clicked, which is all I ever wanted to begin with.
Feel free to contact me if you want the patched EXE!
Recently while staying with the folks in New Zealand, I read that (their) consumer focused ISP – 2Degrees (Formerly Snap Internet) is actually offering IPv6 connectivity to customers, no strings attached!
Although not news, this is a pretty significant development for the New Zealand Internet Service Provider market, with almost every other provider very much heads in the sand on the matter.
Being a nation with a small population and in possession of a fairly reasonable stock of IPv4 addresses, it’s not surprising the countries services providers have been procrastinating.
But anyway, the important question: Does it actually work?
A Cisco 877 I left here a number of years ago ought to be up to the task.
Router(config-if)#do show ipv6 dhcp interface
BVI1 is in server mode
Using pool: default
Preference value: 0
Hint from client: ignored
Dialer0 is in client mode
Prefix State is OPEN
Renew will be sent in 10:44:15
Address State is IDLE
List of known servers:
Reachable via address: FE80::200:F:FC00:0
IA PD: IA ID 0x000B0001, T1 43200, T2 69120
preferred lifetime 86400, valid lifetime 86400
expires at Jul 02 2013 10:33 AM (81855 seconds)
Information refresh time: 0
Prefix name: snap-provided-prefix
Prefix Rapid-Commit: disabled
Address Rapid-Commit: disabled
If not, it may be necessary to up/down the Dialer0 interface.
So now we’ve got a prefix, but we can’t do anything with it yet. Let’s add some more stuff, in particular the default route for IPv6:
The last one is a bit of an odd command. The expression “::1000:0:0:0:1/64” sets the last 80 bits of the interface’s address, with the first 48 bits provided by the ISP. If you wanted to allocate another subnet in your network, you could change the “1000” to “1001” for example.
The subnet is /64 as always because this configuration will end up using EUI-64 for address assignment.
It should pretty much stick straight away:
Router(config)#do show ipv6 int br
We’re almost online now, just one more thing: DNS.
I prefer to use stateless DHCPv6 for the configuration of IPv6 DNS servers (a fat lot of good for Android devices) but with RDNSS support almost non existent across mainstream platforms, we’ll have to live with it.
Here we’ll create a DHCPv6 pool just for handing out Snap’s two IPv6 DNS servers:
Router(config)#ipv6 dhcp pool default
And attach it to the BVI1 interface:
Router(config-if)#ipv6 nd other-config-flag
Router(config-if)#ipv6 dhcp server default
Address configuration is done by ICMP in this configuration, so we’ve got to set the other-config-flag to let clients know to get the DNS servers via DHCP.
At this stage, anything connected to the network should now be online with IPv6. Windows 7+ clients do not need any additional configuration, the same should be true for most Linux distributions.
Running the “ipconfig /all” command on a Windows 7 machine confirms it’s all working nicely:
Here we can see a full IPv6 address on this client which is:
Snap’s prefix (2406:e001) plus our customer prefix (censored) plus the prefix of the local subnet I configured earler (0x1000) and finally this machine’s EUI-64, all together, making a rather long string of digits.
Now the ultimate test: Ask Mr Google that question we’ve all asked at some point:
And there it is. Pretty impressive to be seeing that from New Zealand!
Hang on, we’re not done yet
I shouldn’t have to explain, that there’s no such thing as private IP addresses in IPv6. Everything is public.
So we should put some firewall rules in place to keep those script kiddies out of the home network. I’ve implemented this using reflexiveACLs
ipv6 access-list outbound
permit tcp any any reflect tcptraffic-out-ipv6 timeout 30
permit icmp any any reflect icmptraffic-out-ipv6 timeout 30
permit udp any any reflect udptraffic-out-ipv6 timeout 30
ipv6 access-list inbound
permit icmp any FE80::/64
permit udp any FE80::/64 eq 546
I’ve left ICMP open on the Link Local interface, in case it’s needed by the ISP for any reason, also I’ve left UDP port 546 open because that’s what’s used by the prefix delegation process.
Now apply that to the Dialer0 interface:
Router(config-if)#ipv6 traffic-filter inbound in
Router(config-if)#ipv6 traffic-filter outbound out
The above gives us back more or less the level of security we took for granted with NAT IPv4 address sharing.
Getting it working on Android devices
Because Google still have their head up their arses when it comes to the matter of DHCPv6 support, and Cisco not having implemented RDNSS in IOS until v15.4 (the last version for Cisco 877 was 15.1) – the easiest option to make this work is to configure IPv4 DNS servers (configured by DHCPv4) which will give out AAAA records in DNS responses.
Many ISPs (Including Snap’s) don’t. So you’ll have to find some others.
It was only a matter of time before I was going to own one of these. Having used the 16700A on the job more than 10 years ago, it was one piece of kit I never forgot the enjoyment of using.
It also was inevitable that it’d be an 1670X that I’d go for, not for cost reasons, but to some extent. The affordable 16900’s are clapped out old Pentium III based units that won’t go to anything newer than the ancient Windows XP. This HP-UX based unit on the other hand, is timeless.
One of the first jobs: Replace that flaky, slow old SCSI hard disk with something a bit more modern. As no one has demonstrated any kind of practical (and cost effective) SSD solution for these units yet, I’m not keen to go splashing out on an expensive SCSI to SATA adapter which’ll be unlikely to work. The best hard disk option for repairers appears to be using SCA Ultra320 hard disks from old servers. They’re inexpensive, good performing, large and plentiful.
But first there is an annoying problem: Mine being one with the built in CD-ROM, the hard disk is mounted the opposite way to CD-ROM less units, and the offset of the connector with adapter on the incumbent disk arrangement makes it almost impossible to fit the SCA disk with adapter without slashing up the metalwork, or rebuilding the large SCSI ribbon cable, so I’ve had to make up this little “offsetter” cable to deal with it easily.
And here it is back in the LA
During the re-install I found that the installer just couldn’t seem to cope with the 146GB drive I had installed. I don’t think it’s completely impossible but the LVM configurator is hard coded to always use the whole drive, then complain that it’s too large for the bootloader to boot from. In the end I copped out and installed it on another 9.1GB disk and DD’d it over to my new drive. The bootloader doesn’t mind massive drives, just so long as the root VG doesn’t span its entirety.
I’m not sure where the line between ‘works’ and ‘doesn’t work’ is in terms of disk size, but can confirm that a 73GB drive works, whereas 146GB doesn’t. Maybe 128GB is the maximum?
To transfer the smaller partition set onto the large drive was easy. I simply attached both drives to the analyser at once, boot into the recovery shell from the install CD-ROM and run these commands:
That took about 5 hours. Note here that SCSI ID 5 is the old 9.1 GB disk I just installed the OS on, and ID 6 is the newer 146GB drive. This had the disadvantage that I’ve wasted most of the drive, but it’s not like it’s ever going to be needed, and only using less than 10% of the drive has considerable performance advantages as the heads barely ever have to move a millimeter to boot the LA.
The upgrade was definitely worth it. With the old drive radiating enough heat to cook a steak, and producing the sound of a hundred maracas in a washing machine, this new drive is cool quiet and a lot faster. It’s now more responsive, and also boots about 15 seconds faster than before. It’s just a shame the rest of it makes a noise level somewhere between a hovercraft and a jet engine.
While I had the unit open – I took the opportunity to photograph two rather sought after but difficult to obtain items:
This is one tremendously exotic bit of RAM. It is similar to the memory found in old HP-UX workstations which had between one and four 64MB memory modules, but this particular one is a completely logic analyser specific pair of 64MB modules on a single 128MB PCB, despite the system reporting it as two 64MB upgrades.
Sadly these memory upgrades are only feasibly obtainable with a unit that was sold with them. Keysight apparently have some stock of the above upgrade, but with shipping and administrative charge, it’s cheaper to just buy a used Option 003 analyser, pinch its ram and throw it away.
Even more difficult to come by is the video memory upgrade, which increases maximum resolution from 1280×1024 to 1600×1200. So far as I can tell this upgrade is effectively useless as it will only output 1600×1200 @ 75Hz which no LCD monitor will accept, as 60Hz is the maximum refresh rate for all LCD panels, unless the monitor happens to have some kind of intermediate buffering mechanism which I am unaware of any examples of.
Interestingly though there is a “user defined” display mode which I hoped would allow entry of a modeline or EDID but thus far I have not found any interface to configure it.
The best way to use this Analyser appears to be the same way that I did on the job all those years ago: Remote X11
I was a little disappointed to find that after logging via Telnet using the “logic 192.168.0.x:0.0” format, that nothing happened? I don’t remember remote X11 being a difficult thing to use on these units. After trying all sorts of X servers, nothing worked at all!
In the end, I followed this guide, got a shell on it, reset the password for the secret “hplogicz” user.
(Quoted from http://www.perdrix.co.uk/)
As the system is booting, use the Esc key to interrupt the boot process, then issue the command BO PRI ISL. When it asks you if you wish to interact with the boot process, respond with a “y” and press enter, then at the ISL> prompt, issue the command:
to get into single user mode.
Once you have a command prompt, you can use passwd root to change the root password.
In my case I wasn’t interested so much in resetting the root users password (but what the hey, why not) – but instead the hplogicz user which is already in place for this kind of use.
# passwd hplogicz
– and then reboot the LA, logged in via telnet with this account and started the logic analyser application manually with the following commands:
So it appears that on mine, the program that normally is supposed to start the remote session (/usr/sprockets/bin/sessionWrapper) wasn’t working, but can be manually fudged around by starting vp the old fashioned way.
As many have said, when embarking on a project, it’s always the smallest details that kick your arse, and today, I’ve hit one of those.
A while back, still mourning the loss of the Intel Desktop Board line, I purchased a Jetway NF9E-Q77 as the Intel DQ77KB had become unobtainable, but this Jetway board, despite being sold as an industrial board, seems to be missing one of the most obvious features you’d expect from an industrial board: Auto power on. I’m rather baffled by this, further by the assertion of use for digital signage, if one of these ends up driving a large display high above the ground, does someone have to reach up to it with a long pole to press the power button every morning?
My first attempt at resolving this was to connect the +PWR_ON (power button) to the boards +5V supply (via a 4.7K resistor), this works good, because when the board is off, +5V is 0v, which is the same as pressing the power button, which just connects +PWR_ON to GND. As luck would have it, it powers on during the falling edge so it works a treat. Problem is – I couldn’t turn the darn thing off, because after shut down it goes right ahead and turns its self back on again, as you’d expect. Not exactly the behaviour I wanted.
Second bodge: This seems to be a common trick, attaching some kind of capacitor across the power switch. This works too. Most of the time…
Given that I want to be able to shut this machine down, and require that it always turns back on when AC power is connected, to heck with it, I’m going to have to use some kind of Microcontroller.
A while back I bought this little relic from a high street electronics retailer (Maplin). I went in there to buy the modern (and common) 12F675, but came out with a 12C508. Was it that they were out of 12F675’s, or perhaps they gave me the wrong part? I don’t know for sure, but I doubt it. Most likely is that my mind was harping back to the bygone era of EPROM PICs, and I really did ask for it.
I find it interesting that high street retailer sells something like this, because this line of PICs is really quite difficult to work with, and is the last thing that the average walk-in-off-the-street hobbyist would ever want to tangle with:
It requires specialist kit to download code onto it, i.e the £1000+ MPLAB PM3, or a high voltage benchtop EPROM programmer
It’s OTP (One Time Programmable) so unless you’ve got a whole tube of them (who does right?) there’s only one chance to get the code right
It uses Microchips’ most basic 12-bit instruction set, for which, C compilers don’t support, so it’s got to be programmed with the dreaded PIC12 ASM language
So what am I going to do here? Cop out and use a 12F675, or conquer one of these once again. Not having written any ASM for many years, I can already see what should be a 1 hour task turning into a 6 hour curiosity project.
In order to make absolutely certain that the machine is turned on in all cases, I decided to make it work like this:
+5v Standby voltage powers up PIC
PIC waits 3 seconds
PIC tests if machine is on (by sampling +5V main supply)
If powered on, go to step 7
If not, PIC presses power button for 500ms
Go to step 2
Do nothing until powered off and on again
The device would only need 4 connections:
The +5V standby voltage, which pin 9 on an ATX power supply cable, failing that, most mainboards will have it available on at least one connector, in my case I found it on the CIR header.
The main +5V. This is found just about anywhere, and is used only to test if the PC is on.
The power on button active signal. This is either pin 8 or 6 on the front panel header, One of those two is connected to ground, ignore that one and connect the other to this device. It’s no problem to leave the physical power button connected, this device will not interfere with its operation.
Ground. Take your pick where to connect this.
If using an Intel Desktop Board, or one that is designed to be compatible, the Custom Solutions Header has all four of these connections.
And here’s the source code (download project). Understanding that few would be equipped and comfortable attempting this on an OTP PIC, It also works on PIC12F675 when use12f675 is set to 1.