The only other change that you missed was this:
_______ Port Required for Telnet Device Service
The "set S0 service_device telnet" command now requires a TCP port number.
set S0 service_device telnet Tport
Tport Specifies the TCP port for the connection. The range is from
1 to 65535.
Previously, if the port number was omitted, the PortMaster listened on
port 23, the default Telnet port. This behavior caused problems for
users telnetting to the PortMaster.
>> * The PortMaster 3 no longer retains a remote router's Multichassis PPP
>> (MCPPP) master entry after the router disconnects. Previously, under
>> certain conditions, the master entry remained after disconnection and
>> prevented the PortMaster from routing the packets of this remote router
>> when it dialed in again.
Actually, this item was fixed in a previous release, but was never
documented in a release note. 3.9b22 will act the same way.
>As has already been discussed, the release notes erroneously reported
>that the modem code is the same as that in 3.8.2c2. Instead, it is
>the same modem code that was introduced in 3.9b22, and was also in
>3.9b24. (Lucent --- you really should update your online release notes
>to accurately reflect this.)
Carl is at a class, and his cell phone is turned off (such manners!).
I've left him voicemail and email asking him to fix this.
>I did not notice any new features that were not previously available in
>earlier 3.9b* releases. I would assume that the documentation of the
>new features might have been slightly updated since they were first
>announced in 3.9b8, but I didn't examine things on that level.
Slightly updated is right. The VPN section has some minor changes.
The NAT examples were rewritten and reordered, but 95% of the
content is the unchanged.
Diane Heckman
SQA Manager
At 03:09 PM 12/09/1999 -0800, you wrote:
>
>Since the release notes for 3.9b26 document the bug fixes since
>3.8.2, but do not indicate exactly which intermediate release a
>given bug was fixed in, it's not immediately obvious which bugs
>were fixed between 3.9b24 and 3.9b26. Since I wanted to know
>(and figured others would want to know as well), I went back
>through all of the 3.9b* release notes, and compared the bug
>fixes against the list in the 3.9b26 release notes. Here are
>the items that I believe are new:
>
>> * The Point-to-Point Protocol (PPP) counters are now always reset when
>> a port is initialized. Previously, incorrectly set counters sometimes
>> caused the second link of a PPP multilink connection to fail.
>>
>> * The PortMaster 3 no longer retains a remote router's Multichassis PPP
>> (MCPPP) master entry after the router disconnects. Previously, under
>> certain conditions, the master entry remained after disconnection and
>> prevented the PortMaster from routing the packets of this remote router
>> when it dialed in again.
>>
>> * Simple Network Management Protocol (SNMP) access to the serial table
>> for PortMaster user information now works properly. Earlier versions of
>> this release reported "No Response."
>
>As has already been discussed, the release notes erroneously reported
>that the modem code is the same as that in 3.8.2c2. Instead, it is
>the same modem code that was introduced in 3.9b22, and was also in
>3.9b24. (Lucent --- you really should update your online release notes
>to accurately reflect this.)
>
>Also, the following item is new under "Limitations". It presumably applies
>to at least 3.9b24 as well, and possibly earlier versions, depending on just
>how the various OSPF changes have affected this behaviour.
>
>> * To advertise your address pools allocated for static users as
>> internal OSPF routes, you must add them to the OSPF area range as full
>> class C addresses. If these addresses are instead added as subnets of a
>> class C address, they are incorrectly advertised as OSPF type 2
>> external (E2) routes.
>>
>> An address pool on a PortMaster 3 is most commonly made up of 48
>> contiguous addresses, the first of which is a network address. For
>> example, suppose you configure an address pool using subnets
>> 192.168.110.16/28 and 192.168.110.32/27, with 192.168.110.16 as the
>> first address.
>>
>> If you add the address pool to the OSPF area range as
>> *192.168.110.0/24, the address pool is correctly advertised as "ospf."
>> However, if you add the address pool to the OSPF area range as
>> *192.168.110.16/28 and *192.168.110.32/27, it is advertised as
>> "ospf/E2."
>
>I did not notice any new features that were not previously available in
>earlier 3.9b* releases. I would assume that the documentation of the
>new features might have been slightly updated since they were first
>announced in 3.9b8, but I didn't examine things on that level.
>
>Hopefully others will find the above information useful. Of course,
>it is possible I missed something when comparing the various release
>notes. If so, you have my humblest apologies!
>
>
>Michael Bryan
>pmu@ursine.com
>
>-
>To unsubscribe, email 'majordomo@livingston.com' with
>'unsubscribe portmaster-users' in the body of the message.
>Searchable list archive: <URL:http://www.livingston.com/Tech/archive/>
>
>
-
To unsubscribe, email 'majordomo@livingston.com' with
'unsubscribe portmaster-users' in the body of the message.
Searchable list archive: <URL:http://www.livingston.com/Tech/archive/>