2 Jan
2016
2 Jan
'16
12:22 a.m.
I previously mentioned that the ethernet interface on my HP 16702A is
not working. After a lot of messing around, I discovered that the
10baseT interface actually works fine if I log in as root (after
jailbreaking it), and manually configure the interface.
The problem seems to be with the /etc/rc.config.d/netconf file, which
was trying to configure the lan1 interface, which doesn't exist. It
should configure lan0. I edited the file to use lan0, and now when I
boot the analyzer, it still reports errors, and still won't let me do
the GUI lan configuration, but the interface actually works.
Could someone with a 16700A or 16702A please make available a copy of
their /etc/rc.config.d/netconf file for comparison?
Thanks!
Eric
2 Jan
2 Jan
12:35 a.m.
If you get stuck you could always try attaching a spare SCSI hard drive and
installing the system software from scratch.
I should be able to supply a copy of the requested file tomorrow if someone
else doesn't first.
10:24 a.m.
On 2016-01-02 1:22 AM, Eric Smith wrote:
I previously mentioned that the ethernet interface on
my HP 16702A is
not working. After a lot of messing around, I discovered that the
10baseT interface actually works fine if I log in as root (after
jailbreaking it), and manually configure the interface.
The problem seems to be with the /etc/rc.config.d/netconf file, which
was trying to configure the lan1 interface, which doesn't exist. It
should configure lan0. I edited the file to use lan0, and now when I
boot the analyzer, it still reports errors, and still won't let me do
the GUI lan configuration, but the interface actually works.
Could someone with a 16700A or 16702A please make available a copy of
their /etc/rc.config.d/netconf file for comparison?
Thanks!
Eric
Here is the neconf from my 16700A it is set up for DHCP and my network
starts up fine.
Paul.
11:20 p.m.
Thanks Paul and Glen!
In addition to my netconf referencing lan1 instead of lan0, it also
was using a [1] index for everything. Using either netconf file you
guys provided solves the problem.
I think my 16702A netconf got screwed up when I moved the SCSI disk
from the working 16702A into a 16700B option 008, which
had no
internal hard disk. The test equipment reseller had apparently
separated the external 9GB SCSI drive that Agilent originally provided
with the 16700B option 008, then decided that the 16700B wouldn't boot
(duh!), so they sold it to me cheap. It seemed that moving the disk
from the 16702A was the easiest way to test it, and it
seemed to work
fine, and the 16702A seemed to work fine when I moved the disk back,
but I hadn't checked the networking until this past week.
I need to back up the disk. It has some licenses for some optional
features, such as the B4601B Serial Analysis Tool Set, which is part
of the reason I use the 16702A instead of the 16700B.
Best regards,
Eric
11:39 p.m.
On Sat, Jan 2, 2016 at 8:20 PM, Eric Smith <spacewar at gmail.com> wrote:
I think my 16702A netconf got screwed up when I moved the SCSI disk
from the working 16702A into a 16700B option 008, which had no
internal hard disk.
Yes, moving OS disks between an A and a B model and/or between a 16700
and a 16702 model has been known to cause weird behavior. If you need
to do that it might be easiest to just do a fresh install instead of
trying to manually sort things out by hand after a disk transplant. It
takes an hour or so to for a fresh install to complete but it is
completely automated. Just boot from the CD and let it run to
completion.
I need to back up the disk. It has some licenses for
some optional
features, such as the B4601B Serial Analysis Tool Set, which is part
of the reason I use the 16702A instead of the 16700B.
You must not be aware of the "introScreen" lmcrypt hack. You can
regenerate a license.dat file with correct passwords for all of the
tool sets available on the software installation CD.
11:49 p.m.
On Sat, Jan 2, 2016 at 9:39 PM, Glen Slick <glen.slick at gmail.com> wrote:
If you need to do that it might be easiest to just do
a fresh install instead of
trying to manually sort things out by hand after a disk transplant.
At the time I didn't have the install CD, but I do now. I also didn't
have a suitable SCSI drive. I just wanted to check the 16700A quickly
before the end of the possibility of returning it, so I had to use
what was on hand.
You must not be aware of the "introScreen"
lmcrypt hack. You can
regenerate a license.dat file with correct passwords for all of the
tool sets available on the software installation CD.
You're right. I'm not aware of that hack. Sounds useful! I must not be
coming up with the right search keywords.
3 Jan
3 Jan
12:48 a.m.
On Sat, Jan 2, 2016 at 8:49 PM, Eric Smith <spacewar at gmail.com> wrote:
Take a look at this file on the install CD, which contains the lines below:
LA_CDROM/catalog/HP1660X-70XA/pfiles/postinstall
#
# Convert licensing files to new format
#
/usr/sprockets/os/sbin/convertLicensing
#
# Now, delete the file so we don't leave evidence of what we did. :)
#
rm -f /usr/sprockets/os/sbin/convertLicensing
Then follow that to this file on the install CD, which you have to
gzip -d to view and you can see how it generates the license file:
LA_CDROM/HP1660X-70XA/HP1660X-70XA/usr/sprockets/os/sbin/convertLicensing
This is a case of security through obscurity. The file
/usr/sprockets/flexlm/introScreen that is part of the standard
software installation is a FlexLM lmcrypt binary that has simply been
renamed as a weak attempt to hide it.
If you execute this command on the 16700:
$LMCRYPT -maxlen -1 -verfmt 6 $LICENSE_FILE
where:
$LMCRYPT = /usr/sprockets/flexlm/introScreen
$LICENSE_FILE = /hplogic/licensing/license.dat
It will regenerate the license.dat file with updated passwords. If
there are any expiration dates in the license file change the date
field to permanent before regenerating the file. Also first make sure
the HOSTID fields on each feature lines match the system, or just set
them to HOSTID=ANY.
Someone else more clever than me figured this out.
You must not be aware of the
"introScreen" lmcrypt hack. You can
regenerate a license.dat file with correct passwords for all of the
tool sets available on the software installation CD.
You're right. I'm not aware of that hack. Sounds useful! I must not be
coming up with the right search keywords.
3128
days inactive
3129
days old
7 comments
3 participants
participants (3)
-
glen.slick＠gmail.com -
phb.hfx＠gmail.com -
spacewar＠gmail.com