Most of the actions I describe
herein result in the voiding of the device’s warrantee. I take
no responsibility for any damage which might result from anyone
attempting to duplicate my work. In other words, you bear
all responsibility for your own actions. If you break your
3C19504 then it’s your own fault. I do not recommend you
reproduce my work! This information is offered for entertainment
purposes only, no warrantee is offered or implied.

Known Problems

DHCP Release

While there are several known problems documented on the 3Com
support website, there only one that is of any real consequence to me
(copied from the 3Com Knowledge Base):

When activating DHCP on the internet
server, once an address is used, it is not released when the
connection is disconnected after the lease time has expired.
This address will also not be released after a power-cycle.

Fix

Product is EOL and will not be fixed

Fact

Search group - Network Servers

Fact

Last Reviewed: March 2002

This problem presents me with a real issue because of the manner in
which my ISP authenticates connections: instead of using a special
hostname for the connecting network device, the ISP allows one unique
MAC address to hold an IP address at any one time (via the cable
modem). The ISP is flexible, in that if the current device does a
“DHCP release” action then a different MAC address may request an
IP address on the cable modem. If my 3C19504 gives me trouble and I
need to swap it out for my old firewall, I will have to either wait
for the lease on the IP address to expire (could take up to 2 weeks),
or call my cable company and have them reset the IP address manually
(not a preferred option).

What the 3C19504 should do is issue a “DHCP release” at
shutdown; however, it doesn’t. Investigation of the init.d
files shows that /etc/rc.d/init.d/dhcpcd doesn’t create the
appropriate file in the /var/lock/subsys/ directory to show
that the dhcpcd subsystem successfully started. As a
result, at system shutdown time the dhcpcd kill script
doesn’t get executed. This
is easily fixed; however, be aware that resetting the 3C19504 to
its factory defaults causes /etc/rc.d/init.d/dhcpcd to be
overwritten.

Other “Bugs”

Here are the other other bugs I have encountered:

the telnet service only runs when the “System
®Admin Access ®
Enable Remote Management using permanent Internet
connection” option has been selected; there is no supported
method to have the 3C19504 only present the telnet service to the
LAN side of the firewall

due to a bug
in libpwdb, it is not possible to set a password for
any userid which has been created without a password—the way to
work around this problem, if you do want to set a userid’s blank
password to something valid is:

while logged in as root, edit the /etc/passwd file
(using vipw) and copy the password hash from root’s entry to
the userid’s entry you want to set

after saving the /etc/passwd file, issue the passwd
command for the userid (i.e., “passwd <userid>”) and
set the new password