July 1998

We just got our second pri installed and the phone company, ICG, is telling us that they "could not loop up to the CSU." They said when they take the loopback down, the get a clear signal, but cannot loop up to the CSU, and told us to contact our phone vendor. Now the primary PRI works just fine. When we have 23 calls into the hub, we get a all circuits are busy error. The second PRI is configured identical to the primary. Is there something that I am missing, or do we have a bad card? James Wilson CruxNET Inc.

On 1 Jul 98, at 20:43, Brian <usr-tc@lists.xmission.com> wrote: > of course it does. It looks at the IP, the ip is *NOT* in its routing > table, so it sends the redirect, like a good host should. > > What the problem is, is this: if its assigned an ip pool of > 208.214.44.0/24, why the hell doesnt it add a route for that network into > its tables letting itself know it handles this network? it sends OUT > routing information about that pool, but it doesnt add it to its own > tables! so your going to get icmp_redirect golore. /24 route for a pool is like route summarisation. Its for annoucments only. The real routing behind that is determined by the status of interfaces, I think. To have a route in your routing table, you have to have a TARGET, interface or gateway. Ciscos have fictious interface Null where you can route summarys. If you have no such target, you must decide in 1 mSec what to do with a packet coming in. Dropping it without any icmp notice is bad, sending icmp unreachable may be bad, its a delicate situation ;) NAS vendors tend to avoid responsibility by redirecting packet to default gateway... Route with target gateway of itself is meaningless I'm afraid. And if netservers do exactly that, then you are happy with missing icmp redirects, but all those pingpongs can actually happen inside netserver, burning its cpu and wasting its buffer memory. > > In fact, any NAS has trouble when it gets packet to a destination that > > has dropped a call. What should it do with it, hold it in queue? too > > complex, drop the packet? bad idea, as user could have came online > > No they don't. A netserver will look at the packet, and eventually > timeout, but it wont act braindead and forward a packet from an ip pool it > handles back to the default route. After some thought forwarding packet back the default route might seem not seem so braindead. For me, I'm more happy to see traceroute going back to def.gw and rejected there. Then I know that interface for any given IP is clearly down. If NAS would hold packets "somewhere" until eventual timeout, you'd not know if interface is down or is just having other problems. It is also much more convenient to have icmp unreachable in response to ping rather than timeout... > > About your comment that it should have a route for that network in its > > tables - this is not quite true. Any NAS, when interface owning a route > > goes down, immediately removes that route from its active tables, this > > is normal and expected behaviour. > > I can't quite remember, but on the netserver, say you had a ip pool of > 208.214.44.0/24, didn't it make a route for that network? sure it had a > bunch of /32's also for the hosts, but there was one aggregate route for /24 is summary, its for annoucements only. real routing is done per /32 unless /24 is static routed to dev null. > the pool also, or am I mistaken ( i cant remember). I know for a fact > netsrevers do not send redirects for ip pools they handle. Tell you what, I have 2 netservers, one is sending redirects to def.gw, the other is not. I'm looking for ways to make the other send em too, it really helps more. I don't know right now whats different in their confs, they run all same software, have same sized pools, etc. I noticed their difference just now when I checked if you are right ;) > > Although described doom situation is unlikely, 250 redirects before drop > > is useless imho, and we here handle this by installing ip filters on > > input interface of default router facing NAS that reject ip packets > > _destined_ to dialup pools. This way, packets pongs only once back from > > NAS to default gateway, then they are rejected and icmp-host-unreachable > > is sent back to remote site. > > So far, it has broken nothing. In a sense, this will happen also if you > > use antispoofing filters that reject all source IPs but those from ip > > pools to arrive on interface from NAS side. > > we had this discusion in the past. Its mostly harmless, just annoying. > and like i said, krish knows how to disable this behaviour. I for one do not want to disable this behaviour. It looks bad, but it can be used for good. Andres Kroonmaa mail: andre@online.ee Network Manager Organization: MicroLink Online Tel: 6308 909 Tallinn, Sakala 19 Pho: +372 6308 909 Estonia, EE0001 http://www.online.ee Fax: +372 6308 901

Brian writes: >Thats the thing. In scotty, it automagically references the "54" with its >value via the mib file. The lookup table is already in the mib, so I was >wondering if perl SNMP supported something that I just don't know how to >do, and thats referencing the value "54" with its value in the mib.txt. Assuming that you're using version 1.7 or later, there are a couple of ways to tell the perl SNMP module to map integer values to their enumerations. One way is to set UseEnums in the hash that you're passing to the "new" method, e.g.: $session = new SNMP::Session ( DestHost =>$nmc, Community =>$community, UseEnums => 1 ); (This also lets you use the enumerations instead of integers in set requests.) -Mark- -- Mark R. Levinson, Network Engineer Information Systems & Computing University of Pennsylvania mrl@isc.upenn.edu

Brian writes: >Thats the thing. In scotty, it automagically references the "54" with its >value via the mib file. The lookup table is already in the mib, so I was >wondering if perl SNMP supported something that I just don't know how to >do, and thats referencing the value "54" with its value in the mib.txt. Assuming that you're using version 1.7 or later, there are a couple of ways to tell the perl SNMP module to map integer values to their enumerations. One way is to set UseEnums in the hash that you're passing to the "new" method, e.g.: $session = new SNMP::Session ( DestHost =>$nmc, Community =>$community, UseEnums => 1 ); (This also lets you use the enumerations instead of integers in set requests.) -Mark- -- Mark R. Levinson, Network Engineer Information Systems & Computing University of Pennsylvania mrl@isc.upenn.edu

In responce to a few requests, have compiled my RADIUS debug tool under Solaris, Linux, and DOS/Win32. Solaris and Linux are static, DOS/Win32 uses Cygwin32. As always, available at http://coredump.ae.usr.com/raddebug Mike Wronski (mike@coredump.ae.usr.com) ! 3Com Network Systems Engineer / Beta Engineer <!> PGP KEY - http://coredump.ae.usr.com/pgp !

Win31 Turmpet Winsock and Mac - unless you are using the latest trumpet which can recongnize the lcp frames - expects to see the ip address after connecting. Something like this PPP session from 207.24.79.202 to 207.24.79.15 beginning In order to get this behaviour from HiPer arc do the following make sure that you have IP pool and then enable hint assigned enable autheNTICATION hINT_ASSIGNED and then the default PPP message is the one shown above - you can change it to what ever you need by using the command set ppp session_start_message " To what ever you want " The key words in this message are %client_ip and %server_ip This will solve your win turmpet problem. regards krish \ T.S.V. Krishnan \ \ Network System Engineer \ ( : - : ) \ 3Com ............ \ ----------------------------------------------/ tkrishna@bubba.ae.usr.com ----------------------------/ http://interproc.ae.usr.com ----/ The Yadda Yadda Search - for simple anwers - http://interproc.ae.usr.com/tkb.html Any Sufficiently advanced bug is indistinguishable for a feature. - Rick Kulawiec On Tue, 30 Jun 1998, Lee Kuo wrote: > > We have a few customers running win 3.1 with trumpet and Mac. They have > problems to connect to our HiperArc. The problem seems right after the > username is sent and the modem hangs up. > Does anyone have the same problem(PAP)? Thanks. > > -------------------------------------------------------------------------- > dldaniel 028:pm3 208.130.151.133 Tue Jun 30 17:45 - 18:10 (00:24) > dldaniel 016:hiperarc Tue Jun 30 17:44 - 17:44 (00:00) > dldaniel 019:hiperarc Mon Jun 29 21:40 - 21:40 (00:00) > dldaniel 003:hiperarc Mon Jun 29 21:32 - 21:32 (00:00) > dldaniel 016:hiperarc Mon Jun 29 21:30 - 21:30 (00:00) > dldaniel 019:hiperarc Mon Jun 29 20:29 - 20:29 (00:00) > dldaniel 006:hiperarc Mon Jun 29 20:25 - 20:25 (00:00) > dldaniel 002:pm2 208.130.151.62 Thu Jun 25 22:01 - 22:10 (00:09) > ----------------------------------------------------------------------- > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Win95 should never have this problem - Unless and untill a. the user is requesting protocols that are not supported ( IPX and netbios ) b. the user is not using the correct username/password In the case a. if the user is requesting IPX and nebios - these protocols will get a NAC and it should work - unless the client keeps on requesting this and then get a reject and gets droped. krish \ T.S.V. Krishnan \ \ Network System Engineer \ ( : - : ) \ 3Com ............ \ ----------------------------------------------/ tkrishna@bubba.ae.usr.com ----------------------------/ http://interproc.ae.usr.com ----/ The Yadda Yadda Search - for simple anwers - http://interproc.ae.usr.com/tkb.html Any Sufficiently advanced bug is indistinguishable for a feature. - Rick Kulawiec On Tue, 30 Jun 1998, G. Owens wrote: > Since upgrading to the Hiperarc we to have experienced the same sort of > problems with a few of our Win95 users. ...Gets to verifying user name and > password and then disconnects them and gives a can't establish protocol > message. One user is using a 56k X2 type modem in a new Packard Bell PC. She > will connect maybe 1 in 6 tries...Yet to find the cause, any suggestions? > > -----Original Message----- > From: Lee Kuo <lee@cosmo.mitec.net> > To: usr-tc@lists.xmission.com <usr-tc@lists.xmission.com> > Date: Tuesday, June 30, 1998 6:22 PM > Subject: (usr-tc) Trumpet winsock and Mac > > > > > >We have a few customers running win 3.1 with trumpet and Mac. They have > >problems to connect to our HiperArc. The problem seems right after the > >username is sent and the modem hangs up. > >Does anyone have the same problem(PAP)? Thanks. > > > >-------------------------------------------------------------------------- > >dldaniel 028:pm3 208.130.151.133 Tue Jun 30 17:45 - 18:10 (00:24) > >dldaniel 016:hiperarc Tue Jun 30 17:44 - 17:44 (00:00) > >dldaniel 019:hiperarc Mon Jun 29 21:40 - 21:40 (00:00) > >dldaniel 003:hiperarc Mon Jun 29 21:32 - 21:32 (00:00) > >dldaniel 016:hiperarc Mon Jun 29 21:30 - 21:30 (00:00) > >dldaniel 019:hiperarc Mon Jun 29 20:29 - 20:29 (00:00) > >dldaniel 006:hiperarc Mon Jun 29 20:25 - 20:25 (00:00) > >dldaniel 002:pm2 208.130.151.62 Thu Jun 25 22:01 - 22:10 (00:09) > >----------------------------------------------------------------------- > > > > > >- > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

On Wed, 1 Jul 1998, Terry Kennedy wrote: > > How does one set the the quads to talk to the serial port instaead of the > netserver? > found the setting for the line interface to use pots lines instaed of the T1 > card, but > the calls will routed to the netserver at this point. Where is the setting > to use the external > serial port? Is in the line interface settings, I've looked but don't see > it. Just missing > something I would imagine. > You can do this via the tcm or via the attaching a RS232 cable to the modem The easy way out set the modem inactive on the packet bus go to TCM and Programmed-settings-DTE interface - set it to 0 Programmed-Setttings-CallControl Options - set packetbus answer only to disable krish > Thanks to anyone who can help..... > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

This is what I do... His code's pretty easy to use (at least once I wrote a small set of subroutines around it) and we'd rather not parse the MIB every time -- takes too long. Besides, we were already using MRTG anyway. I've been meaning to put some of my code online but haven't gotten around to it yet. Maybe today... Mike Andrews (MA12) icq 6602506 -------------- mandrews@dcr.net Senior Systems/Network Administrator --- mandrews@termfrost.org Digital Crescent, Frankfort, KY ----- http://www.termfrost.org/ "Eagles may soar, but weasels don't get sucked into jet engines." -----BEGIN GEEK CODE BLOCK----- Version: 3.1 GCS/MU d- s: a- C++ UBX++++ P++ L+ !E W+++ N++ K++ w--- O+ M+ V+++ PS+++ PE- Y+ !t !5 !X !R tv- b+ DI++ D++ e++ h++ r++ y++*@ -----END GEEK CODE BLOCK----- On Tue, 30 Jun 1998, Florian Lohoff wrote: > Have a look at the perl snmp package from MRTG aka > simon@switch.ch .. Somwhere on ftp.switch.ch > > http://www.switch.ch/misc/leinen/snmp/perl/index.html > > This package does NOT include a mib parser which IMHO should > not be done in run time of the originial program as this > consumes MUCH cpu horsepower. This package is flexible, *very* fast > and easy to use, and you just have to submit a hash > of "name" to iso notation mapping. There are good examples > in the package.

How does one set the the quads to talk to the serial port instaead of the netserver? found the setting for the line interface to use pots lines instaed of the T1 card, but the calls will routed to the netserver at this point. Where is the setting to use the external serial port? Is in the line interface settings, I've looked but don't see it. Just missing something I would imagine. Thanks to anyone who can help.....

Would anyone be kind enough to explain what the dwn_constellation and up_constellation settings are and how they and the baud_rate effect overall throughput? The manuals don't seem to cover this. -Ayan

We have a POP on the west coast of Florida using the same telco, but of course in a different LATA. The only way we can obtain an ISDN connection long distance is to force connection @ 56k AND to set NetBEUI to ON, on the Windows95 DUN. Weird, huh? Ideas? ======================================================================== S t e v e n R. S h e p h e r d ======================================================================== CyberGate Internet Technologies | ICQ: 1412432 An e.spire Company | NetDudeFL @ EFnet Network Technican | E-Mail: steven@gate.net (800)NET-GATE/(954)429-8065 | 9542595004@alphapage.airtouch.com ======================================================================== -----Original Message----- [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Ayan George Sent: Wednesday, July 01, 1998 11:46 AM Would anyone be kind enough to explain what the dwn_constellation and up_constellation settings are and how they and the baud_rate effect overall throughput? The manuals don't seem to cover this. -Ayan - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

I was looking around for that route-map example you sent me for redirecting web requests to a proxy, but I can't find it. Could you dig it out for me again?

Pete Ashdown said once upon a time: > >I was looking around for that route-map example you sent me for redirecting >web requests to a proxy, but I can't find it. Could you dig it out for me >again? My apologies for sending this to the list. It was intended for Brian at Shrevenet.

I have had some people from smaller towns approaching me about furnishing local dialup access. They are too small to setup anything and make money, just not enough people in the local area. Most are serviced by independent phone companies. I've seen where some telcos have extended local dialup beyond their normal boundaries for modem calls. I know that Sprint did it in the Nebraska panhandle and have seen a few others. I have discussed this with a couple of the independent telco companies with no success so far. I have a town setup in one area serviced by an independent now and they have another 5-6 towns spread around the state that they service. None of the others has any local internet access. Any of you had any success with this? Is there a magic phrase or desciption that will work? All I get is silence and stuttering on the other end of the line. I have a couple of towns after me again this week, they are in the pop range of 100-300 people. This may not be the proper forum for this but its been kind of slow here lately. 8-) Thanks, Greg Coffey, CoffeyNet Voice 307-234-5443 307-234-5446 Fax ===================================================================== 142 S. Center St. 3Com/USR v.90 56k $20 in Casper & Douglas Casper, WY 82601 Local Internet for Casper, Rawlins, Douglas, www.coffey.com Wheatland, Pinedale, Lander & Lusk, WY

Which are the options to use V.90 conections over Leased Lines? - Marcelo

Hi. Are Supernetmasks supported for dial on_demand locations on a netserver? for example add netmask 192.168.8.0 255.255.253.0 -> network 192.168.8-0 to 192.168.11.254 set loc test netmask 255.255.253.0 set loc test address 192.168.10.254 -> address of router to dial to So the netserver should dial for every packet in the range from 192.168.8-0 to 192.168.11.254 ? Thanks Martin Oberle **************************************************************** Martin Oberle, Dipl.-Ing. Institut fuer Maschinenelemente, Universitaet Stuttgart, Germany Telefon +49 711/685-6175 e-mail oberle@ima.uni-stuttgart.de ****************************************************************

> Pete Ashdown said once upon a time: > > > >I was looking around for that route-map example you sent me for redirecting > >web requests to a proxy, but I can't find it. Could you dig it out for me > >again? > > My apologies for sending this to the list. It was intended for Brian at > Shrevenet. Actually, if it's possible to redirect port 80 queries to a proxy, we'd probably all be interested in knowing how. -- Dane Jasper Sonic (707)522-1001 (33.6kbps) (707)522-1000 (Voice) mailto:support@sonic.net http://www.sonic.net Key fingerprint = A5 D6 6E 16 D8 81 BA E9 CB BD A9 77 B3 AF 45 53

We are in the same situation 4 small phone systems and then SWB in our town. Our user that are in our lad ask for what is called a "calling circle" plan where they can dial our town unlimited number of times for a flat rate of about $15.00 Mo. Depending on how far away, some can call all over our city for the $15 other telcos only allow 1 number to be dialed. We even have one user that lives over a 100 miles away but since they are in the same lad as us she only pays the flat rate. Hopes this helps -----Original Message----- >I have had some people from smaller towns approaching me about furnishing >local dialup access. They are too small to setup anything and make money, >just not enough people in the local area. Most are serviced by independent >phone companies. I've seen where some telcos have extended local dialup >beyond their normal boundaries for modem calls. I know that Sprint did it >in the Nebraska panhandle and have seen a few others. I have discussed >this with a couple of the independent telco companies with no success so >far. I have a town setup in one area serviced by an independent now and >they have another 5-6 towns spread around the state that they service. >None of the others has any local internet access. Any of you had any >success with this? Is there a magic phrase or desciption that will work? >All I get is silence and stuttering on the other end of the line. I have a >couple of towns after me again this week, they are in the pop range of >100-300 people. This may not be the proper forum for this but its been >kind of slow here lately. 8-) > > > >Thanks, >Greg Coffey, CoffeyNet Voice 307-234-5443 307-234-5446 Fax >===================================================================== > 142 S. Center St. 3Com/USR v.90 56k $20 in Casper & Douglas >Casper, WY 82601 Local Internet for Casper, Rawlins, Douglas, > www.coffey.com Wheatland, Pinedale, Lander & Lusk, WY > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

No, The hiper arc does not terminate the isdn calls - it requires either a Quad modem or a HDM. You have to use the pri cards with the quads else use a hdm krish \ T.S.V. Krishnan \ \ Network System Engineer \ ( : - : ) \ 3Com ............ \ ----------------------------------------------/ tkrishna@bubba.ae.usr.com ----------------------------/ http://interproc.ae.usr.com ----/ The Yadda Yadda Search - for simple anwers - http://interproc.ae.usr.com/tkb.html Any Sufficiently advanced bug is indistinguishable for a feature. - Rick Kulawiec On Wed, 1 Jul 1998, Robert Adams wrote: > Hello all, > > Anyone know if it's possible to do the following? Just thought it would be a > great way of offering a LOT of ISDN only. > > > Enterprise Chassis > 5 or more Dual PRI Cards > 1 HyperARC > 2 70Amp Power > > > -Jason > > > --- > Robert J. Adams radams@siscom.net http://www.siscom.net > Looking to outsource news? http://www.newshosting.com > SISCOM Network Administration - President, SISCOM Inc. > Phone: 888-4-SISCOM 937-222-8150 FAX: 937-222-8153 > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

On Tue, 30 Jun 1998, Andres Kroonmaa wrote: > On 27 Jun 98, at 11:41, Brian <usr-tc@lists.xmission.com> wrote: > > > On Sat, 27 Jun 1998, Lee Kuo wrote: > > > > > > After installed hiperarc, we keep getting the following messages. > > > can anyone help? Thanks. > > > ------ > > > Jun 27 00:02:43 machine kernel: ICMP redirect from 208.130.151.14 > > > Jun 27 00:02:43 machine last message repeated 30 times > > > Jun 27 00:04:43 machine last message repeated 31 times > > > Jun 27 00:06:43 machine kernel: ICMP redirect from 208.130.151.14 > > > Jun 27 00:06:43 machine last message repeated 30 times > > > Jun 27 00:08:43 machine last message repeated 31 times > > > > The HiperARC has a brian dead way of handling redirects. > > > > If a user is on a IP address, handled by the ARC, and that user hangs up > > during some sort of activity. The ARC frees the IP address, but traffic > > still tries to reach the IP. The arc says "I don't know where this guy is > > and sends a redirect. > > > > If the arc is assigned ip pool 208.214.44.0/24 for example, and a user on > > 208.214.45.5 hangs up in the middle of doing something, all packets still > > trying to reach 208.214.45.5 are going to be redirected. Why? I have no > > idea, because the arc should not redirect anywheres, since there should be > > a route for that network in its tables pointing to itself. > > > > This has driven me nuts for months. I sent emails on it, detailing how > > the netserver does *not* behave like this (if a ip hangs up on a > > netserver, no redirects are sent). > > You mean, ARC sends _icmp_-redirect??? to whom? to default gateway? > huh, funny, although harmless I guess... of course it does. It looks at the IP, the ip is *NOT* in its routing table, so it sends the redirect, like a good host should. What the problem is, is this: if its assigned an ip pool of 208.214.44.0/24, why the hell doesnt it add a route for that network into its tables letting itself know it handles this network? it sends OUT routing information about that pool, but it doesnt add it to its own tables! so your going to get icmp_redirect golore. > If it just forwards packets to default gateway, then this is not only > usr/3com problem, and it is even hard to believe that netserver does > not do that. I'd guess that syslog message is misleading, that actually > there was ip forward not icmp redirect happening. > O it gets better than that: arc looks at routing table arc sees ip is not in table (but why the hell not, its part of its ip pool) arc sends redirect to router (default gateway) default gateway says "huh? i show a route for this network pointing to the arc!" it send the packet BACK to the arc, and thus a series of ping ponging continues until infinity is reached. > In fact, any NAS has trouble when it gets packet to a destination that > has dropped a call. What should it do with it, hold it in queue? too > complex, drop the packet? bad idea, as user could have came online No they don't. A netserver will look at the packet, and eventually timeout, but it wont act braindead and forward a packet from an ip pool it handles back to the default route. there is actually a way to disable this braindead behavior, perhaps krish can comment. He told me of a way to do it in the past, but in the particular version of arc code we were running, it crashed the arc, but perhaps this is fixed. > on another NAS nearby, so it is wise to forward packet to "smart" > gateway, default. If that "smart" occurs to be as "dumb" as NAS, > then they continue to play ping-pong until ip-packet's TTL reaches 0, > then packet is dropped with "source-quench". > Bad news is that with default TTL of 255 every packet destined to dead > dialin host takes about 250 fast ping-pongs before going to trash, just > wasting both local bandwidth and burning cpu uselessly. > bingo! why does it act this way by default? you got me, I hate seeing all those damn redirect messages on my console though. > About your comment that it should have a route for that network in its > tables - this is not quite true. Any NAS, when interface owning a route > goes down, immediately removes that route from its active tables, this > is normal and expected behaviour. I can't quite remember, but on the netserver, say you had a ip pool of 208.214.44.0/24, didn't it make a route for that network? sure it had a bunch of /32's also for the hosts, but there was one aggregate route for the pool also, or am I mistaken ( i cant remember). I know for a fact netsrevers do not send redirects for ip pools they handle. > > Although pretty harmless, you can get real trouble when a bunch of calls > drop from NAS that all had download activity. Consider: 1500 byte packet, > traversing 250 times local lan, wastes 366KBytes. suppose a full E1 trunk > dying with 30 sessions going down, on average 2 tcp open sessions per > modem, and allow 1-2 retry packets from remote site before it realises > that session is broken. We'd get 250x2x30x2 ~= 30000 packets spike, in > worst case all 1500 byte packets, wasting 45MB of bandwidth in a short > time. Too bad if the link is serial, not 100baseT lan. > no > Although described doom situation is unlikely, 250 redirects before drop > is useless imho, and we here handle this by installing ip filters on > input interface of default router facing NAS that reject ip packets > _destined_ to dialup pools. This way, packets pongs only once back from > NAS to default gateway, then they are rejected and icmp-host-unreachable > is sent back to remote site. > So far, it has broken nothing. In a sense, this will happen also if you > use antispoofing filters that reject all source IPs but those from ip > pools to arrive on interface from NAS side. > we had this discusion in the past. Its mostly harmless, just annoying. and like i said, krish knows how to disable this behaviour. Brian > > ---------------------------------------------------------------------- > Andres Kroonmaa mail: andre@online.ee > Network Manager > Organization: MicroLink Online Tel: 6308 909 > Tallinn, Sakala 19 Pho: +372 6308 909 > Estonia, EE0001 http://www.online.ee Fax: +372 6308 901 > ---------------------------------------------------------------------- > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > /-------------------------- signal@shreve.net -----------------------------\ | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | | Network Administrator | Perl, Linux | Web hosting, online stores, | | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | | 89 CRX DX w/MPFI, lots of |-=*:Quake:*=-| http://www.shreve.net/ | | mods/Homepage coming soon |LordSignal/SN| Quake server: 208.206.76.47 | \-------------------------- 318-222-2638 x109 -----------------------------/

On Mon, 29 Jun 1998, Mark R. Levinson wrote: > Brian writes: > > >Thats the thing. In scotty, it automagically references the "54" with its > >value via the mib file. The lookup table is already in the mib, so I was > >wondering if perl SNMP supported something that I just don't know how to > >do, and thats referencing the value "54" with its value in the mib.txt. > > Assuming that you're using version 1.7 or later, there are a couple of > ways to tell the perl SNMP module to map integer values to their > enumerations. One way is to set UseEnums in the hash that you're passing > to the "new" method, e.g.: > > $session = new SNMP::Session ( DestHost =>$nmc, Community =>$community, > UseEnums => 1 ); > > (This also lets you use the enumerations instead of integers in set > requests.) Thanks alot Mark, you just saved me ALOT of time. > -Mark- > > -- > Mark R. Levinson, Network Engineer > Information Systems & Computing > University of Pennsylvania mrl@isc.upenn.edu > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > /-------------------------- signal@shreve.net -----------------------------\ | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | | Network Administrator | Perl, Linux | Web hosting, online stores, | | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | | 89 CRX DX w/MPFI, lots of |-=*:Quake:*=-| http://www.shreve.net/ | | mods/Homepage coming soon |LordSignal/SN| Quake server: 208.206.76.47 | \-------------------------- 318-222-2638 x109 -----------------------------/

On Wed, 1 Jul 1998, Pete Ashdown wrote: > I was looking around for that route-map example you sent me for redirecting > web requests to a proxy, but I can't find it. Could you dig it out for me > again? How to do Transparent Proxying using Linux and Cisco <signal@shreve.net> Here is how I have Transparent proxying working for me, in an enviroment where my router is a Cisco 2501 running IOS 11.1, and Squid machine is running Linux 2.0.33. Many thanks to the following individules and the squid-users list for helping me get redirection and transparent proxying working on my Cisco/Linux box. Lincoln Dale Riccardo Vratogna Mark White Henrik Nordstrom First, here is what I added to my Cisco, which is running IOS 11.1. In IOS 11.1 the route-map command is "process switched" as opposed to the faster "fast-switched" route-map which is found in IOS 11.2 and later. You may wish to be running IOS 11.2. I am running 11.1, and have had no problems with my current load of about 150 simultaneous connections to squid.: ! interface Ethernet0 description To Office Ethernet ip address 208.206.76.1 255.255.255.0 no ip directed-broadcast no ip mroute-cache ip policy route-map proxy-redir ! access-list 110 deny tcp host 208.206.76.44 any eq www access-list 110 permit tcp any any eq www route-map proxy-redir permit 10 match ip address 110 set ip next-hop 208.206.76.44 So basically from above you can see I added the "route-map" declaration, and an access-list, and then turned the route-map on under int e0 "ip policy route-map proxy-redir" ok, so the Cisco is taken care of at this point. The host above: 208.206.76.44, is the ip number of my squid host. My squid box runs Linux, so I had to do the following on it: my kernel (2.0.33) config looks like this: # # Networking options # CONFIG_FIREWALL=y # CONFIG_NET_ALIAS is not set CONFIG_INET=y CONFIG_IP_FORWARD=y CONFIG_IP_MULTICAST=y CONFIG_SYN_COOKIES=y # CONFIG_RST_COOKIES is not set CONFIG_IP_FIREWALL=y # CONFIG_IP_FIREWALL_VERBOSE is not set CONFIG_IP_MASQUERADE=y # CONFIG_IP_MASQUERADE_IPAUTOFW is not set CONFIG_IP_MASQUERADE_ICMP=y CONFIG_IP_TRANSPARENT_PROXY=y CONFIG_IP_ALWAYS_DEFRAG=y # CONFIG_IP_ACCT is not set CONFIG_IP_ROUTER=y You will need Firewalling and Transparent Proxy turned on at a minimum. Then some ipfwadm stuff: # Accept all on loopback ipfwadm -I -a accept -W lo # Accept my own IP, to prevent loops (repeat for each interface/alias) ipfwadm -I -a accept -P tcp -D 208.206.76.44 80 # Send all traffic destinated to port 80 to Squid on port 3128 ipfwadm -I -a accept -P tcp -D 0/0 80 -r 3128 it accepts packets on port 80 (redirected from the Cisco), and redirects them to 3128 which is the port my squid process is sitting on. I put all this in /etc/rc.d/rc.local and the squid is configured as: http_port 3128 icp_port 3130 httpd_accel virtual 80 httpd_accel_with_proxy on I am using v1.1.20 of the squid with the patch at: http://hem.passagen.se/hno/squid/squid-1.1.20.host_and_virtual.patch installed. You will want to install this patch if using a setup similar to mine. This works great. Many thanks again to all of those listed above in helping me. Brian /-------------------------- signal@shreve.net -----------------------------\ | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | | Network Administrator | Perl, Linux | Web hosting, online stores, | | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | | 89 CRX DX w/MPFI, lots of |-=*:Quake:*=-| http://www.shreve.net/ | | mods/Homepage coming soon |LordSignal/SN| Quake server: 208.206.76.47 | \-------------------------- 318-222-2638 x109 -----------------------------/ > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > /-------------------------- signal@shreve.net -----------------------------\ | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | | Network Administrator | Perl, Linux | Web hosting, online stores, | | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | | 89 CRX DX w/MPFI, lots of |-=*:Quake:*=-| http://www.shreve.net/ | | mods/Homepage coming soon |LordSignal/SN| Quake server: 208.206.76.47 | \-------------------------- 318-222-2638 x109 -----------------------------/

On Wed, 1 Jul 1998, Pete Ashdown wrote: > Pete Ashdown said once upon a time: > > > >I was looking around for that route-map example you sent me for redirecting > >web requests to a proxy, but I can't find it. Could you dig it out for me > >again? > > My apologies for sending this to the list. It was intended for Brian at > Shrevenet. damn, I double apologize, I didn't look at the reply-to and replied! ugh! Brian > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > /-------------------------- signal@shreve.net -----------------------------\ | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | | Network Administrator | Perl, Linux | Web hosting, online stores, | | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | | 89 CRX DX w/MPFI, lots of |-=*:Quake:*=-| http://www.shreve.net/ | | mods/Homepage coming soon |LordSignal/SN| Quake server: 208.206.76.47 | \-------------------------- 318-222-2638 x109 -----------------------------/

How dos one enable ripv2 globally over the system? Were using radius to setup calls so there are no users on the arc database. Ive poured over the doc for the arc and ive turned on rip routing but as far as I can tell the only way to specify ripv2 is on a per network name basis. Any suggestions? Also im pretty sure that everything is ripv1 right now as sho ip network settings lists it as v1 and its listed that way in the harm. On the radius server theres only listen-broadcast nothing about v2 Thanks, Ernie Pritchard Inline Connections.

Hello all, Anyone know if it's possible to do the following? Just thought it would be a great way of offering a LOT of ISDN only. Enterprise Chassis 5 or more Dual PRI Cards 1 HyperARC 2 70Amp Power -Jason --- Robert J. Adams radams@siscom.net http://www.siscom.net Looking to outsource news? http://www.newshosting.com SISCOM Network Administration - President, SISCOM Inc. Phone: 888-4-SISCOM 937-222-8150 FAX: 937-222-8153

> Anyone know if it's possible to do the following? Just thought it would be a > great way of offering a LOT of ISDN only. > > > Enterprise Chassis > 5 or more Dual PRI Cards > 1 HyperARC > 2 70Amp Power The HiperARC card will not terminate ISDN calls - it doesn't have that daughterboard that the netserver has. | Curtis V. Shambeau | curt@execpc.com | http://www.execpc.com/~curt | | Executive Vice President - Exec-PC, Inc. |

thanks Krish, -----Original Message----- Cc: usr-tc@lists.xmission.com <usr-tc@lists.xmission.com> >On Wed, 1 Jul 1998, Terry Kennedy wrote: > >> >> How does one set the the quads to talk to the serial port instaead of the >> netserver? >> found the setting for the line interface to use pots lines instaed of the T1 >> card, but >> the calls will routed to the netserver at this point. Where is the setting >> to use the external >> serial port? Is in the line interface settings, I've looked but don't see >> it. Just missing >> something I would imagine. >> >You can do this via the tcm or via the attaching a RS232 cable to the modem > >The easy way out > >set the modem inactive on the packet bus >go to TCM and Programmed-settings-DTE interface - set it to 0 >Programmed-Setttings-CallControl Options - set packetbus answer only to >disable > > >krish > >> Thanks to anyone who can help..... >> >> >> - >> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" >> with "unsubscribe usr-tc" in the body of the message. >> For information on digests or retrieving files and old messages send >> "help" to the same address. Do not use quotes in your message. >> > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

When I enable NTP on my HyperDSP the machine loads the wrong time. I suspect that this is a timezone issue. Is there a way to set the timezone of the router? -- Jay Nitikman (jay@cruzio.com) Cruzio is a mom and pop Internet Service Provider Web: http://www.cruzio.com Email: info@cruzio.com Voice: 423-1162

On Thu, 2 Jul 1998, Jay Nitikman wrote: > When I enable NTP on my HyperDSP the machine loads the wrong time. I > suspect that this is a timezone issue. Is there a way to set the > timezone of the router? no you cannot set the timezone :) It will come across as GMT regardless. Brian > > -- > Jay Nitikman (jay@cruzio.com) > Cruzio is a mom and pop Internet Service Provider > Web: http://www.cruzio.com Email: info@cruzio.com Voice: 423-1162 > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > /-------------------------- signal@shreve.net -----------------------------\ | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | | Network Administrator | Perl, Linux | Web hosting, online stores, | | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | | 89 CRX DX w/MPFI, lots of |-=*:Quake:*=-| http://www.shreve.net/ | | mods/Homepage coming soon |LordSignal/SN| Quake server: 208.206.76.47 | \-------------------------- 318-222-2638 x109 -----------------------------/

On Thu, 2 Jul 1998, JC wrote: > Hi, > > I am trying to use Ascend free radius for the accounting > of USR/TC. I notice that there are many bad authenticator > in my logfile. > > Does USR implements the authenticator differently ? > > Or does anyone know what is the cause ? I have no idea. But personally I would go with merit or livingston (lucent) radius (assuming you own some livingston equipment so that your "legal"). Also if you really want some good functionality with the USR TC, that Radiator sounds real nice............I am thinking about going the Radiator direction myself, I just haven't heard much about it in real live sites and how it is doing. Brian > > TIA. > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > /-------------------------- signal@shreve.net -----------------------------\ | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | | Network Administrator | Perl, Linux | Web hosting, online stores, | | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | | 89 CRX DX w/MPFI, lots of |-=*:Quake:*=-| http://www.shreve.net/ | | mods/Homepage coming soon |LordSignal/SN| Quake server: 208.206.76.47 | \-------------------------- 318-222-2638 x109 -----------------------------/

Total Control Hub : 16-slot chassis single 110v ac 70Amp power supply, fan tray, ethernet network management card 12 Quad v34 Digital Modem NAC (48 ports total, 56k v.90) Netserver PRI Dual PRI/T1 - supports analog/ISDN Asking $7,500 for above bundle. OR separately: Quad v34 Digital Modem NAC $500 Analog/Digital Modem NIC/NAC $1,000 Netserver PRI $900 Dual PRI/T1 $900 USR Courier v.90 ext . modem $150 All products are used and in excellent condition. Buyer is responsible for shipping. Contact brwiser@xmission.com, or call Brian at 801-539-0852, extension 131. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= XMission Internet Access | Save a Tree -- Use Email! 51 E. 400 S, Suite 200 | Salt Lake City, UT 84111 | Hardware & Software Sales: Voice 801.539.0852 | http://www.xmission.com/general/retail.html Fax 801.539.0853 | =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=  Brian

JC wrote: > > I am trying to use Ascend free radius for the accounting > of USR/TC. I notice that there are many bad authenticator > in my logfile. > > Does USR implements the authenticator differently ? The accounginting authenticator is a md5 hash on the secret and the entire accounting packet (minus the authenticator field itself). This is used to authenticate the validity of the packet. I don't know if USR is calculating the authenticator correctly or not. RadiusNT has an option to ignore the authenticator, since its wasn't required in the first drafts for RADIUS accounting and not many clients actually did them correctly. > Or does anyone know what is the cause ? Typically the cause of the problem is not specifying a secret or specifying an incorrect secret for accounting requests. -- Dale E. Reed Jr. (daler@iea-software.com) _________________________________________________________________ IEA Software, Inc. | RadiusNT, Emerald, and NT FAQs Internet Solutions for Today | http://www.iea-software.com

Ok well I am just getting into this SNMP stuff with perl.. I am using SNMP support for Perl 5 by Simon Leinen <simon@switch.ch>.. Now I am not very familiar with ASN and all that.. is there anything else I can use to help me do this easier?? Gorkem

I've got some sample code using Simon's SNMP library at http://www.dcr.net/~mandrews/usrtoys/ Mike Andrews (MA12) icq 6602506 -------------- mandrews@dcr.net Senior Systems/Network Administrator --- mandrews@termfrost.org Digital Crescent, Frankfort, KY ----- http://www.termfrost.org/ "Eagles may soar, but weasels don't get sucked into jet engines." -----BEGIN GEEK CODE BLOCK----- Version: 3.1 GCS/MU d- s: a- C++ UBX++++ P++ L+ !E W+++ N++ K++ w--- O+ M+ V+++ PS+++ PE- Y+ !t !5 !X !R tv- b+ DI++ D++ e++ h++ r++ y++*@ -----END GEEK CODE BLOCK----- On Thu, 2 Jul 1998, Gorkem Yuksel wrote: > Ok well I am just getting into this SNMP stuff with perl.. I am using SNMP > support for Perl 5 by Simon Leinen <simon@switch.ch>.. Now I am not very > familiar with ASN and all that.. is there anything else I can use to help > me do this easier?? > > Gorkem > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Hi, I am trying to use Ascend free radius for the accounting of USR/TC. I notice that there are many bad authenticator in my logfile. Does USR implements the authenticator differently ? Or does anyone know what is the cause ? TIA.

I'm running a HiPer chassis/USR S&A Server and having trouble with my users being unable to login, with the reported problem as; [RADSERV] Failed login: username Maximum Sessions Exceeded under an event ID of 43 The only way I can allow them to log in is to delete the account and re-enter it as a new account. I've not set any sort of session limit, other than 1 concurrent session. Why is it doing this, and what can I do to stop it? TIA, Kirk Kirk Mitchell-General Manager mitch@keyconn.net Keystone Connect http://www.keyconn.net ***** Providing quality internet services in central PA ***** ******* (814)941-5000 We unlock the world ********

: [RADSERV] Failed login: username Maximum Sessions Exceeded The only : way I can allow them to log in is to delete the account and re-enter : it as a new account. I've not set any sort of session limit, other : than 1 concurrent session. Why is it doing this, and what can I do to : stop it? That *is* a session limit; it sounds as if your RADIUS Accounting server software is not receiving or handling Stop notifications, or is not passing them on to the authentication side. Nonetheless, I have yet to see a published RADIUS package for the TC system that can restrict multiple logins across multiple chassis in spite of loss of connectivity between the servers and the NASsen, or hard crashes, or very lossy networks. (The HARC MIB makes it theoretically possible, however.) You would do better to let your users on your system and do experimentation with keeping them offline in a maintenance period (4am).

At 11:46 PM 7/2/98 -0400, you wrote: >: [RADSERV] Failed login: username Maximum Sessions Exceeded The only >: way I can allow them to log in is to delete the account and re-enter >: it as a new account. I've not set any sort of session limit, other >: than 1 concurrent session. Why is it doing this, and what can I do to >: stop it? > >That *is* a session limit; it sounds as if your RADIUS Accounting server >software is not receiving or handling Stop notifications, or is not >passing them on to the authentication side. I understand that the "1 concurrent session" setting is a session limit, but S&A certainly shouldn't be calling that rule into effect for a user that hadn't been logged on in 24 hours. Is there anything I can do to increase the odds of S&A properly receiving Stop notifications? >Nonetheless, I have yet to see a published RADIUS package for the TC >system that can restrict multiple logins across multiple chassis in >spite of loss of connectivity between the servers and the NASsen, >or hard crashes, or very lossy networks. (The HARC MIB makes it >theoretically possible, however.) I only have 1 chassis, with 13 slots left to fill. Hopefully somebody("Hello, 3Com?") will have that problem solved before it affects me :) >You would do better to let your users on your system and do experimentation >with keeping them offline in a maintenance period (4am). Letting them on is my objective, not keeping them off. I don't, however, feel that setting concurrent sessions to unlimited is the right solution. Thanks for the reply, Kirk Kirk Mitchell-General Manager mitch@keyconn.net Keystone Connect http://www.keyconn.net ***** Providing quality internet services in central PA ***** ******* (814)941-5000 We unlock the world ********

K Mitchell was heard to say: >I'm running a HiPer chassis/USR S&A Server and having trouble with my users >being unable to login, with the reported problem as; >[RADSERV] Failed login: username Maximum Sessions Exceeded >under an event ID of 43 >The only way I can allow them to log in is to delete the account and >re-enter it as a new account. I've not set any sort of session limit, other >than 1 concurrent session. Why is it doing this, and what can I do to stop it? Turn off concurrent session limiting... it doesn't work (and never has.) --Ricky

Mark R. Lindsey was heard to say: >That *is* a session limit; it sounds as if your RADIUS Accounting server >software is not receiving or handling Stop notifications, or is not >passing them on to the authentication side. Or the NAS never sent them... the last (few) netserver code versions have not been sending the Accounting-On message when the NAS restarts. So, how the fsck are you supposed to know the NAS rebooted if it makes no effort to tell you? (I _suppose_ you could check for a reset of the ID vector, but that's even easier to break.) >Nonetheless, I have yet to see a published RADIUS package for the TC >system that can restrict multiple logins across multiple chassis in >spite of loss of connectivity between the servers and the NASsen, >or hard crashes, or very lossy networks. (The HARC MIB makes it >theoretically possible, however.) I had this mostly working until the aforemention code... The accounting server updates the users table to set the number of current sessions and the last known login location. If I detect a NAS restart (Accounting-On) then I "update USERS set current_sessions=0 where NAS='[client id]';" Of course, if they login twice to different chassis, then that causes a problem... (I said it *mostly* works.) [BTW, I also chucked USR's joke of a database schema out the window.] --Ricky

If you have some netserver cards left over from an upgrade that you want to sell, please email me qty and price. Thanks, -- Aaron Nabil

-> K Mitchell was heard to say: -> >I'm running a HiPer chassis/USR S&A Server and having trouble with my users -> >being unable to login, with the reported problem as; -> >[RADSERV] Failed login: username Maximum Sessions Exceeded -> >under an event ID of 43 -> >The only way I can allow them to log in is to delete the account and -> >re-enter it as a new account. I've not set any sort of session limit, other -> >than 1 concurrent session. Why is it doing this, and what can I do to stop -> it? -> -> Turn off concurrent session limiting... it doesn't work (and never has.) There are two other ways to solve this. Stop and restart the S/A server. This clears the session counters in the USERS table. The other option is to manually change the user's entry in the USERS table back to 0. Jeff Binkley ASA Network Computing

Forwarded by mikem from the Radiator mailing list: Reply-to: pfreed@freed.com > > I am trying to use Ascend free radius for the accounting > > of USR/TC. I notice that there are many bad authenticator > > in my logfile. > > > > Does USR implements the authenticator differently ? Authentication is pretty standard, up to a point. Perhaps if you shared the error messages, we could guess better. But it kind of sounds like the message I get when I've forgotten to put tell Radius about a particular NAS (i.e. modem bank), so every message from that NAS is either flagged as an error or silently ignored. > Also if you really want some good functionality with the USR > TC, that Radiator sounds real nice............I am thinking about going > the Radiator direction myself, I just haven't heard much about it in real > live sites and how it is doing. We've got bunches of USR TCs, and we're using Radiator. I like it a lot. It's easy to maintain, and the author does a remarkable job of producing new releases and incorporating users suggestions. (Keep up the good work, Mike!) The only downside is that it chews up more CPU than most Radius software, since it's written in Perl and not C. On the other hand, that's also it's greatest strength: the Perl code is easy to read and modify. --phil "All my life, I always wanted to be somebody. Now I see that I should have been more specific." -- Mike McCauley mikem@open.com.au Open System Consultants Pty. Ltd Unix, Motif, C++, WWW 24 Bateman St Hampton, VIC 3188 Australia Consulting and development Phone, Fax: +61 3 9598-0985 http://www.open.com.au

Does anyone know how to fix UDP problems that Quake2 or any other online games use? Is there some setting's that you need to make to USR's chassis to make thing's better.. Please Help... Vito

: Does anyone know how to fix UDP problems that Quake2 or any other online : games use? Is there some setting's that you need to make to USR's chassis : to make thing's better.. Please Help... We've mentioned a FAQ before, but I don't remember where that thread went. If somebody wants to compose a nice answer to this, I'll make it the first item on my usr-tc FAQ under http://usr-tc.datasys.net/faq/ (Until then, however, that page won't exist.)

You should upgrade to the latest Quake2 (3.17 as of this moment) which fixes some checksum problems in previous versions. A while back someone mentioned on the list that we should pause for a moment and consider if Quake was the problem, and not the usr-tc; well that was true to a certain extent. It turns out that some versions of Quake2 had really inefficient checksum code that tended to hog up the CPU and induce lag.. depending on the speed of your machine. The developer uses a high end system for testing and didnt catch the bug until after everyone noticed it hogging up their slower (although quite adequate) systems. Thats only part of it though, if at all. UDP performance seems to lack consistency locally on the network the netserver chasis sits on, where as traffic to the net seems to be ok or at least substantially better. Also, netserver release 3.7.73 seems to help, though its not publicly available so ask usr/3com about it. In fact, with the above changes I think Quake2 netserver problems are solved for good (or am I being too optimistic?) :> - lv On Fri, 3 Jul 1998 vito@aracnet.net wrote: > Does anyone know how to fix UDP problems that Quake2 or any other online > games use? Is there some setting's that you need to make to USR's chassis > to make thing's better.. Please Help... > > Vito > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

you are being to optimistic =) ... I have 3.7.73 code and quake2 gives lag of 900MS ... Seems to happen to my boxes with 2 HiPER DSP's and the rest quads (96 ports) ... seems like it statrs to lag when the box get's full ... -----Original Message----- >You should upgrade to the latest Quake2 (3.17 as of this moment) which >fixes some checksum problems in previous versions. A while back someone >mentioned on the list that we should pause for a moment and consider if >Quake was the problem, and not the usr-tc; well that was true to a certain >extent. It turns out that some versions of Quake2 had really inefficient >checksum code that tended to hog up the CPU and induce lag.. depending on >the speed of your machine. The developer uses a high end system for >testing and didnt catch the bug until after everyone noticed it hogging up >their slower (although quite adequate) systems. > >Thats only part of it though, if at all. UDP performance seems to lack >consistency locally on the network the netserver chasis sits on, where as >traffic to the net seems to be ok or at least substantially better. > >Also, netserver release 3.7.73 seems to help, though its not publicly >available so ask usr/3com about it. In fact, with the above changes I >think Quake2 netserver problems are solved for good (or am I being too >optimistic?) :> > >- lv > >On Fri, 3 Jul 1998 vito@aracnet.net wrote: > >> Does anyone know how to fix UDP problems that Quake2 or any other online >> games use? Is there some setting's that you need to make to USR's chassis >> to make thing's better.. Please Help... >> >> Vito >> >> >> >> >> - >> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" >> with "unsubscribe usr-tc" in the body of the message. >> For information on digests or retrieving files and old messages send >> "help" to the same address. Do not use quotes in your message. >> > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Ok so is there anything to fix it, and or make thing's faster in the UDP packet area. Thanks Vito On Fri, 3 Jul 1998, Jamie Orzechowski wrote: > you are being to optimistic =) ... I have 3.7.73 code and quake2 gives lag > of 900MS ... Seems to happen to my boxes with 2 HiPER DSP's and the rest > quads (96 ports) ... seems like it statrs to lag when the box get's full ... > > > -----Original Message----- > From: Laszlo Vecsey <master@internexus.net> > To: usr-tc@lists.xmission.com <usr-tc@lists.xmission.com> > Date: Friday, July 03, 1998 7:19 PM > Subject: Re: (usr-tc) UDP packet's (Help Me) > > > >You should upgrade to the latest Quake2 (3.17 as of this moment) which > >fixes some checksum problems in previous versions. A while back someone > >mentioned on the list that we should pause for a moment and consider if > >Quake was the problem, and not the usr-tc; well that was true to a certain > >extent. It turns out that some versions of Quake2 had really inefficient > >checksum code that tended to hog up the CPU and induce lag.. depending on > >the speed of your machine. The developer uses a high end system for > >testing and didnt catch the bug until after everyone noticed it hogging up > >their slower (although quite adequate) systems. > > > >Thats only part of it though, if at all. UDP performance seems to lack > >consistency locally on the network the netserver chasis sits on, where as > >traffic to the net seems to be ok or at least substantially better. > > > >Also, netserver release 3.7.73 seems to help, though its not publicly > >available so ask usr/3com about it. In fact, with the above changes I > >think Quake2 netserver problems are solved for good (or am I being too > >optimistic?) :> > > > >- lv > > > >On Fri, 3 Jul 1998 vito@aracnet.net wrote: > > > >> Does anyone know how to fix UDP problems that Quake2 or any other online > >> games use? Is there some setting's that you need to make to USR's chassis > >> to make thing's better.. Please Help... > >> > >> Vito > >> > >> > >> > >> > >> - > >> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > >> with "unsubscribe usr-tc" in the body of the message. > >> For information on digests or retrieving files and old messages send > >> "help" to the same address. Do not use quotes in your message. > >> > > > > > >- > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

only response I keep getting is to change to a HIPER ARC ... which is UNACCEPTABLE! ... A NETServer has more than enough power to do it's UDP right ... USR just needs coders with half a clue ... I say if they are phasing our NETServers, then release the source so that people like us can improve it instead of waiting for months for a fix from USR ... -----Original Message----- >Ok so is there anything to fix it, and or make thing's faster in the UDP >packet area. > >Thanks >Vito > >On Fri, 3 Jul 1998, Jamie Orzechowski wrote: > >> you are being to optimistic =) ... I have 3.7.73 code and quake2 gives lag >> of 900MS ... Seems to happen to my boxes with 2 HiPER DSP's and the rest >> quads (96 ports) ... seems like it statrs to lag when the box get's full ... >> >> >> -----Original Message----- >> From: Laszlo Vecsey <master@internexus.net> >> To: usr-tc@lists.xmission.com <usr-tc@lists.xmission.com> >> Date: Friday, July 03, 1998 7:19 PM >> Subject: Re: (usr-tc) UDP packet's (Help Me) >> >> >> >You should upgrade to the latest Quake2 (3.17 as of this moment) which >> >fixes some checksum problems in previous versions. A while back someone >> >mentioned on the list that we should pause for a moment and consider if >> >Quake was the problem, and not the usr-tc; well that was true to a certain >> >extent. It turns out that some versions of Quake2 had really inefficient >> >checksum code that tended to hog up the CPU and induce lag.. depending on >> >the speed of your machine. The developer uses a high end system for >> >testing and didnt catch the bug until after everyone noticed it hogging up >> >their slower (although quite adequate) systems. >> > >> >Thats only part of it though, if at all. UDP performance seems to lack >> >consistency locally on the network the netserver chasis sits on, where as >> >traffic to the net seems to be ok or at least substantially better. >> > >> >Also, netserver release 3.7.73 seems to help, though its not publicly >> >available so ask usr/3com about it. In fact, with the above changes I >> >think Quake2 netserver problems are solved for good (or am I being too >> >optimistic?) :> >> > >> >- lv >> > >> >On Fri, 3 Jul 1998 vito@aracnet.net wrote: >> > >> >> Does anyone know how to fix UDP problems that Quake2 or any other online >> >> games use? Is there some setting's that you need to make to USR's chassis >> >> to make thing's better.. Please Help... >> >> >> >> Vito >> >> >> >> >> >> >> >> >> >> - >> >> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" >> >> with "unsubscribe usr-tc" in the body of the message. >> >> For information on digests or retrieving files and old messages send >> >> "help" to the same address. Do not use quotes in your message. >> >> >> > >> > >> >- >> > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" >> > with "unsubscribe usr-tc" in the body of the message. >> > For information on digests or retrieving files and old messages send >> > "help" to the same address. Do not use quotes in your message. >> > >> >> >> - >> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" >> with "unsubscribe usr-tc" in the body of the message. >> For information on digests or retrieving files and old messages send >> "help" to the same address. Do not use quotes in your message. >> > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

-> Ok so is there anything to fix it, and or make thing's faster in the UDP -> packet area. -> -> Thanks -> Vito So far the answer seems to be sqitching to HiPerArcs. It solved the problem here. Jeff Binkley ASA Network Computing

-> only response I keep getting is to change to a HIPER ARC ... which is -> UNACCEPTABLE! ... A NETServer has more than enough power to do it's UDP -> right ... USR just needs coders with half a clue ... I say if they are -> phasing our NETServers, then release the source so that people like us can -> improve it instead of waiting for months for a fix from USR ... Nice thought but I believe part of that source code is licensed from Lucent (i.e. Livingston) and this would preclude them from doing so. I struggked with this decision too but the bottom line was all of the major new features will come in the HiPerArc and I didn't want to be left behind. I'm still waiting to see there trade-in program to be announced. Jeff Binkley ASA Network Computing

Jamie Orzechowski was heard to say: >only response I keep getting is to change to a HIPER ARC ... which is >UNACCEPTABLE! ... A NETServer has more than enough power to do it's UDP >right ... USR just needs coders with half a clue ... I say if they are >phasing our NETServers, then release the source so that people like us can >improve it instead of waiting for months for a fix from USR ... While I share your view, USR doesn't own the code to the netserver and therefore cannot give it away. If USR were so inclined, all that is needed is the hardware specs for the netserver (it's mostly just a PC, but it's got that "fancy" TDM interface and all that jaz) ... --Ricky

Ever since i upgraded to V.90 code on the quad modems and Netservers, (Hiper DSP upgrade but no V.90) I haven't been able to get ant Multilink ISDN connections online. has anyone noticed anything similar? I suspect that since the ISDN calls are answered in in the Netserver card that something need to be enabled but i don't know what. Leon

Walt Gnann said once upon a time: > >Why can't you setup a local number in the remote town and pay for the >unlimited calling circle plan. Then forward the number to base POP. As >long as the phone companies are digitally connected the call should be >pretty clean. The way it's been explained to me is after the number is >forwarded it's free to take another call. I'd check it out thoroughly with >the local telco guys and make sure it's within the tarriff for that service. Up to a limit. We've hit this before in an area with a similar scheme. It is around 100 forwarded calls.

At 03:57 PM 7/6/98 -0400, you wrote: >Why can't you setup a local number in the remote town and pay for the >unlimited calling circle plan. Then forward the number to base POP. As >long as the phone companies are digitally connected the call should be >pretty clean. The way it's been explained to me is after the number is >forwarded it's free to take another call. I'd check it out thoroughly with >the local telco guys and make sure it's within the tarriff for that service. > Actually I don't think that is within the Tarrif - Defeating Long Distance to the end customer. They (at least here) call that Extended Business something or other - and want the ISP to pay per minute fee for incoming calls from what would normally be a LD Call making it unaffordable for the end customer... It can be done, but you do risk some exposure to lawsuits from US West if you try to do it. ***** Top Net InterNet Services ***** Omaha, Nebraska Husker Heaven www.top.net (402) 291-1542 Visit Our BBS at: www.hawgwild.com

Why can't you setup a local number in the remote town and pay for the unlimited calling circle plan. Then forward the number to base POP. As long as the phone companies are digitally connected the call should be pretty clean. The way it's been explained to me is after the number is forwarded it's free to take another call. I'd check it out thoroughly with the local telco guys and make sure it's within the tarriff for that service. Walt Walter N. Gnann ISLC, Manager 843.770.1000 843.770.1002 (fax) wgnann@islc.net http://www.islc.net http://www.beaufortcomputerclub.org -----Original Message----- >We are in the same situation 4 small phone systems and then SWB in our town. >Our user that are in our lad ask for what is called a "calling circle" plan >where they can dial our town unlimited number of times for a flat rate of >about $15.00 Mo. Depending on how far away, some can call all over our city >for the $15 other telcos only allow 1 number to be dialed. We even have one >user that lives over a 100 miles away but since they are in the same lad as >us she only pays the flat rate. Hopes this helps >-----Original Message----- >From: Greg Coffey <greg@coffey.com> >To: usr-tc@lists.xmission.com <usr-tc@lists.xmission.com> >Date: Wednesday, July 01, 1998 2:11 PM >Subject: (usr-tc) Extending local area phone service > > >>I have had some people from smaller towns approaching me about furnishing >>local dialup access. They are too small to setup anything and make money, >>just not enough people in the local area. Most are serviced by independent >>phone companies. I've seen where some telcos have extended local dialup >>beyond their normal boundaries for modem calls. I know that Sprint did it >>in the Nebraska panhandle and have seen a few others. I have discussed >>this with a couple of the independent telco companies with no success so >>far. I have a town setup in one area serviced by an independent now and >>they have another 5-6 towns spread around the state that they service. >>None of the others has any local internet access. Any of you had any >>success with this? Is there a magic phrase or desciption that will work? >>All I get is silence and stuttering on the other end of the line. I have a >>couple of towns after me again this week, they are in the pop range of >>100-300 people. This may not be the proper forum for this but its been >>kind of slow here lately. 8-) >> >> >> >>Thanks, >>Greg Coffey, CoffeyNet Voice 307-234-5443 307-234-5446 Fax >>===================================================================== >> 142 S. Center St. 3Com/USR v.90 56k $20 in Casper & Douglas >>Casper, WY 82601 Local Internet for Casper, Rawlins, Douglas, >> www.coffey.com Wheatland, Pinedale, Lander & Lusk, WY >> >>- >> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" >> with "unsubscribe usr-tc" in the body of the message. >> For information on digests or retrieving files and old messages send >> "help" to the same address. Do not use quotes in your message. >> > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

I am having a problem accessing my enterprise hub from TCM. This is a new setup and I've setup the NMC with an IP and the default SNMP settings. When I try to access the rack through TCM I receive "device not responding" I can ping the rack ip. The USR view program causes a Dr. Watson and crashes. I have another rack at a remote location that works fine. The NMC is running card rev 4.3.4 The TCM is 5.5.1 If I need to upgrade the NMC how can I do it without using TCM? Any responses most appreciated thanks, aj

What you are describing is called an "RCF" in GTE/Texas. The RCF can have multiple paths and each path will forward a call. So if you want to forward 20 calls to the mail POP, you need an RCF with 19 additional paths. Again, in GTE/Texas the cost of an RCF is $14.50/path unless it is an a former Contel area and then it is $20/path. Also, I keep hearing that some switches have limitations on how many paths an RCF can have. And everytime I expand the ones I have, I get a song and dance about not being able to have more than 14 paths and they don't know if the requested expansion can be granted. But so far, there has been no trouble. Butch At 03:57 PM 7/6/98 -0400, you wrote: >Why can't you setup a local number in the remote town and pay for the >unlimited calling circle plan. Then forward the number to base POP. As >long as the phone companies are digitally connected the call should be >pretty clean. The way it's been explained to me is after the number is >forwarded it's free to take another call. I'd check it out thoroughly with >the local telco guys and make sure it's within the tarriff for that service. > >Walt >----------------------------------------------------- >Walter N. Gnann >ISLC, Manager >843.770.1000 >843.770.1002 (fax) >wgnann@islc.net >http://www.islc.net >http://www.beaufortcomputerclub.org >----------------------------------------------------- > >-----Original Message----- >From: G. Owens <gowens@seark.net> >To: usr-tc@lists.xmission.com <usr-tc@lists.xmission.com> >Date: Wednesday, July 01, 1998 9:18 PM >Subject: Re: (usr-tc) Extending local area phone service > > >>We are in the same situation 4 small phone systems and then SWB in our >town. >>Our user that are in our lad ask for what is called a "calling circle" plan >>where they can dial our town unlimited number of times for a flat rate of >>about $15.00 Mo. Depending on how far away, some can call all over our city >>for the $15 other telcos only allow 1 number to be dialed. We even have one >>user that lives over a 100 miles away but since they are in the same lad as >>us she only pays the flat rate. Hopes this helps >>-----Original Message----- >>From: Greg Coffey <greg@coffey.com> >>To: usr-tc@lists.xmission.com <usr-tc@lists.xmission.com> >>Date: Wednesday, July 01, 1998 2:11 PM >>Subject: (usr-tc) Extending local area phone service >> >> >>>I have had some people from smaller towns approaching me about furnishing >>>local dialup access. They are too small to setup anything and make money, >>>just not enough people in the local area. Most are serviced by >independent >>>phone companies. I've seen where some telcos have extended local dialup >>>beyond their normal boundaries for modem calls. I know that Sprint did it >>>in the Nebraska panhandle and have seen a few others. I have discussed >>>this with a couple of the independent telco companies with no success so >>>far. I have a town setup in one area serviced by an independent now and >>>they have another 5-6 towns spread around the state that they service. >>>None of the others has any local internet access. Any of you had any >>>success with this? Is there a magic phrase or desciption that will work? >>>All I get is silence and stuttering on the other end of the line. I have >a >>>couple of towns after me again this week, they are in the pop range of >>>100-300 people. This may not be the proper forum for this but its been >>>kind of slow here lately. 8-) >>> >>> >>> >>>Thanks, >>>Greg Coffey, CoffeyNet Voice 307-234-5443 307-234-5446 Fax >>>===================================================================== >>> 142 S. Center St. 3Com/USR v.90 56k $20 in Casper & Douglas >>>Casper, WY 82601 Local Internet for Casper, Rawlins, Douglas, >>> www.coffey.com Wheatland, Pinedale, Lander & Lusk, WY >>> >>>- >>> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" >>> with "unsubscribe usr-tc" in the body of the message. >>> For information on digests or retrieving files and old messages send >>> "help" to the same address. Do not use quotes in your message. >>> >> >> >>- >> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" >> with "unsubscribe usr-tc" in the body of the message. >> For information on digests or retrieving files and old messages send >> "help" to the same address. Do not use quotes in your message. >> > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

If you can ping the NMC the only reason you would not get a response from the device is if you are not using the correct snmp community strings. Connect to the console and choose option 1 on the Main Menu (Configuration). Now choose option 5 (Local SNMP Community Strings). Now look at the read and the read+write community strings. Make sure you are specifying these strings when you open TCM and choose file/new. If all else fails, flip dip 6 on the NMC. You'll find the dips just behind the face plate. Reseat the NMC and try it again. As far as flashing your NMC without TCM, you can use PCSDL to do that. use the following steps: 1. Verify you can get a console session to your NMC. (Use a rj45 to a db25 with a null modem adapter and a modem cable to connect one of your com ports to the console. Then open HyPer Terminal and set the speed to 9600 if dips. 9600 assumes dips 1 & 2 are off on your NMC. 2. If you can see a menu then close hyper terminal and any other programs you may have open. Open a dos prompt or close windows and go to DOS. 3. Change directories to the directory where your unzipped NMC files are. You will need a .nac, .sdl., & pcsdl.exe. 4. Type the following: pcsdl -p1 -r9600 -vsd3.2.0 -vna5.4.95 -nsdnm -nnanm (for 4mb NMC cards) assumes you have downloaded and unzipped nmc5495.zip from totalservice.3com.com into the current directory pcsdl -p1 -r9600 -vsd3.2.0 -vna5.5.86 -nsdnm -nnahm (for 16mb NMC cards) assumes you have downloaded and unzipped nmc5586.zip from totalservice.3com.com into the current directory -p1 assumes you have your modem cable to nullmodem to db25 to rj45 cable plugged into your 1st com port on your PC. Hope this helps "Jolliffe, Anu" <ajolliffe@imagen.net> on 07/06/98 06:09:10 PM Please respond to usr-tc@lists.xmission.com cc: I am having a problem accessing my enterprise hub from TCM. This is a new setup and I've setup the NMC with an IP and the default SNMP settings. When I try to access the rack through TCM I receive "device not responding" I can ping the rack ip. The USR view program causes a Dr. Watson and crashes. I have another rack at a remote location that works fine. The NMC is running card rev 4.3.4 The TCM is 5.5.1 If I need to upgrade the NMC how can I do it without using TCM? Any responses most appreciated thanks, aj - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

After switching over to the HiPerArcs from Netservers, I am finding myself having a difficult time building a filter. Here is one I have built but it doesn't seem to work: #filter IP: 010 AND src-addr = 199.178.136.0/24 020 ACCEPT dst-addr = 199.178.136.0/24; DENY; According to RADIUS, the filter is being sent to the HiPerArc. WHat I thought this rule would do is limited IP traffic to only being between addresses originating and termintain with the designated class c address range. In testing though it appears not to make any difference (i.e. someone within this class c can get to other addresses outside of the class c). What am I missing ? What is also confusing is that with the Netserver you created two filters (i.e. xyz.in and xyz.out) to correspond to the filter name. The HiPerArc doesn't seem to require this or I can't find it in the documentation. Thanks, Jeff Binkley ASA Network Computing CMPQwk 1.42 9999

>-----Original Message----- >From: owner-usr-tc@lists.xmission.com >[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Jeff Binkley >Sent: Tuesday, July 07, 1998 8:47 AM >To: usr-tc@lists.xmission.com >Subject: (usr-tc) HiPer Arc Filters > > > > > >After switching over to the HiPerArcs from Netservers, I am finding >myself having a difficult time building a filter. Here is one I have >built but it doesn't seem to work: > >#filter >IP: >010 AND src-addr = 199.178.136.0/24 >020 ACCEPT dst-addr = 199.178.136.0/24; >DENY; > >According to RADIUS, the filter is being sent to the HiPerArc. WHat I >thought this rule would do is limited IP traffic to only being between >addresses originating and termintain with the designated class c address >range. In testing though it appears not to make any difference (i.e. >someone within this class c can get to other addresses outside of the >class c). What am I missing ? > >What is also confusing is that with the Netserver you created two >filters (i.e. xyz.in and xyz.out) to correspond to the filter name. >The HiPerArc doesn't seem to require this or I can't find it in the >documentation. > For setting up filters you will have to do the following. Filters can be created / modified using 1. HARM 2. An off line text editor than TFTP the file. "set interface slot:x/:mod:[1-Y] filter_access on" Then disable and re-enable the interfaces. add filter <filename> verify filter <filename> Also remember the in vs out conventions. In and out is always in reference to the interface and not the dial client. USER INTERFACE DATA --> = input filter <-- DATA = output filter For HARC Filters: 1) filter_access must be turned on, on the interface for them to work. 2) You can use RADIUS framed-filter-id to apply a filter to a specific user via RAIDIUS.filter file must be present on the HARC. Make sure the filter has the correct suffix (.in or .out) if you wish the filter to be input or output only. 3) Or, you can use ip-input-filter/ip-output-filter to set the filter up dynamically via RADIUS 4) Or, if the user is defined on the HARC you can always set a filter for that specific user. The filter file must be present on the HARC. For Example #filter IP: 010 ACCEPT src-addr = 128.100.33.1 020 DENY dst-addr = 200.135.38.9 For RADIUS users you can see if the filter is applied by typing "show remote user <name>". It will show what filters are applied. Hope this helps.

>-----Original Message----- >From: owner-usr-tc@lists.xmission.com >[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Jeff Binkley >Sent: Tuesday, July 07, 1998 11:06 AM >To: usr-tc@lists.xmission.com >Subject: RE: (usr-tc) HiPer Arc Filters > > >-> For setting up filters you will have to do the following. >-> >-> Filters can be created / modified using >-> 1. HARM >-> 2. An off line text editor than TFTP the file. >-> >-> "set interface slot:x/:mod:[1-Y] filter_access on" >-> Then disable and re-enable the interfaces. > >Is the "set interface xyz filter_access on" required even if I am >using RADIUS >to send the filter name to the HiPerArc and the filter is stored in the >HiPerArc via the HARM ? If so, this is definetly different than >the Netserver. Yes. All HARM does is automate the editing and TFTP of the filter file. It doesnt use a different method of creating the filters on the HARC. >Also if so, is the disable and re-enable command disruptive ? Yes. >-> add filter <filename> >-> verify filter <filename> >-> >-> Also remember the in vs out conventions. In and out is always >in reference >-> to the interface and not the dial client. >-> >-> USER INTERFACE >-> DATA --> = input filter >-> <-- DATA = output filter >-> >-> For HARC Filters: >-> >-> 1) filter_access must be turned on, on the interface for them to work. >-> 2) You can use RADIUS framed-filter-id to apply a filter to a specific >-> user via RAIDIUS.filter file must be present on the HARC. Make sure the >-> filter has the correct suffix (.in or .out) if you wish the filter to be >-> input or output only. >-> 3) Or, you can use ip-input-filter/ip-output-filter to set the filter up > >Ok, does #2 mean then that if there is no .in or .out extension >that the filter >is bidirectional or must I create two files one with a .in and one >with a .out >and make them identical to have a bi-directional filter ? Sorry >for all of the >questions but have I found the documentation lacking so far. > If you supply a Framed-Filter-Id = "myfilter" Harc will expect that you have the filters myfiler.in and myfilter.out installed. If you supply a Framed-Filter-Id = "myfilter.in" then only myfilter.in needs to be present.

-> For setting up filters you will have to do the following. -> -> Filters can be created / modified using -> 1. HARM -> 2. An off line text editor than TFTP the file. -> -> "set interface slot:x/:mod:[1-Y] filter_access on" -> Then disable and re-enable the interfaces. Is the "set interface xyz filter_access on" required even if I am using RADIUS to send the filter name to the HiPerArc and the filter is stored in the HiPerArc via the HARM ? If so, this is definetly different than the Netserver. Also if so, is the disable and re-enable command disruptive ? -> add filter <filename> -> verify filter <filename> -> -> Also remember the in vs out conventions. In and out is always in reference -> to the interface and not the dial client. -> -> USER INTERFACE -> DATA --> = input filter -> <-- DATA = output filter -> -> For HARC Filters: -> -> 1) filter_access must be turned on, on the interface for them to work. -> 2) You can use RADIUS framed-filter-id to apply a filter to a specific -> user via RAIDIUS.filter file must be present on the HARC. Make sure the -> filter has the correct suffix (.in or .out) if you wish the filter to be -> input or output only. -> 3) Or, you can use ip-input-filter/ip-output-filter to set the filter up Ok, does #2 mean then that if there is no .in or .out extension that the filter is bidirectional or must I create two files one with a .in and one with a .out and make them identical to have a bi-directional filter ? Sorry for all of the questions but have I found the documentation lacking so far. Jeff Binkley ASA Network Computing

Thus spake Walt Gnann >Why can't you setup a local number in the remote town and pay for the >unlimited calling circle plan. Then forward the number to base POP. As >long as the phone companies are digitally connected the call should be >pretty clean. The way it's been explained to me is after the number is >forwarded it's free to take another call. I'd check it out thoroughly with >the local telco guys and make sure it's within the tarriff for that service. I would think it would depend on the switches and the telco's involved... If the switches are using an SS7 setup to forward calls (ie, true number portability), then once the call is "forwarded" then it should be free to handle another one...basically what you're doing is taking that number and actually moving the home switch for that number to the other switch...there should be no limits on the number of calls that this setup can take. The other option that folks have mentioned is the Remote Call Forwarding (RCF) and is what is used if the switches are SS7 capable. This is what we're having to use in at least one location (on a 1A switch here in Louisville ancient piece of analog junk), and this is the situation where they have to set up "paths". Each group of paths (not sure of the telco terminology here) is limited to 14 or 15 paths or so, but these can be grouped together in a hunt group up to being able to give you about 100 paths (think its actually 99), so for most places, this will do what you need, but in large locations you could run into problems. <ponder> I wonder if you could set up the 99th path to do a *local* call forward to another number within the same switch which is then set up as another one of these 99 trunk groups to do remote call forwarding....proly could, but good luck getting any telco's to do it </ponder> P.S. Back from my honeymoon...I'll get on the redistributing RIPv2 into OSPF here in a minute...the cruise itself was wonderful, getting there and getting back was a nightmare...don't fly Delta, their customer service is worse that any phone company I've ever dealt with. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Thus spake Brian >Ok, I'll start this out. Here is how *we* are doing it: >First, let me tell you that all HiperARC (you could substitute netservers) >are on the 208.206.76.0/24 network. All my servers (web, mail, etc) are >all on that network as well. Dialup pools are on totally seperate >networks, and that doesnt matter. OK, our assumptions here (again, sorry for taking so long for this, got married and all that :)... we put 4 usr chassis' on a subnet...each subnet is a flat 10bt network (ie, no switching at this point). We have the netservers, nmc's and dialup pools all within a class c on that subnet, so x.x.x.1 is the default gateway (cisco 2501 usually), x.x.x.2 is the first nmc, x.x.x.3 is the first netserver, x.x.x.4 is the second nmc, etc. we start our dialup pools at x.x.x.20 just to leave a few free for adding weird stuff in later if we need (switches, maybe a sparc for watching the network, stuff like that). This layout allows us to put 4 full chassis' in a class C without a great deal of wasted IP numbers. The example configs I'm going to put below is for our Nashville POP (newest POP, simplest, smallest, etc.), and the config is this: 10bt ethernet that everything is sitting on...2501 as the router, t1 back to our main location....ripv2 is running on the ethernet, ospf is running on the t1 (and the cisco is also set up to talk OSPF on the ethernet even though there's nothing else there for it to talk to in OSPF). The Class C for this network in Nashville is 204.255.232.0/24, the T1 has the ip number of 204.255.229.250 (249 being the IP number of the other side of the link) the relevant sections of the config are: router rip version 2 ! turn on rip version 2 (obviously) timers basic 30 90 5 120 ! adjust rip timeouts to prevent long routing "black-holes" network 204.255.232.0 ! ethernet network IP block...specifies to run RIPv2 on the ethernet !interface (which is within this block) distribute-list 12 in ! only accept routes that pass the access-list number 12 no auto-summary ! don't screw with any summarization....OSPF will handle all of that ! This access-list controls what routes are allowed to be advertised by ! RIPv2...this is only here as a protection from someone advert'ing a ! bogus default route, we only have it because we had some old Xyplex ! equipment that didn't seem to have any way to disable advertisement of ! certain routes and would therefore advert theis default route out and ! screw things up no access-list 12 access-list 12 deny 0.0.0.0 access-list 12 permit any router ospf 1 summary-address 204.255.232.0 255.255.255.0 ! for all address is the 204.255.232.0/24 network, just advertise the ! base /24 route...this cuts down on the number of routes advertised as ! anything in 204.255.232.0 is on the local ethernet and the routing for ! that is handled by the ripv2 redistribute rip metric 1 subnets route-map rip2ospf ! redistribute rip routes into OSPF, allow subnets, and only advertise ! ones that match the route map rip2ospf...these routes are subject to the ! summarization above network 204.255.232.0 0.0.0.255 area 0 network 204.255.229.0 0.0.0.255 area 0 ! Run OSPF on any interfaces in the following network blocks, and these ! interfaces are in area 0 (backbone area)...this matches both the ! ethernet, and the t1 interface ! This route map is also here for checking for bum configs...basically, ! it prevents OSPF from adverting routes learned from RIP on any ! interfaces other than the ones that are listed here...so this router ! will only advertise routes into OSPF from RIP that are learned through ! the ethernet interfaces...this let me slowly introduce OSPF into the ! network, so I could set this router up to run OSPF and still let it ! learn RIP routes over the T1 and *not* redistribute routes into OSPF ! which would then override those RIP routes learned via the T1 and cause ! a routing loop...made switching to OSPF *much* easier as I could ! specify more directly where I would allow routes to be learned from so I ! could run RIP and OSPF in parallel on our backbone for a while while I ! implemented it in our other routers route-map rip2ospf permit 10 match interface Ethernet0 OK...so here's how we really make use of this...and what this does...we assign static IP addresses out of other Class C blocks (which are not in the summary-address statements), so those blocks get advertised out as they are assigned (many /32's, but a few blocks assigned via Framed-Route statements in RADIUS, usually /27's, /28's, and /29's depending on how big the customer is). The static IP address is assigned in the netserver, advertised via RIPv2, picked up by the cisco and redistributed in OSPF everywhere else. If its a dynamically assigned IP address, it'll be advertised by the netserver, picked up by the Cisco and only advertised as the summary for the whole class c (which was almost assuredly already advertised). Some customers have static IP's assigend out of class C's (usually the very top of the Class C) that were also assigned to modem networks (for example, up in Cincinnati we have customers with IP address such as 199.170.84.253, the dialup pools, netservers, and NMC's are all in the 199.170.84.0 class c...don't ask...old crappy Xyplex equipment we used to use required this), so these customers can now call to other POP's (say nashville) and that specific /32 for that customer is still advertised out via RIPv2 on the netservers into OSPF on the cisco's and is therefore fully reachable even though they're not in thier "home" POP...the only place that they wouldn't be reachable (maybe, haven't checked that for sure) is actually in their "home" POP (ie, Cincinnati in the above example) since those Netservers and such would assume that they would be reachable on the directly connected network when they aren't...this could be solved by redistributing OSPF back into RIPv2 for the netservers and such, but I haven't deemed that enough of a problem to worry with worrying about the interactions and possible routing loops (proly not major, but we haven't had anyone need this functionality yet, so we're not worrying about it yet :). Obviously, this scheme doesn't work when you're whole operation is on one flat network, or when you only have one class C to work with (though there's no reason it couldn't be made to work with smaller subnets) Anyway...I *hope* I've made this pretty clear and haven't confused everyone...let me know if you have further questions about it. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

u>> u>> u>> u>> u>> u>>After switching over to the HiPerArcs from Netservers, I am finding u>>myself having a difficult time building a filter. Here is one I have u>>built but it doesn't seem to work: u>> u>>#filter u>>IP: u>>010 AND src-addr = 199.178.136.0/24 u>>020 ACCEPT dst-addr = 199.178.136.0/24; u>>DENY; u>> u>>According to RADIUS, the filter is being sent to the HiPerArc. WHat u>I >thought this rule would do is limited IP traffic to only being u>between >addresses originating and termintain with the designated u>class c address >range. In testing though it appears not to make any u>difference (i.e. >someone within this class c can get to other u>addresses outside of the >class c). What am I missing ? u>> u>>What is also confusing is that with the Netserver you created two u>>filters (i.e. xyz.in and xyz.out) to correspond to the filter name. u>>The HiPerArc doesn't seem to require this or I can't find it in the u>>documentation. u>> u>For setting up filters you will have to do the following. u>Filters can be created / modified using u>1. HARM u>2. An off line text editor than TFTP the file. u>"set interface slot:x/:mod:[1-Y] filter_access on" u>Then disable and re-enable the interfaces. Thanks for your help. I finally got a filter working. it seems there is either a bug on the HiPerArc 4.0.29 code or the documentation is wrong in many places. The problem ended up being the rule itself. The last line: DENY; doesn't work. HARM would sometimes show the compile being good and sometimes you'd get a goofy error message about "line 0 IP:" being wrong. I finally went to the HiPerArc itself and did a verify filter. Through process of elimination I got it working. Since the DENY didn't work I reversed the logic on the rule and wrote it as a != instead of an = and now they work. Jeff Binkley ASA Network Computing CMPQwk 1.42 9999

Hi, I see that I could optionaly activate a Cellular protocol. Which new possibilities could I open to my customers ? Could I offer : - SMS - E-mail - Paging services to my customers connected thru my TC's ? Thanks . -- Gilles Lorphelin Telecoms Mgr. - ISOC Member Phone : +689 508 888 MANA S.A. (www.mana.pf) Fax : +689 508 889 IAP/ISP - Tahiti & her Islands E-mail: gilles@mana.pf

Anybody know the magic incantation to do this? SNMP just still isn't my "thing", and I know this has to be possible.

We are having a considerable amount of problems with people who use telepath modems. We are using both the HiPer DSP/Hiper ARC and the netserver/quad modems. People who used to connect fine to us on old Multitech equipment connect are instanly dropped. Anyone else seen this problem before? Terry Kennedy

Terry, We have seen this too... I think it is a combination of several things! Bad phone line (telepaths don't like bad lines) Some bad modems, just won't connect at all. Someone can correct me if I'm wrongm, but I believe their x2 flash code is kinda old? We have about a 50/50 split on connections and non connections as well as some attaining x2 speeds and other only 31,200??? I really think most of it lies with the modem itself. Just my opinion.... Phillip On Wed, 8 Jul 1998, Terry Kennedy wrote: > We are having a considerable amount of problems with > people who use telepath modems. We are using both > the HiPer DSP/Hiper ARC and the netserver/quad modems. > People who used to connect fine to us on old Multitech equipment > connect are instanly dropped. Anyone else seen this problem before? > > Terry Kennedy > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Is anyone aware of any problems with the HiPerArc 4.0.29 code and being able to connect with Courier I-Modem using asyncPPP on 2 ISDN channels ? Since switching from the Netserver to the HiPerArc card, we cannot get a Cour I-Modem to connect with anything other than a single channel v.110 or V.120 connection. When we try the v2=5 option on the Courier I-Modem we never see the userid and password get sent from the NT 4.0 workstation. And the second channel never tried to come up. This worked fine with the Netserver. We've got a ticket in with supprot but I am not holding out much hope with them. We are able to get an Ascend Pipeline 50 to establish a connection on 2 channels. Thanks, Jeff Binkley ASA Network Computing

>-----Original Message----- >From: owner-usr-tc@lists.xmission.com >[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Jeff Binkley >Sent: Thursday, July 09, 1998 9:03 AM >To: USR-TC@lists.xmission.com >Subject: (usr-tc) Courier I Modem and TC > > > >Is anyone aware of any problems with the HiPerArc 4.0.29 code and >being able to connect with Courier I-Modem using asyncPPP on >2 ISDN channels ? Since switching from the Netserver to the HiPerArc >card, we cannot get a Cour I-Modem to connect with anything other >than a single channel v.110 or V.120 connection. When we try the >v2=5 option on the Courier I-Modem we never see the userid and >password get sent from the NT 4.0 workstation. And the second >channel never tried to come up. This worked fine with the Netserver. >We've got a ticket in with supprot but I am not holding out much >hope with them. We are able to get an Ascend Pipeline 50 to >establish a connection on 2 channels. > Try this for an init string: at*v2=5*d0=1 It works for me. You should also try turning off LCP extentions and IP Headder compression if NT is your dial client.

I have the unique opportunity of starting over with some new equipment, a new users file, and a new radius in a few weeks. I'd like to do it right this time. I'm well versed with mysql, so Radiator looks very attractive to me. Is anyone here using it yet? I have a hard time using any Unix software "sight-unseen". Do you know if they offer any type of evaluations, even if we "deposit" our credit card number with them for 30 days? How is performance compared to Merit radius? Any other recommendations? I would like to stay with a FreeBSD based system. Thanks, Randy Cosby iCable.net

Do you have the "hiper bundle" special available there? It's a full chassis with two hiper cards, and is much cheaper than buying the cards by themselves. We've bought a couple and just pulled the cards out of them and moved them to another chassis to save shelf space. Now we have spare chassis, power supplies, NMC's, and HiperARC's.

-> > -> > -> > -> >Is anyone aware of any problems with the HiPerArc 4.0.29 code and >being -> able to connect with Courier I-Modem using asyncPPP on -> >2 ISDN channels ? Since switching from the Netserver to the HiPerArc -> >card, we cannot get a Cour I-Modem to connect with anything other >than a -> single channel v.110 or V.120 connection. When we try the >v2=5 option on -> the Courier I-Modem we never see the userid and >password get sent from the -> NT 4.0 workstation. And the second >channel never tried to come up. This -> worked fine with the Netserver. >We've got a ticket in with supprot but I am -> not holding out much >hope with them. We are able to get an Ascend Pipeline -> 50 to -> >establish a connection on 2 channels. -> > -> -> Try this for an init string: -> at*v2=5*d0=1 -> -> It works for me. You should also try turning off LCP extentions and IP -> Headder compression if NT is your dial client. Mike, I'll try it. What I find odd is everyone says turn off NT LCP and IP compression. yet we have always had our systems setup that way and it works flawlessly. I am wondering why folks keep wanting to turn it off ? Granted you have to have the Netserver or HiPerArc setup to handle them but I've seen no inherent problem with them. Jeff Binkley ASA Network Computing

I have a similar problem.. ever since i upgraded to V.90 code, I have not been able to connect at 128K with either Pipeline 50s or Courier-Is. the Courier-Is are both on win95 machines so i don't thing they even use LCP extensions. Leon

I'm trying to limit ISDN to a a single B-channel via RADIUS. How do I do this? I thought I once saw this in 3COM documentation, but now I can't find the info. -- Jay Nitikman (jay@cruzio.com) Cruzio is a mom and pop Internet Service Provider Web: http://www.cruzio.com Email: info@cruzio.com Voice: 423-1162

Brian wrote: > > I am keeping my eye on radiator as well. I just need to here more > feedback. We use the Platypus billing system, and Radiator output records > would have to be compatible. I like the 3Com VSA stuff in Radiator. I am > wondering if it has support for Postgres.......... You might want to look at RadiusNT. I know Platypus supports it at the DB level (no text file import junk to worry about). The latest supports VSA attrbiutes and works with many different DB backends. -- Dale E. Reed Jr. (daler@iea-software.com) _________________________________________________________________ IEA Software, Inc. | RadiusNT, Emerald, and NT FAQs Internet Solutions for Today | http://www.iea-software.com

On Thu, 9 Jul 1998, Randy Cosby wrote: > I have the unique opportunity of starting over with some new equipment, a new > users file, and a new radius in a few weeks. I'd like to do it right this time. > > I'm well versed with mysql, so Radiator looks very attractive to me. Is anyone > here using it yet? I have a hard time using any Unix software "sight-unseen". > Do you know if they offer any type of evaluations, even if we "deposit" our > credit card number with them for 30 days? How is performance compared > to Merit radius? I am keeping my eye on radiator as well. I just need to here more feedback. We use the Platypus billing system, and Radiator output records would have to be compatible. I like the 3Com VSA stuff in Radiator. I am wondering if it has support for Postgres.......... > > Any other recommendations? I would like to stay with a FreeBSD based system. > > Thanks, > > Randy Cosby > iCable.net > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > /-------------------------- signal@shreve.net -----------------------------\ | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | | Network Administrator | Perl, Linux | Web hosting, online stores, | | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | | 89 CRX DX w/MPFI, lots of |-=*:Quake:*=-| http://www.shreve.net/ | | mods/Homepage coming soon |LordSignal/SN| Quake server: 208.206.76.47 | \-------------------------- 318-222-2638 x109 -----------------------------/

>-----Original Message----- >From: owner-usr-tc@lists.xmission.com >[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Jay Nitikman >Sent: Thursday, July 09, 1998 3:09 PM >To: usr-tc@lists.xmission.com >Subject: (usr-tc) limiting ISDN to a single B-channel > > >I'm trying to limit ISDN to a a single B-channel via RADIUS. How do I >do this? I thought I once saw this in 3COM documentation, but now I >can't find the info. > Port-Limit=1 in DEFAULT user profile.

Brian, If you're using the Platypus billing system, I recommend RadiusNT by IEA Software (www.iea-software.com) . It runs as an NT service, uses very few resources, and is directly supported in the latest version of Platypus. We've been using it successfully for almost a year now, with very few problems. One note, the documentation is not very detailed, so unless you're pretty familiar with MS-SQL, it might not be for you. We have it authenticating directly from a view of our Platypus database and it works quite well. As for trial versions, IEA lets you download the full version, then gives you a trial key that will authenticate 100 times before you have to restart the service. Peter D. Mayer NetWalk Tech Support dmayer@netwalk.com -----Original Message----- > >I am keeping my eye on radiator as well. I just need to here more >feedback. We use the Platypus billing system, and Radiator output records >would have to be compatible. I like the 3Com VSA stuff in Radiator. I am >wondering if it has support for Postgres.......... > > > >/-------------------------- signal@shreve.net -----------------------------\ >| Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | >| Network Administrator | Perl, Linux | Web hosting, online stores, | >| ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | >| 89 CRX DX w/MPFI, lots of |-=*:Quake:*=-| http://www.shreve.net/ | >| mods/Homepage coming soon |LordSignal/SN| Quake server: 208.206.76.47 | >\-------------------------- 318-222-2638 x109 -----------------------------/

We are ready to buy some new boards for the Total Control. We have to choose between a HiPer DSP 30 channel (E1 Card Set) and some more quad modem cards used in conjunction with a dual PRI/E1 NAC. The question is: Since the modems are cheaper than the HiPer card, is this card more reliable, or more performant, than the dual PRI/E1 NAC + modems? Does the HiPer card needs some server or the Netserver PRI card can be used? TIA -vsv --- Stefanita Valcu Network Administrator, Dynamic Network Technologies Calea Victoriei 155, bl.D1, sc.7, et.3, sector 1, 71102, Bucuresti, Romania tel: +40-1-6590696, fax: +40-1-3122745, E-mail: vsv@dnt.ro

Is there anybody able to send me some sample configuration in order to make a link between a cisco and a TC, via Frame Relay? Are the cisco syncronous cables good for the TC, or I need different cables? Does the TC support RS.232 cables or only V.35 (as is written in the documentation)? TIA -vsv --- Stefanita Valcu Network Administrator, Dynamic Network Technologies Calea Victoriei 155, bl.D1, sc.7, et.3, sector 1, 71102, Bucuresti, Romania tel: +40-1-6590696, fax: +40-1-3122745, E-mail: vsv@dnt.ro

On Thu, 9 Jul 1998, Randy Cosby wrote: > Do you have the "hiper bundle" special available there? It's a full chassis > with two hiper cards, and is much cheaper than buying the cards by themselves. > We've bought a couple and just pulled the cards out of them and moved them to > another chassis to save shelf space. Now we have spare chassis, power > supplies, NMC's, and HiperARC's. No, we have two sepparate offerts, one for HiPer cards and the other for quad modem cards. No bundles. rgds -vsv --- Stefanita Valcu Network Administrator, Dynamic Network Technologies Calea Victoriei 155, bl.D1, sc.7, et.3, sector 1, 71102, Bucuresti, Romania tel: +40-1-6590696, fax: +40-1-3122745, E-mail: vsv@dnt.ro

Brian wrote: > > > > I am keeping my eye on radiator as well. I just need to here more > > > feedback. We use the Platypus billing system, and Radiator output records > > > would have to be compatible. I like the 3Com VSA stuff in Radiator. I am > > > wondering if it has support for Postgres.......... > > > > You might want to look at RadiusNT. I know Platypus supports it at > > the DB level (no text file import junk to worry about). The latest > > supports VSA attrbiutes and works with many different DB backends. > > NT has not proven itself a reliable enough platform, in most cases. I'm not looking for a holy or OS war. We have over a 1000 customers using RadiusNT world wide. If RadiusNT wasn't reliable or stable (and that includes NT itself) wouldn't something majorly have been brought up by now? -- Dale E. Reed Jr. (daler@iea-software.com) _________________________________________________________________ IEA Software, Inc. | RadiusNT, Emerald, and NT FAQs Internet Solutions for Today | http://www.iea-software.com

On Thu, 9 Jul 1998, Dale E. Reed Jr. wrote: > Brian wrote: > > > > I am keeping my eye on radiator as well. I just need to here more > > feedback. We use the Platypus billing system, and Radiator output records > > would have to be compatible. I like the 3Com VSA stuff in Radiator. I am > > wondering if it has support for Postgres.......... > > You might want to look at RadiusNT. I know Platypus supports it at > the DB level (no text file import junk to worry about). The latest > supports VSA attrbiutes and works with many different DB backends. > NT has not proven itself a reliable enough platform, in most cases. > -- > Dale E. Reed Jr. (daler@iea-software.com) > _________________________________________________________________ > IEA Software, Inc. | RadiusNT, Emerald, and NT FAQs > Internet Solutions for Today | http://www.iea-software.com > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > /-------------------------- signal@shreve.net -----------------------------\ | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | | Network Administrator | Perl, Linux | Web hosting, online stores, | | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | | 89 CRX DX w/MPFI, lots of |-=*:Quake:*=-| http://www.shreve.net/ | | mods/Homepage coming soon |LordSignal/SN| Quake server: 208.206.76.47 | \-------------------------- 318-222-2638 x109 -----------------------------/

42 used USR Sportsters, $35/each 60 serial modem cables (6 feet/9 feet) $2.0/each If anyone is interested in buying, please email me at pmlist@mitec.net Thanks.

Do you have a open ticket on this issue? krish \ T.S.V. Krishnan \ \ Network System Engineer \ ( : - : ) \ 3Com ............ \ ----------------------------------------------/ tkrishna@bubba.ae.usr.com ----------------------------/ http://interproc.ae.usr.com ----/ The Yadda Yadda Search - for simple anwers - http://interproc.ae.usr.com/tkb.html Any Sufficiently advanced bug is indistinguishable for a feature. - Rick Kulawiec On Fri, 10 Jul 1998, Terry Kennedy wrote: > Ok, we've running 8 DSP cards with the HiPer ARC's for about > 3 weeks now. We are much worse off than when we had the quads > and netservers only. Constant complaints of disconnections and no > connections. Are there any settings that can help this. I have already > upped the carrier loss times. > > How about header compression? > Is this something that might help to turn this off? > Should we turn off v.32 terbo like the quads? > > I bought the new equipment because I couldn't find anyone selling > the Netservers and Quads setup new. I don't mind new equipment > if it works at least as well as the old. ( the netservers/quads worked > great for us) By the way, anyone here of v.90 release date for the > HiPer DSp? > > This is a fairly simple setup. We have channelized T1 lines, not PRI > Most of our callers still have 33.6 modems, the rest mostly X2. Some > V.90. > > Anyone with ideas? I'd love some help with this one. > > Terry Kennedy > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Hi Randy, thanks for your interest in Radiator. Radiator is a full source code product. We sometimes make 30 day evaluation licenses available to selected ISPs. Before we could do that, we would need to know: 1. What is your proposed environment (hosts and NASs)? 2. What is your test plan? 3. What are your selection criteria? 4. If Radiator meets those criteria, will you be purchasing? Hope that helps Cheers. On Jul 9, 9:42am, Randy Cosby wrote: > Subject: (usr-tc) Radius recommendations > I have the unique opportunity of starting over with some new equipment, a new > users file, and a new radius in a few weeks. I'd like to do it right this time. > > I'm well versed with mysql, so Radiator looks very attractive to me. Is anyone > here using it yet? I have a hard time using any Unix software "sight-unseen". > Do you know if they offer any type of evaluations, even if we "deposit" our > credit card number with them for 30 days? How is performance compared > to Merit radius? > > Any other recommendations? I would like to stay with a FreeBSD based system. > > Thanks, > > Randy Cosby > iCable.net > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > >-- End of excerpt from Randy Cosby -- Mike McCauley mikem@open.com.au Open System Consultants Pty. Ltd Unix, Motif, C++, WWW 24 Bateman St Hampton, VIC 3188 Australia Consulting and development Phone, Fax: +61 3 9598-0985 http://www.open.com.au

On Jul 9, 2:41pm, Brian wrote: > Subject: Re: (usr-tc) Radius recommendations > On Thu, 9 Jul 1998, Randy Cosby wrote: > > > I have the unique opportunity of starting over with some new equipment, a new > > users file, and a new radius in a few weeks. I'd like to do it right this time. > > > > I'm well versed with mysql, so Radiator looks very attractive to me. Is anyone > > here using it yet? I have a hard time using any Unix software "sight-unseen". > > Do you know if they offer any type of evaluations, even if we "deposit" our > > credit card number with them for 30 days? How is performance compared > > to Merit radius? > > I am keeping my eye on radiator as well. I just need to here more > feedback. We use the Platypus billing system, and Radiator output records > would have to be compatible. I like the 3Com VSA stuff in Radiator. I am > wondering if it has support for Postgres.......... There is a postgres DBD driver for perl on CPAN. Radiator can use it without modification. -- Mike McCauley mikem@open.com.au Open System Consultants Pty. Ltd Unix, Motif, C++, WWW 24 Bateman St Hampton, VIC 3188 Australia Consulting and development Phone, Fax: +61 3 9598-0985 http://www.open.com.au

Ok, we've running 8 DSP cards with the HiPer ARC's for about 3 weeks now. We are much worse off than when we had the quads and netservers only. Constant complaints of disconnections and no connections. Are there any settings that can help this. I have already upped the carrier loss times. How about header compression? Is this something that might help to turn this off? Should we turn off v.32 terbo like the quads? I bought the new equipment because I couldn't find anyone selling the Netservers and Quads setup new. I don't mind new equipment if it works at least as well as the old. ( the netservers/quads worked great for us) By the way, anyone here of v.90 release date for the HiPer DSp? This is a fairly simple setup. We have channelized T1 lines, not PRI Most of our callers still have 33.6 modems, the rest mostly X2. Some V.90. Anyone with ideas? I'd love some help with this one. Terry Kennedy

OK. That's what the USR Top-Level Exec said April 28 in response to the 3COM Top 10 list that was sent to 3com several months ago. Due to the architecture of the Netserver, certain problems such as Quake Lag simply could not be 'fixed' past a certain point. What has happened? I haven't heard anything about an 'agressive' trade-up program. Has 3com dropped the ball? Are they working on this? Has something been done, and I just don't know about it? We would like to be able to tell our customers that these problems have been fixed. Thanks, Craig Thompson WingNET Internet Services, P.O. Box 3000 // Cleveland, TN 37320-3000 423-559-LINK (v) 423-559-5444 (f) http://www.wingnet.net The world of children's publishing is bunny eat bunny.

I see this error cropping up frequently in the X2 Status column in the Performance Monitor in the TCM. Other slots in the chasis show good X2 and v.90 connections. Just wondering what the problem could be, and whether a fix or configuration tweak will improve the connections. Quad modems at 5.10.9 4 MB NMC at 5.4.95 16 MB Netserver at 3.5.34 Thanks Walt Walter N. Gnann ISLC, Manager 843.770.1000 843.770.1002 (fax) wgnann@islc.net http://www.islc.net http://www.beaufortcomputerclub.org

Has anyone had any problems getting 3Com and Adtran ISDN modems to work with the Total Control Hubs? We attempted to get all ISDN calls terminate in the Quad Modems Yesterday (2059 Bundle). We promptly got complaints from some Adtran and 3Com ISDM Modem users saying they could not connect. Lee Reese ATLNET Support

> > I have the unique opportunity of starting over with some new equipment, a new > > users file, and a new radius in a few weeks. I'd like to do it right this time. > > > > I'm well versed with mysql, so Radiator looks very attractive to me. Is anyone > > here using it yet? I've been using Radiator with our TCs for some time now, and am extremely happy with it: 1) It works, and works well. 2) It's feature-rich. 3) It's well-written (in Perl) so adding/modifying features is straightforward. 4) Features are being added at a suprising rate (thanks, Mike!) Just when you thing you've got everything you need, someone comes up with a neat idea, and the author incorporates it into the next version -- often within weeks. 5) As a corolarry to (4) - whenever I hack something useful into the code, I send it to the author. Since he is receptive to adding new features, it will often become come a part of the next release, and I don't need to keep it as a "local mod." > > Do you know if they offer any type of evaluations, even if we "deposit" our > > credit card number with them for 30 days? If you contact them directly, you can probably arrange for this. > > How is performance compared to Merit radius? Because it's written in Perl, it uses considerably more memory and CPU than any C software. I was concerned about this at first, but found that it wasn't a problem, at least for us. (We're running it on a Sparc 10 under Solaris 2.5.1 with over 15K users.) In our environment, we'd probably be running several Merit daemons, where we can handle everything we need under a single Radiator process. (No mucking with the Radius ports on the TC's to allow all our daemons to run on one server.) We also like the fact that it runs on NT; occasionally we have need of that. > I am keeping my eye on radiator as well. I just need to here more > feedback. We use the Platypus billing system, and Radiator output records > would have to be compatible. I believe that the next release of Radiator will tie directly into the Platypus SQL db. You might want to contact the author (Mike McCauley - mikem@open.com.au) for details. > I like the 3Com VSA stuff in Radiator. I am wondering if it has support for > Postgres.......... Yup. Hope this helps. Feel free to contact me for more info. Phil Freed <pfreed@cybertours.com>

We,ve had this often. Whenever we tell the TELCO to check the customers line they always find a ground or some other type of interference. The TELCO usually gets it fixed. blake -----Original Message----- Sent: Friday, July 10, 1998 11:41 AM I see this error cropping up frequently in the X2 Status column in the Performance Monitor in the TCM. Other slots in the chasis show good X2 and v.90 connections. Just wondering what the problem could be, and whether a fix or configuration tweak will improve the connections. Quad modems at 5.10.9 4 MB NMC at 5.4.95 16 MB Netserver at 3.5.34 Thanks Walt Walter N. Gnann ISLC, Manager 843.770.1000 843.770.1002 (fax) wgnann@islc.net http://www.islc.net http://www.beaufortcomputerclub.org - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

At 10:22 PM 7/9/98 -0700, you wrote: >Brian wrote: >> >> > > I am keeping my eye on radiator as well. I just need to here more >> > > feedback. We use the Platypus billing system, and Radiator output records >> > > would have to be compatible. I like the 3Com VSA stuff in Radiator. I am >> > > wondering if it has support for Postgres.......... >> > >> > You might want to look at RadiusNT. I know Platypus supports it at >> > the DB level (no text file import junk to worry about). The latest >> > supports VSA attrbiutes and works with many different DB backends. >> >> NT has not proven itself a reliable enough platform, in most cases. > >I'm not looking for a holy or OS war. We have over a 1000 customers using >RadiusNT world wide. If RadiusNT wasn't reliable or stable (and that includes >NT itself) wouldn't something majorly have been brought up by now? No, because people outside the UNIX world are just used to crappy servers. John John Powell, President john@jetcity.com Jet City Online http://www.jetcity.com Business Office: 206-281-1774 Customer Service: 425-820-7006, 1-888-747-6464

All, I have the following TC Netserver (2 PRI's into it, 12 quadcards in) "Total Control (tm) NETServer Card V.34/ISDN with Frame Relay V3.4.23" I have a customer who wants to bond two B channels dialing in with an Ascend Pipeline. Unfortunately, he happens to be the first of our customers to want this, and some questions have arisen. 1/ Does the TC Netserver support MLPPP out of the box, or do we have to explicitly enable it? 2/ In this case, all of our ports will answer either ISDN or POTS calls and assign addresses out of a pool. Will this work with a dual-B connection? I'm sure these are trivial questions, but if someone could answer the questions abovem or give me a pointer to the relevant documentation, I would greatly appreciate it!

John Powell wrote: > > >> NT has not proven itself a reliable enough platform, in most cases. > > > >I'm not looking for a holy or OS war. We have over a 1000 customers using > >RadiusNT world wide. If RadiusNT wasn't reliable or stable (and that > includes > >NT itself) wouldn't something majorly have been brought up by now? > > No, because people outside the UNIX world are just used to crappy servers. Your response proves your ignorance to this. We have customers using RadiusNT in large scale distributed client/server implementations with over 100,000 users. They are not "outside the UNIX world" and are not "used to crappy servers". Just because MS can't program a DNS server or some other applications on NT didn't meet your needs, don't assume RadiusNT isn't stable or reliable. -- Dale E. Reed Jr. (daler@iea-software.com) _________________________________________________________________ IEA Software, Inc. | RadiusNT, Emerald, and NT FAQs Internet Solutions for Today | http://www.iea-software.com

On Fri, 10 Jul 1998, Walt Gnann wrote: > I see this error cropping up frequently in the X2 Status column in the > Performance Monitor in the TCM. Other slots in the chasis show good X2 and > v.90 connections. Just wondering what the problem could be, and whether a > fix or configuration tweak will improve the connections. That's a phone line impairment at the user's end -- probably an extra D/A conversion. Their speed is probably topping out in the 24K to 28.8K range too. There's nothing you can do about it at your end. Mike Andrews (MA12) icq 6602506 -------------- mandrews@dcr.net Senior Systems/Network Administrator --- mandrews@termfrost.org Digital Crescent, Frankfort, KY ----- http://www.termfrost.org/ "Eagles may soar, but weasels don't get sucked into jet engines." -----BEGIN GEEK CODE BLOCK----- Version: 3.1 GCS/MU d- s: a- C++ UBX++++ P++ L+ !E W+++ N++ K++ w--- O+ M+ V+++ PS+++ PE- Y+ !t !5 !X !R tv- b+ DI++ D++ e++ h++ r++ y++*@ -----END GEEK CODE BLOCK-----

All, Just recieved 5th new chassis (bundle with 2 DSP's) On this one nmc run/fail stays red after booting. Changed the card with spare, same thing. The first 4 racks, which we quickly assembled into 2 racks with dual power and 4 DSP's exibited this when power supplies were installed but only one was powered up. Do these racks expect tosee 2 power supplies to keep nmc from running with an error. Other than the led, everything appears to work fine. Terry Kennedy

Forwarded from Radiator mailing list by mikem: --- Forwarded mail from Stephan Forseilles <sf@skynet.be> >--- Forwarded mail from usr-tc@lists.xmission.com > >Date: Thu, 9 Jul 1998 09:42:03 -0600 (MDT) >From: Randy Cosby <dcosby@infowest.com> >To: USR-TC@lists.xmission.com >Subject: (usr-tc) Radius recommendations >Reply-To: usr-tc@lists.xmission.com > >I have the unique opportunity of starting over with some new equipment, a new >users file, and a new radius in a few weeks. I'd like to do it right this >time. > >I'm well versed with mysql, so Radiator looks very attractive to me. Is anyone >here using it yet? I have a hard time using any Unix software "sight-unseen". >Do you know if they offer any type of evaluations, even if we "deposit" our >credit card number with them for 30 days? How is performance compared >to Merit radius? I use radiator on Linux and Digital Unix, with MySQL and USR TC (as well as CISCO 5200). It works, it's fast and support is a dream. What to ask more? (Uuuuuuh a red corvette?) ;-) -- Mike McCauley mikem@open.com.au Open System Consultants Pty. Ltd Unix, Motif, C++, WWW 24 Bateman St Hampton, VIC 3188 Australia Consulting and development Phone, Fax: +61 3 9598-0985 http://www.open.com.au

Mike Andrews was heard to say: >On Fri, 10 Jul 1998, Walt Gnann wrote: > >> I see this error cropping up frequently in the X2 Status column in the >> Performance Monitor in the TCM. Other slots in the chasis show good X2 and >> v.90 connections. Just wondering what the problem could be, and whether a >> fix or configuration tweak will improve the connections. > >That's a phone line impairment at the user's end -- probably an extra D/A >conversion. Their speed is probably topping out in the 24K to 28.8K range >too. There's nothing you can do about it at your end. Really? I've seen this on a PRI chassis dialing back to itself... where there ain't no D/A conversions. (FWIW) --Ricky

Has anyone heard when 3com will be release the V.90 code for the Hiper DSP cards? Thanks. Alan

On Thu, 9 Jul 1998, Dale E. Reed Jr. wrote: > Brian wrote: > > > > > > I am keeping my eye on radiator as well. I just need to here more > > > > feedback. We use the Platypus billing system, and Radiator output records > > > > would have to be compatible. I like the 3Com VSA stuff in Radiator. I am > > > > wondering if it has support for Postgres.......... > > > > > > You might want to look at RadiusNT. I know Platypus supports it at > > > the DB level (no text file import junk to worry about). The latest > > > supports VSA attrbiutes and works with many different DB backends. > > > > NT has not proven itself a reliable enough platform, in most cases. > > I'm not looking for a holy or OS war. We have over a 1000 customers using > RadiusNT world wide. If RadiusNT wasn't reliable or stable (and that includes > NT itself) wouldn't something majorly have been brought up by now? I understand your point, and I am sure you have a good product. I didn't mean to judge your product or make an assumption about it. I am mainly talking about MS NT. MS NT has not impressed me with its memory leaks, 10-20MB service packs, crashes, speed, etc. From an "integration" standpoint, unix is much more attractive to the ISP, since the vast majority are UNIX based. It allows us to easier communicate with programs, thru scripting, etc, and have more control over the enviroment. I was just making an opinion I'll admit. Some people embrace nt, I am one of the ones who don't. > > -- > Dale E. Reed Jr. (daler@iea-software.com) > _________________________________________________________________ > IEA Software, Inc. | RadiusNT, Emerald, and NT FAQs > Internet Solutions for Today | http://www.iea-software.com > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > /-------------------------- signal@shreve.net -----------------------------\ | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | | Network Administrator | Perl, Linux | Web hosting, online stores, | | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | | 89 CRX DX w/MPFI, lots of |-=*:Quake:*=-| http://www.shreve.net/ | | mods/Homepage coming soon |LordSignal/SN| Quake server: 208.206.76.47 | \-------------------------- 318-222-2638 x109 -----------------------------/

At 04:23 PM 7/10/98 -0700, you wrote: >John Powell wrote: >> >> >> NT has not proven itself a reliable enough platform, in most cases. >> > >> >I'm not looking for a holy or OS war. We have over a 1000 customers using >> >RadiusNT world wide. If RadiusNT wasn't reliable or stable (and that >> includes >> >NT itself) wouldn't something majorly have been brought up by now? >> >> No, because people outside the UNIX world are just used to crappy servers. > >Your response proves your ignorance to this. We have customers using RadiusNT >in large scale distributed client/server implementations with over 100,000 >users. They are not "outside the UNIX world" and are not "used to crappy >servers". > >Just because MS can't program a DNS server or some other applications on >NT didn't meet your needs, don't assume RadiusNT isn't stable or reliable. Hey, absence of evidence is not evidence of absence. One possible (and likely) explanation for the lack of negative response from your customers is that they don't expect any better. People don't expect much from NT, so they don't report to you when the server crashes. Why should they? They know it will. We make our NT server auto reboot every night, so then at least we _know_ when it will be down. John John Powell, President john@jetcity.com Jet City Online http://www.jetcity.com Business Office: 206-281-1774 Customer Service: 425-820-7006, 1-888-747-6464

-> > -> >I'm not looking for a holy or OS war. We have over a 1000 customers using -> >RadiusNT world wide. If RadiusNT wasn't reliable or stable (and that -> includes -> >NT itself) wouldn't something majorly have been brought up by now? -> No, because people outside the UNIX world are just used to crappy servers. Get a life... Jeff Binkley ASA Network Computing

-> Just because MS can't program a DNS server or some other applications on NT -> didn't meet your needs, don't assume RadiusNT isn't stable or reliable. Dale, Actually we run Microsoft's native DNS as a secondary domain controller for over 50+ domains with it being the primary DNS for out customers (we tell them to hit this one first) with over 100,000+ lookups per day, with no problems. I'd hardly say we have a problem... Now I can't speak for this person though but it does work in the real world on the Internet as an ISP resource... Jeff Binkley ASA Network Computing

How can I configure my Livingston Radius to log the connection speed of the customers connected to my TCs. - Marcelo

Just thought I'd throw this out while we're on the topic. Theres a freeware GNU C/C++ compiler for windows called gnu-win32 which will let you compile most unix apps on your NT/95 box with minimum or no porting at all: http://www.cygnus.com/gnu-win32/ So for example you could compiled bind (named) to run a nameserver, sendmail, qmail, etc, or whatever other services you want to run. In fact you can even set up a shell system (bash/tcsh, ftp, telnet, blah) if you care to :) The compiler comes with bash precompiled actually so you feel like you're in unix from the get go. - lv

You have to rewrite the code to include the vendor specific attributes. krish \ T.S.V. Krishnan \ \ Network System Engineer \ ( : - : ) \ 3Com ............ \ ----------------------------------------------/ tkrishna@bubba.ae.usr.com ----------------------------/ http://interproc.ae.usr.com ----/ The Yadda Yadda Search - for simple anwers - http://interproc.ae.usr.com/tkb.html Any Sufficiently advanced bug is indistinguishable for a feature. - Rick Kulawiec On Fri, 10 Jul 1998, Marcelo Souza wrote: > > How can I configure my Livingston Radius to log the connection > speed of the customers connected to my TCs. > > > - Marcelo > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

On Sat, 11 Jul 1998, Jeff Mcadams wrote: > Thus spake Jamie Orzechowski > >BTW: I was talking with a USR Level 2 support guy and he sais NETServers > >will become unsupported this christmas ... but they will have an AMAZING > >deal on HiPER ARC's because they are going to force the end users to upgrade > >... so I guess that's a good thing ... =) > > Say WHAT?! You *are* kidding us, right? I hope? If USR/3Com pulls > support for the Netservers by Christmas, I for one will start screaming > bloody murder and cozy up really nice with my local Cisco rep. That is > unless they make some *phenomenal* improvements to the HiPer equipment > from what I've seen. At this point, the HiPer stuff just isn't up to > snuff for what we use it for, our setup *requires* some of the protocol > support that the netservers have that the HiPer doesn't at this point > (yeah, yeah, its in beta, I know) and I have serious doubts that the > support for these protocols (MPIP in specific) will be ready for prime > time and still leave us enough time to get all of our equipment switched > over...This isn't even considering the cost of upgrading (even with an > AMAZING deal, it will still cost us money, how much you want to bet?) > I am not sure about this - Yes the HiPer arc in beta does support everything that the NETServer does and much more. Why don't you give it a try. regards krish > Someone please tell me that this is a miscommunication somewhere along > the way. > -- > Jeff McAdams Email: jeffm@iglou.com > Head Network Administrator Voice: (502) 966-3848 > IgLou Internet Services (800) 436-4456 > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

On Fri, 10 Jul 1998, Jeff Binkley wrote: > -> Just because MS can't program a DNS server or some other applications on NT > -> didn't meet your needs, don't assume RadiusNT isn't stable or reliable. > > Dale, > > Actually we run Microsoft's native DNS as a secondary domain controller for > over 50+ domains with it being the primary DNS for out customers (we tell them > to hit this one first) with over 100,000+ lookups per day, with no problems. > I'd hardly say we have a problem... Now I can't speak for this person though > but it does work in the real world on the Internet as an ISP resource... > Microsoft doesn't use MS DNS, so that right there gives me a red flag. They have since up'ed security, but I always got a laugh out of telnetting to atbd.microsoft.com (there primary dns), and seeing the UNIX issue file. > Jeff Binkley > ASA Network Computing > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > /-------------------------- signal@shreve.net -----------------------------\ | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | | Network Administrator | Perl, Linux | Web hosting, online stores, | | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | | 89 CRX DX w/MPFI, lots of |-=*:Quake:*=-| http://www.shreve.net/ | | mods/Homepage coming soon |LordSignal/SN| Quake server: 208.206.76.47 | \-------------------------- 318-222-2638 x109 -----------------------------/

John Powell wrote: > >> >> NT has not proven itself a reliable enough platform, in most cases. > >> > > >> >I'm not looking for a holy or OS war. We have over a 1000 customers using > >> >RadiusNT world wide. If RadiusNT wasn't reliable or stable (and that > >> includes > >> >NT itself) wouldn't something majorly have been brought up by now? > >> > >> No, because people outside the UNIX world are just used to crappy servers. > > > >Your response proves your ignorance to this. We have customers using > RadiusNT > >in large scale distributed client/server implementations with over 100,000 > >users. They are not "outside the UNIX world" and are not "used to crappy > >servers". > > > >Just because MS can't program a DNS server or some other applications on > >NT didn't meet your needs, don't assume RadiusNT isn't stable or reliable. > > Hey, absence of evidence is not evidence of absence. One possible (and > likely) explanation for the lack of negative response from your customers > is that they don't expect any better. People don't expect much from NT, so > they don't report to you when the server crashes. Why should they? They > know it will. We make our NT server auto reboot every night, so then at > least we _know_ when it will be down. But I didn't say our customers don't report problems. No software package is perfect and we have to update and resolve problems like all the others. I said "if RadiusNT wasn't reliable or stable, wouldn't soemthing major have been brought up by now". That means if WindowsNT couldn't take the load, or RadiusNT had major problems, then our customers would not be able to use our software. Our customers have the same high demands and expectations out of their mission critical applications that you do. Don't assume they settle for some "crappy" software, because I'll be the first to correct you: they don't. BTW, I have many WindowsNT mission critical machines here running from SQL Server to RadiusNT and DNS that haven't been rebooted in months. These are heavily used machines built correctly and work. This is NOT an exception as most of out customer can atest to this as well. -- Dale E. Reed Jr. (daler@iea-software.com) _________________________________________________________________ IEA Software, Inc. | RadiusNT, Emerald, and NT FAQs Internet Solutions for Today | http://www.iea-software.com

On Fri, 10 Jul 1998, John Powell wrote: > At 04:23 PM 7/10/98 -0700, you wrote: > >John Powell wrote: > >> > >> >> NT has not proven itself a reliable enough platform, in most cases. > >> > > >> >I'm not looking for a holy or OS war. We have over a 1000 customers using > >> >RadiusNT world wide. If RadiusNT wasn't reliable or stable (and that > >> includes > >> >NT itself) wouldn't something majorly have been brought up by now? > >> > >> No, because people outside the UNIX world are just used to crappy servers. > > > >Your response proves your ignorance to this. We have customers using > RadiusNT > >in large scale distributed client/server implementations with over 100,000 > >users. They are not "outside the UNIX world" and are not "used to crappy > >servers". > > > >Just because MS can't program a DNS server or some other applications on > >NT didn't meet your needs, don't assume RadiusNT isn't stable or reliable. > > Hey, absence of evidence is not evidence of absence. One possible (and > likely) explanation for the lack of negative response from your customers > is that they don't expect any better. People don't expect much from NT, so > they don't report to you when the server crashes. Why should they? They > know it will. We make our NT server auto reboot every night, so then at > least we _know_ when it will be down. indeed NT is "young". AmigaOS was doing full pre-emptive multi-tasking back in 1986. I don't even think windows has made it to where Amiga was in 1986. UNIX of any type, is built on knowledge of 25+ years. Even just looking at BSD the code base started 15+ years ago, and was built upon networking and key concepts that are part of OS's today. MS operating systems never had very sound networking, and only recently have started scrambling to become more of what UNIX already is. To me, NT is a code kludge, bloated really bad. > > John > > John Powell, President john@jetcity.com > Jet City Online http://www.jetcity.com > Business Office: 206-281-1774 > Customer Service: 425-820-7006, 1-888-747-6464 > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > /-------------------------- signal@shreve.net -----------------------------\ | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | | Network Administrator | Perl, Linux | Web hosting, online stores, | | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | | 89 CRX DX w/MPFI, lots of |-=*:Quake:*=-| http://www.shreve.net/ | | mods/Homepage coming soon |LordSignal/SN| Quake server: 208.206.76.47 | \-------------------------- 318-222-2638 x109 -----------------------------/

-> We are running USR Radius (Ver. 5.5.3) under NT, and have expirienced that -> the Radius memory use increases over time. Starting at 6000 k and building -> up to 130000 k in about a week. -> -> Why is that ? -> -> Can it be stoped ? -> -> We are not running the service version of Radius, and the service is not -> installed. -> Our +1000 users, are kept in MS access, ver.7.0. Yep, it's a problem. Has been for the past couple of releases. 3Com is aware of it and thought they had it fixed in 5.5.3. I'd suggest nagging them about it again. I do a reboot every two weeks to avoid running out of memory. Right now I am attempting to upsize the database to MS SQL Server 6.5. I would have like to have used our Sybase 11.5 server but 3Com was so kind to use field names longer than 30 characters in their schema, which Sybase won't handle. Jeff Binkley ASA Network Computing

-> > -> > Hey, absence of evidence is not evidence of absence. One possible (and > -> likely) explanation for the lack of negative response from your customers > -> is that they don't expect any better. People don't expect much from NT, so > -> they don't report to you when the server crashes. Why should they? They > -> know it will. We make our NT server auto reboot every night, so then at > -> least we _know_ when it will be down. -> -> indeed NT is "young". AmigaOS was doing full pre-emptive multi-tasking back -> in 1986. I don't even think windows has made it to where Amiga was in 1986. -> UNIX of any type, is built on knowledge of 25+ years. Even just looking at -> BSD the code base started 15+ years ago, and was built upon networking and -> key concepts that are part of OS's today. MS operating systems never had -> very sound networking, and only recently have started scrambling to become -> more of what UNIX already is. -> -> To me, NT is a code kludge, bloated really bad. I'm going to drop out of this thread because I've been down this road far too many times before and there is no end in sight. I'd expect Dale would prefer to see the listserv put to better use than this. I'll just agree to disagree and leave it at that ... Jeff Binkley ASA Network Computing

The bundles run about $10,000 here in the states. At 04:49 PM 7/11/98 +0200, you wrote: >I am from Denmark, and my company are currently using the "OLD" TC's. We are >about to buy some more, and I would like to know what kind of pricing you >guys get. > >What is the price for the Hiper Bundle you all talk about ? > >We have been offered some very good prices on some of the "OLD" TC's, but we >would rather like some of the New Hiper stuff. > >Does any of you have some recomendations, as to what we should select - NEW >Hiper or "OLD" standard. > >Some one told me a while back, that 3com has stoped developing for the "OLD" >chassis, is that true ? > > >Venlig hilsen / Best regards > >Nicolaj Ottsen >no@tjantik.dk >Tjantik ApS > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > | Peter A. Clausen | Cornerstone Networks | | peter@cstone.net | 410 East Water Street | | 804-984-5600 | Charlottesville, VA | | 800-325-9848 | http://www.cstone.net/ |

Does this same problem occur in the service version of the program?? Jeff Binkley wrote: > -> We are running USR Radius (Ver. 5.5.3) under NT, and have expirienced that > -> the Radius memory use increases over time. Starting at 6000 k and building > -> up to 130000 k in about a week. > -> > -> Why is that ? > -> > -> Can it be stoped ? > -> > -> We are not running the service version of Radius, and the service is not > -> installed. > -> Our +1000 users, are kept in MS access, ver.7.0. > > Yep, it's a problem. Has been for the past couple of releases. 3Com > is aware of it and thought they had it fixed in 5.5.3. I'd suggest > nagging them about it again. I do a reboot every two weeks to avoid > running out of memory. Right now I am attempting to upsize the database > to MS SQL Server 6.5. I would have like to have used our Sybase 11.5 > server but 3Com was so kind to use field names longer than 30 characters > in their schema, which Sybase won't handle. > > Jeff Binkley > ASA Network Computing > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message.

On Sat, 11 Jul 1998, Jeff Binkley wrote: > -> We are running USR Radius (Ver. 5.5.3) under NT, and have expirienced that > -> the Radius memory use increases over time. Starting at 6000 k and building > -> up to 130000 k in about a week. > -> > -> Why is that ? > -> > -> Can it be stoped ? > -> > -> We are not running the service version of Radius, and the service is not > -> installed. > -> Our +1000 users, are kept in MS access, ver.7.0. > > Yep, it's a problem. Has been for the past couple of releases. 3Com > is aware of it and thought they had it fixed in 5.5.3. I'd suggest > nagging them about it again. I do a reboot every two weeks to avoid > running out of memory. Right now I am attempting to upsize the database > to MS SQL Server 6.5. I would have like to have used our Sybase 11.5 > server but 3Com was so kind to use field names longer than 30 characters > in their schema, which Sybase won't handle. So the USR Radius will log to other Datbases besides Access (such as Ms sql, etc?). I didn't know it had that capibility, I thought it worked only with Access. > > Jeff Binkley > ASA Network Computing > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > /-------------------------- signal@shreve.net -----------------------------\ | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | | Network Administrator | Perl, Linux | Web hosting, online stores, | | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | | 89 CRX DX w/MPFI, lots of |-=*:Quake:*=-| http://www.shreve.net/ | | mods/Homepage coming soon |LordSignal/SN| Quake server: 208.206.76.47 | \-------------------------- 318-222-2638 x109 -----------------------------/

On Sat, 11 Jul 1998, Nicolaj Ottsen wrote: > Thanks for your answer, > > If it is not to much work for you, please report back to the list or > directly to me , with your expirences on upsizing to MS SQL 6.5. I myself > have been wanting to do that for a long time but never got around to it. > > Now that we are on the Radius subject, I have a question on Radius > authentication time. > > On my system it takes about 7-10 sec in averege to authenticate a user, this > is from the time where the modems have finished handshaking, to the users > modem/adapter is registred on the network. > > First of all I find the to be rather slow, and second of all it seems like > most og the time spend, is spend by the Netserver and not the Radius server. > > It take about 2-5 sec for the netserver to send an authentication requets to > the Radius. > > Is that normal ? I think telling your ARC/netserver to try PAP authentication first would help. I think by default it tries chap first, which is one more needless step if all you run is pap. Brian > > Venlig hilsen / Best regards > > Nicolaj Ottsen > no@tjantik.dk > Tjantik ApS > > > -----Original Message----- > > From: owner-usr-tc@lists.xmission.com > > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Jeff Binkley > > Sent: Saturday, July 11, 1998 18:33 > > To: usr-tc@lists.xmission.com > > Subject: (usr-tc) Memory leak in USR Radius ? > > > > > > -> We are running USR Radius (Ver. 5.5.3) under NT, and have > > expirienced that > > -> the Radius memory use increases over time. Starting at 6000 k > > and building > > -> up to 130000 k in about a week. > > -> > > -> Why is that ? > > -> > > -> Can it be stoped ? > > -> > > -> We are not running the service version of Radius, and the > > service is not > > -> installed. > > -> Our +1000 users, are kept in MS access, ver.7.0. > > > > Yep, it's a problem. Has been for the past couple of releases. 3Com > > is aware of it and thought they had it fixed in 5.5.3. I'd suggest > > nagging them about it again. I do a reboot every two weeks to avoid > > running out of memory. Right now I am attempting to upsize the database > > to MS SQL Server 6.5. I would have like to have used our Sybase 11.5 > > server but 3Com was so kind to use field names longer than 30 characters > > in their schema, which Sybase won't handle. > > > > Jeff Binkley > > ASA Network Computing > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > /-------------------------- signal@shreve.net -----------------------------\ | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | | Network Administrator | Perl, Linux | Web hosting, online stores, | | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | | 89 CRX DX w/MPFI, lots of |-=*:Quake:*=-| http://www.shreve.net/ | | mods/Homepage coming soon |LordSignal/SN| Quake server: 208.206.76.47 | \-------------------------- 318-222-2638 x109 -----------------------------/

Set the Port Limit to 1, under the PPP settings. Venlig hilsen / Best regards Nicolaj Ottsen no@tjantik.dk Tjantik ApS > -----Original Message----- > From: owner-usr-tc@lists.xmission.com > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Jay Nitikman > Sent: Thursday, July 09, 1998 22:09 > To: usr-tc@lists.xmission.com > Subject: (usr-tc) limiting ISDN to a single B-channel > > > I'm trying to limit ISDN to a a single B-channel via RADIUS. How do I > do this? I thought I once saw this in 3COM documentation, but now I > can't find the info. > > -- > Jay Nitikman (jay@cruzio.com) > Cruzio is a mom and pop Internet Service Provider > Web: http://www.cruzio.com Email: info@cruzio.com Voice: 423-1162 > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

We are running USR Radius (Ver. 5.5.3) under NT, and have expirienced that the Radius memory use increases over time. Starting at 6000 k and building up to 130000 k in about a week. Why is that ? Can it be stoped ? We are not running the service version of Radius, and the service is not installed. Our +1000 users, are kept in MS access, ver.7.0. Venlig hilsen / Best regards Nicolaj Ottsen no@tjantik.dk Tjantik ApS

I am from Denmark, and my company are currently using the "OLD" TC's. We are about to buy some more, and I would like to know what kind of pricing you guys get. What is the price for the Hiper Bundle you all talk about ? We have been offered some very good prices on some of the "OLD" TC's, but we would rather like some of the New Hiper stuff. Does any of you have some recomendations, as to what we should select - NEW Hiper or "OLD" standard. Some one told me a while back, that 3com has stoped developing for the "OLD" chassis, is that true ? Venlig hilsen / Best regards Nicolaj Ottsen no@tjantik.dk Tjantik ApS

Nicolaj Ottsen wrote: > > If it is not to much work for you, please report back to the list or > directly to me , with your expirences on upsizing to MS SQL 6.5. I myself > have been wanting to do that for a long time but never got around to it. RadiusNT has full support for SQL Server, Sybase, and Oracle. And it doesn't have a memory leak. :) -- Dale E. Reed Jr. (daler@iea-software.com) _________________________________________________________________ IEA Software, Inc. | RadiusNT, Emerald, and NT FAQs Internet Solutions for Today | http://www.iea-software.com

-> If it is not to much work for you, please report back to the list or -> directly to me , with your expirences on upsizing to MS SQL 6.5. I myself -> have been wanting to do that for a long time but never got around to it. -> Now that we are on the Radius subject, I have a question on Radius -> authentication time. -> -> On my system it takes about 7-10 sec in averege to authenticate a user, this -> is from the time where the modems have finished handshaking, to the users -> modem/adapter is registred on the network. -> -> First of all I find the to be rather slow, and second of all it seems like -> most og the time spend, is spend by the Netserver and not the Radius server. -> -> It take about 2-5 sec for the netserver to send an authentication requets to -> the Radius. -> -> Is that normal ? -> -> Venlig hilsen / Best regards I've never timed it that colsely but from what I've seen in other conversations, that doesn't seem too far out. I'd expect slightly faster response times but not greatly faster. Jeff Binkley ASA Network Computing

-> > -> We are running USR Radius (Ver. 5.5.3) under NT, and have expirienced -> that -> > -> the Radius memory use increases over time. Starting at 6000 k and -> building -> > -> up to 130000 k in about a week. -> > -> -> > -> Why is that ? -> > -> -> > -> Can it be stoped ? -> > -> -> > -> We are not running the service version of Radius, and the service is -> not > -> installed. -> > -> Our +1000 users, are kept in MS access, ver.7.0. -> > -> > Yep, it's a problem. Has been for the past couple of releases. 3Com > -> is aware of it and thought they had it fixed in 5.5.3. I'd suggest > -> nagging them about it again. I do a reboot every two weeks to avoid > -> running out of memory. Right now I am attempting to upsize the database > -> to MS SQL Server 6.5. I would have like to have used our Sybase 11.5 > -> server but 3Com was so kind to use field names longer than 30 characters > -> in their schema, which Sybase won't handle. -> -> So the USR Radius will log to other Datbases besides Access (such as Ms sql, -> etc?). I didn't know it had that capibility, I thought it worked only with -> Access. Notice I said "attempting". I'll keep you posted. In theory it might work but when I tried it once before, I found they were using some MS Access Jet calls which weren't supported in SQL. This was a few releases back so I am trying it again. Jeff Binkley ASA Network Computing

I was just wondering if anyone had a HOWTO for getting the Total Control to run with MS ACCESS for radius??? I am running it on unix right now ... I tried MS ACCESS but never got it to even install ... if anyone knows a sitewith a howto or can explain it please do.. thanks! BTW: I was talking with a USR Level 2 support guy and he sais NETServers will become unsupported this christmas ... but they will have an AMAZING deal on HiPER ARC's because they are going to force the end users to upgrade ... so I guess that's a good thing ... =) -----Original Message----- >-> > -> We are running USR Radius (Ver. 5.5.3) under NT, and have expirienced >-> that >-> > -> the Radius memory use increases over time. Starting at 6000 k and >-> building >-> > -> up to 130000 k in about a week. >-> > -> >-> > -> Why is that ? >-> > -> >-> > -> Can it be stoped ? >-> > -> >-> > -> We are not running the service version of Radius, and the service is >-> not > -> installed. >-> > -> Our +1000 users, are kept in MS access, ver.7.0. >-> > >-> > Yep, it's a problem. Has been for the past couple of releases. 3Com > >-> is aware of it and thought they had it fixed in 5.5.3. I'd suggest > >-> nagging them about it again. I do a reboot every two weeks to avoid > >-> running out of memory. Right now I am attempting to upsize the database > >-> to MS SQL Server 6.5. I would have like to have used our Sybase 11.5 > >-> server but 3Com was so kind to use field names longer than 30 characters > >-> in their schema, which Sybase won't handle. >-> >-> So the USR Radius will log to other Datbases besides Access (such as Ms sql, >-> etc?). I didn't know it had that capibility, I thought it worked only with >-> Access. > >Notice I said "attempting". I'll keep you posted. In theory it >might work but when I tried it once before, I found they were >using some MS Access Jet calls which weren't supported in SQL. >This was a few releases back so I am trying it again. > > Jeff Binkley > ASA Network Computing > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Thanks for your answer, If it is not to much work for you, please report back to the list or directly to me , with your expirences on upsizing to MS SQL 6.5. I myself have been wanting to do that for a long time but never got around to it. Now that we are on the Radius subject, I have a question on Radius authentication time. On my system it takes about 7-10 sec in averege to authenticate a user, this is from the time where the modems have finished handshaking, to the users modem/adapter is registred on the network. First of all I find the to be rather slow, and second of all it seems like most og the time spend, is spend by the Netserver and not the Radius server. It take about 2-5 sec for the netserver to send an authentication requets to the Radius. Is that normal ? Venlig hilsen / Best regards Nicolaj Ottsen no@tjantik.dk Tjantik ApS > -----Original Message----- > From: owner-usr-tc@lists.xmission.com > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Jeff Binkley > Sent: Saturday, July 11, 1998 18:33 > To: usr-tc@lists.xmission.com > Subject: (usr-tc) Memory leak in USR Radius ? > > > -> We are running USR Radius (Ver. 5.5.3) under NT, and have > expirienced that > -> the Radius memory use increases over time. Starting at 6000 k > and building > -> up to 130000 k in about a week. > -> > -> Why is that ? > -> > -> Can it be stoped ? > -> > -> We are not running the service version of Radius, and the > service is not > -> installed. > -> Our +1000 users, are kept in MS access, ver.7.0. > > Yep, it's a problem. Has been for the past couple of releases. 3Com > is aware of it and thought they had it fixed in 5.5.3. I'd suggest > nagging them about it again. I do a reboot every two weeks to avoid > running out of memory. Right now I am attempting to upsize the database > to MS SQL Server 6.5. I would have like to have used our Sybase 11.5 > server but 3Com was so kind to use field names longer than 30 characters > in their schema, which Sybase won't handle. > > Jeff Binkley > ASA Network Computing > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Thus spake Jamie Orzechowski >BTW: I was talking with a USR Level 2 support guy and he sais NETServers >will become unsupported this christmas ... but they will have an AMAZING >deal on HiPER ARC's because they are going to force the end users to upgrade >... so I guess that's a good thing ... =) Say WHAT?! You *are* kidding us, right? I hope? If USR/3Com pulls support for the Netservers by Christmas, I for one will start screaming bloody murder and cozy up really nice with my local Cisco rep. That is unless they make some *phenomenal* improvements to the HiPer equipment from what I've seen. At this point, the HiPer stuff just isn't up to snuff for what we use it for, our setup *requires* some of the protocol support that the netservers have that the HiPer doesn't at this point (yeah, yeah, its in beta, I know) and I have serious doubts that the support for these protocols (MPIP in specific) will be ready for prime time and still leave us enough time to get all of our equipment switched over...This isn't even considering the cost of upgrading (even with an AMAZING deal, it will still cost us money, how much you want to bet?) Someone please tell me that this is a miscommunication somewhere along the way. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

well ... I am not kidding .. I was asking about quake lag and he started talking about how the ppp stack code was 6 years old and would have to be completely redone ... he said NETServers will becom unsupported hardwas this christmas and they will FORCE users to upgrade to HiPERARC's by this "INCREDIBLE DEAL" and he mention INCREDIBLE many times =) ... but would give any prices ... he said they just want everyone to upgrade to HiPER ARC's ASAP ... guess that's the reason for the deal ... I don;t remeber his name but he was a level 2 support and a team leader also ... -----Original Message----- >Thus spake Jamie Orzechowski >>BTW: I was talking with a USR Level 2 support guy and he sais NETServers >>will become unsupported this christmas ... but they will have an AMAZING >>deal on HiPER ARC's because they are going to force the end users to upgrade >>... so I guess that's a good thing ... =) > >Say WHAT?! You *are* kidding us, right? I hope? If USR/3Com pulls >support for the Netservers by Christmas, I for one will start screaming >bloody murder and cozy up really nice with my local Cisco rep. That is >unless they make some *phenomenal* improvements to the HiPer equipment >from what I've seen. At this point, the HiPer stuff just isn't up to >snuff for what we use it for, our setup *requires* some of the protocol >support that the netservers have that the HiPer doesn't at this point >(yeah, yeah, its in beta, I know) and I have serious doubts that the >support for these protocols (MPIP in specific) will be ready for prime >time and still leave us enough time to get all of our equipment switched >over...This isn't even considering the cost of upgrading (even with an >AMAZING deal, it will still cost us money, how much you want to bet?) > >Someone please tell me that this is a miscommunication somewhere along >the way. >-- >Jeff McAdams Email: jeffm@iglou.com >Head Network Administrator Voice: (502) 966-3848 >IgLou Internet Services (800) 436-4456 > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

The easy way out is to configure it using quick setup. This can be done if you are at the console port. All you have to do is to setup the modems, the network, and the radius server You can also do this using cli with the following commands Modems: set cha slot < slot where the modem is > owner yes Network add ip network <name of the network> address <ipadd>/netmask add ip default gateway <ipaddress of the gateway> Radius server set authen primary_server <ipaddress> primary_secret <secret key> That is to it krish \ T.S.V. Krishnan \ \ Network System Engineer \ ( : - : ) \ 3Com ............ \ ----------------------------------------------/ tkrishna@bubba.ae.usr.com ----------------------------/ http://interproc.ae.usr.com ----/ The Yadda Yadda Search - for simple anwers - http://interproc.ae.usr.com/tkb.html Any Sufficiently advanced bug is indistinguishable for a feature. - Rick Kulawiec On Sun, 12 Jul 1998, Eric wrote: > Does anyone have a any information on configuring a HARC? I want to get > it to the point where it'll do RADIUS and just pick up some calls, then I > can play with the other settings. The HARC definitely has a lot more > settings than the NETServer. > > Eric > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

-> > -> > First of all I find the to be rather slow, and second of all it seems like -> > most og the time spend, is spend by the Netserver and not the Radius -> server. > -> > It take about 2-5 sec for the netserver to send an authentication requets -> to > the Radius. -> > -> > Is that normal ? -> -> I think telling your ARC/netserver to try PAP authentication first would -> help. I think by default it tries chap first, which is one more needless -> step if all you run is pap. I don't believe the Netservers do CHAP, only PAP. I could be mistaken though. Jeff Binkley ASA Network Computing

No you need no special routing to be done on the HiPer aRC, you do need an IP pool if you want the HiPer aRC to assign the IP address add ip pool in <ip add> size <number> This pool is default public so everyone will use it - now you need not assigne address from radius. Proxy for the pool address are done by default. krish \ T.S.V. Krishnan \ \ Network System Engineer \ ( : - : ) \ 3Com ............ \ ----------------------------------------------/ tkrishna@bubba.ae.usr.com ----------------------------/ http://interproc.ae.usr.com ----/ The Yadda Yadda Search - for simple anwers - http://interproc.ae.usr.com/tkb.html Any Sufficiently advanced bug is indistinguishable for a feature. - Rick Kulawiec On Sun, 12 Jul 1998, Jim Heng wrote: > Is there any special routing that needs to be done when setting up the ip > pool? > > > -----Original Message----- > From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com> > To: Eric <ELorenzo@MediaCity.com> > Cc: USR Total Control List <usr-tc@lists.xmission.com> > Date: Sunday, July 12, 1998 1:06 PM > Subject: Re: (usr-tc) HARC configuration? > > > >The easy way out is to configure it using quick setup. This can be done > >if you are at the console port. > > > >All you have to do is to setup the modems, the network, and the radius > server > > > >You can also do this using cli with the following commands > > > > > >Modems: > > > >set cha slot < slot where the modem is > owner yes > > > >Network > > > >add ip network <name of the network> address <ipadd>/netmask > >add ip default gateway <ipaddress of the gateway> > > > >Radius server > > > >set authen primary_server <ipaddress> primary_secret <secret key> > > > >That is to it > > > >krish > > > >----------------------------------------- > > \ T.S.V. Krishnan \ > > \ Network System Engineer \ ( : - : ) > > \ 3Com ............ \ > > ----------------------------------------------/ > >tkrishna@bubba.ae.usr.com > >----------------------------/ http://interproc.ae.usr.com ----/ > >The Yadda Yadda Search - for simple anwers - > http://interproc.ae.usr.com/tkb.html > >-------------------------------------------------------------------------\ > > Any Sufficiently advanced bug is indistinguishable for a feature. > > - Rick Kulawiec > >-------------------------------------------------------------------------/ > > > >On Sun, 12 Jul 1998, Eric wrote: > > > >> Does anyone have a any information on configuring a HARC? I want to get > >> it to the point where it'll do RADIUS and just pick up some calls, then I > >> can play with the other settings. The HARC definitely has a lot more > >> settings than the NETServer. > >> > >> Eric > >> > >> > >> - > >> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > >> with "unsubscribe usr-tc" in the body of the message. > >> For information on digests or retrieving files and old messages send > >> "help" to the same address. Do not use quotes in your message. > >> > > > >- > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Thus spake Tatai SV Krishnan >I am not sure about this - Yes the HiPer arc in beta does support >everything that the NETServer does and much more. Why don't you give it >a try. Replied to Tatai in private email...executive summary Because new software and hardware from networking vendors sucks and we refuse to use new software and hardware until its proven itself, and IMO, the HiPer Arc is far from having done that. Not mentioned in email... I kind of resent the suggestion that we try the HiPer when I've said flat out that we *can't* use this equipment yet because it doesn't have the protocol support we need. Trying it here would be, at this point, plugging it into a chassis and looking at the command line interface and not getting any useful service out of it. That is, unless you were suggesting I get ahold of the beta code for them, which I'd really rather not do. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

The tech at USR said they will stop supportig NETServers this christmas because the HiPER ARC code will be done and out of beta ... -----Original Message----- >Thus spake Tatai SV Krishnan >>I am not sure about this - Yes the HiPer arc in beta does support >>everything that the NETServer does and much more. Why don't you give it >>a try. > >Replied to Tatai in private email...executive summary > >Because new software and hardware from networking vendors sucks and we >refuse to use new software and hardware until its proven itself, and >IMO, the HiPer Arc is far from having done that. > >Not mentioned in email... > >I kind of resent the suggestion that we try the HiPer when I've said >flat out that we *can't* use this equipment yet because it doesn't have >the protocol support we need. Trying it here would be, at this point, >plugging it into a chassis and looking at the command line interface and >not getting any useful service out of it. That is, unless you were >suggesting I get ahold of the beta code for them, which I'd really >rather not do. >-- >Jeff McAdams Email: jeffm@iglou.com >Head Network Administrator Voice: (502) 966-3848 >IgLou Internet Services (800) 436-4456 > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Does anyone have a any information on configuring a HARC? I want to get it to the point where it'll do RADIUS and just pick up some calls, then I can play with the other settings. The HARC definitely has a lot more settings than the NETServer. Eric

NetServer cards do both chap and pap. You can set chap or pap to be attempted first. SET CHAPFST OFF/ON. SET PAP ON As far as how long it takes to send a request for authentication; it happens almost immediately. The lag is usually the time it takes to look up the username and password in whatever database you are running. The slower the network, the computer, and the database software the slower the response. An average authentication time would be close to 6-8 seconds, depending on the above conditions. If chap is used and/or attempted first the average could be closer to 8-11. jeff.binkley@asacomp.com (Jeff Binkley) on 07/12/98 12:55:00 AM Please respond to usr-tc@lists.xmission.com cc: -> > -> > First of all I find the to be rather slow, and second of all it seems like -> > most og the time spend, is spend by the Netserver and not the Radius -> server. > -> > It take about 2-5 sec for the netserver to send an authentication requets -> to > the Radius. -> > -> > Is that normal ? -> -> I think telling your ARC/netserver to try PAP authentication first would -> help. I think by default it tries chap first, which is one more needless -> step if all you run is pap. I don't believe the Netservers do CHAP, only PAP. I could be mistaken though. Jeff Binkley ASA Network Computing - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

If a second power supply is installed but not powered up you will always see a red hub status light. Other likely causes are exceeeding recommended operating temperatures, not plugging in the fan tray, or having a bad fan on the fan tray. Also, load TCM and see if any cards, front or back, are yellow. If so reboot/reseat. "Terry Kennedy" <terry@olypen.com> on 07/10/98 07:30:32 PM Please respond to usr-tc@lists.xmission.com cc: All, Just recieved 5th new chassis (bundle with 2 DSP's) On this one nmc run/fail stays red after booting. Changed the card with spare, same thing. The first 4 racks, which we quickly assembled into 2 racks with dual power and 4 DSP's exibited this when power supplies were installed but only one was powered up. Do these racks expect tosee 2 power supplies to keep nmc from running with an error. Other than the led, everything appears to work fine. Terry Kennedy - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

Keep in mind session limiting does not work unless you enable login tracking. If you want to make sure you have set up your RADIUS to do all types of accounting then set up your radius clients as follows: IP Addr Port Secret Type xxx.xxx.xxx.xxx 1645 xxxxxx NetServer 3.x or HiPer xxx.xxx.xxx.xxx 1646 " " xxx.xxx.xxx.xxx 1645 Accounting Server (for sucessful logins) xxx.xxx.xxx.xxx 1646 Accounting Server xxx.xxx.xxx.xxx 1646 NMC jeff.binkley@asacomp.com (Jeff Binkley) on 07/03/98 03:15:00 PM Please respond to usr-tc@lists.xmission.com cc: -> K Mitchell was heard to say: -> >I'm running a HiPer chassis/USR S&A Server and having trouble with my users -> >being unable to login, with the reported problem as; -> >[RADSERV] Failed login: username Maximum Sessions Exceeded -> >under an event ID of 43 -> >The only way I can allow them to log in is to delete the account and -> >re-enter it as a new account. I've not set any sort of session limit, other -> >than 1 concurrent session. Why is it doing this, and what can I do to stop -> it? -> -> Turn off concurrent session limiting... it doesn't work (and never has.) There are two other ways to solve this. Stop and restart the S/A server. This clears the session counters in the USERS table. The other option is to manually change the user's entry in the USERS table back to 0. Jeff Binkley ASA Network Computing - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

The timezone on the HiPer ARC is not currently configurable. It is GMT be default. Jay Nitikman <jay@cruzio.com> on 07/02/98 06:00:14 AM Please respond to usr-tc@lists.xmission.com cc: When I enable NTP on my HyperDSP the machine loads the wrong time. I suspect that this is a timezone issue. Is there a way to set the timezone of the router? -- Jay Nitikman (jay@cruzio.com) Cruzio is a mom and pop Internet Service Provider Web: http://www.cruzio.com Email: info@cruzio.com Voice: 423-1162 - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

You may have received a response on this already but here goes: set ip network xxxx routing_protocol ripv2 reconfigure ip network xxxx interface eth:1 save all Ernie Pritchard <elp@inline.com> on 07/01/98 09:00:21 PM Please respond to usr-tc@lists.xmission.com cc: How dos one enable ripv2 globally over the system? Were using radius to setup calls so there are no users on the arc database. Ive poured over the doc for the arc and ive turned on rip routing but as far as I can tell the only way to specify ripv2 is on a per network name basis. Any suggestions? Also im pretty sure that everything is ripv1 right now as sho ip network settings lists it as v1 and its listed that way in the harm. On the radius server theres only listen-broadcast nothing about v2 Thanks, Ernie Pritchard Inline Connections. - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

The upstream and downstream constellations on the AxCell card on the HUB can be configured. Correct values with ver 1.17 are 8,16,32,64,128,256,& 256uc. 8 is 1.544 (T1 bandwith) Ayan George <ayan@datasys.net> on 07/01/98 10:46:16 AM Please respond to usr-tc@lists.xmission.com cc: Would anyone be kind enough to explain what the dwn_constellation and up_constellation settings are and how they and the baud_rate effect overall throughput? The manuals don't seem to cover this. -Ayan - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

The exact name of the file is NSMGR342.zip You can look for it by name or click on software libray. Click on NetServer 8/16start search. Go to page 2 and look for file 27 of 40 David OBrien <growler@ac.net> on 06/30/98 03:19:38 PM Please respond to usr-tc@lists.xmission.com cc: Does this software exist, and where is it hidden? ;) I keep seeing references to it in the docs but in over 2 years of TC-ing have yet to actually see it. TIA Dave - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

Your question was not very specific but the best way to configure a HiPer ARC from scratch is to run quick setup. The best way to re-configure or quickly configure a HiPer ARC is to connect to the console and type delete config. Once the config has been deleted it will prompt you if you wish to run quick setup. You can also type _QUICKSETUP from the cli but deleting config has proven more reliable. "Eric" <ELorenzo@MediaCity.com> on 07/12/98 12:20:30 PM Please respond to usr-tc@lists.xmission.com cc: Does anyone have a any information on configuring a HARC? I want to get it to the point where it'll do RADIUS and just pick up some calls, then I can play with the other settings. The HARC definitely has a lot more settings than the NETServer. Eric - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

Is there any special routing that needs to be done when setting up the ip pool? -----Original Message----- Cc: USR Total Control List <usr-tc@lists.xmission.com> >The easy way out is to configure it using quick setup. This can be done >if you are at the console port. > >All you have to do is to setup the modems, the network, and the radius server > >You can also do this using cli with the following commands > > >Modems: > >set cha slot < slot where the modem is > owner yes > >Network > >add ip network <name of the network> address <ipadd>/netmask >add ip default gateway <ipaddress of the gateway> > >Radius server > >set authen primary_server <ipaddress> primary_secret <secret key> > >That is to it > >krish > >----------------------------------------- > \ T.S.V. Krishnan \ > \ Network System Engineer \ ( : - : ) > \ 3Com ............ \ > ----------------------------------------------/ >tkrishna@bubba.ae.usr.com >----------------------------/ http://interproc.ae.usr.com ----/ >The Yadda Yadda Search - for simple anwers - http://interproc.ae.usr.com/tkb.html >-------------------------------------------------------------------------\ > Any Sufficiently advanced bug is indistinguishable for a feature. > - Rick Kulawiec >-------------------------------------------------------------------------/ > >On Sun, 12 Jul 1998, Eric wrote: > >> Does anyone have a any information on configuring a HARC? I want to get >> it to the point where it'll do RADIUS and just pick up some calls, then I >> can play with the other settings. The HARC definitely has a lot more >> settings than the NETServer. >> >> Eric >> >> >> - >> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" >> with "unsubscribe usr-tc" in the body of the message. >> For information on digests or retrieving files and old messages send >> "help" to the same address. Do not use quotes in your message. >> > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

All, I've made this post pretty much verbatim on other lists. Maybe it's a good time for it now. Remember that personal perception is absolutely impossible to avoid in an industry as complex as that in which we make our livelihood. Let's take two engineers, each with the same knowledge level and roughly the same experience. Let's also take Product X and Product Y, two products which provide the same service. Odds are, when you ask the twoe ngineers what they thought, their answers will vary wildly. Maybe Engineer A had a rotten time installing Product X, or maybe Mr B had Product Y keep crashing and rebooting, etc etc ad nauseum. Point is, the VAST majority of "OS wars" on mailing lists come down to PERSONAL EXPERIENCE. And personal experience doesn't mean a lot as far as empirical evidence goes. personally, I've had bad experiences with Windows NT. I think it's a cutting edge OS that has a few years to go before it shakes the bugs out to an acceptable leve. BUT, I know people with as much knowledge or more than myself who have had nothing but success with Windows NT. So stop yelling, stop trying to force your preferences down someone else's throat, and stick to your area of expertise. If you ahte NT, why even respond to a thread that involves RadiusNT? And likewise UNIX, or whatever :P

On Fri, 10 Jul 1998, Marcelo Souza wrote: > > How can I configure my Livingston Radius to log the connection > speed of the customers connected to my TCs. > > > - Marcelo You will have to hack the server in order to support the Vendor Specific attributes from 3com. I succesfully hacked the Merit Radius, and now it supports all the stuff. If you think it is useful, drop me an E-mail and I'll send you the patch. rgds -vsv --- Stefanita Valcu Network Administrator, Dynamic Network Technologies Calea Victoriei 155, bl.D1, sc.7, et.3, sector 1, 71102, Bucuresti, Romania tel: +40-1-6590696, fax: +40-1-3122745, E-mail: vsv@dnt.ro

Sounds like the incredible deal will have to be a free trade in, because even then it wont be useful to all of us. - lv On Sat, 11 Jul 1998, Jamie Orzechowski wrote: > well ... I am not kidding .. I was asking about quake lag and he started > talking about how the ppp stack code was 6 years old and would have to be > completely redone ... he said NETServers will becom unsupported hardwas this > christmas and they will FORCE users to upgrade to HiPERARC's by this > "INCREDIBLE DEAL" and he mention INCREDIBLE many times =) ... but would give > any prices ... he said they just want everyone to upgrade to HiPER ARC's > ASAP ... guess that's the reason for the deal ... I don;t remeber his name > but he was a level 2 support and a team leader also ... > > -----Original Message----- > From: Jeff Mcadams <jeffm@iglou.com> > To: usr-tc@lists.xmission.com <usr-tc@lists.xmission.com> > Date: Saturday, July 11, 1998 10:12 PM > Subject: (usr-tc) Netservers becoming unsupported?! > > > >Thus spake Jamie Orzechowski > >>BTW: I was talking with a USR Level 2 support guy and he sais NETServers > >>will become unsupported this christmas ... but they will have an AMAZING > >>deal on HiPER ARC's because they are going to force the end users to > upgrade > >>... so I guess that's a good thing ... =) > > > >Say WHAT?! You *are* kidding us, right? I hope? If USR/3Com pulls > >support for the Netservers by Christmas, I for one will start screaming > >bloody murder and cozy up really nice with my local Cisco rep. That is > >unless they make some *phenomenal* improvements to the HiPer equipment > >from what I've seen. At this point, the HiPer stuff just isn't up to > >snuff for what we use it for, our setup *requires* some of the protocol > >support that the netservers have that the HiPer doesn't at this point > >(yeah, yeah, its in beta, I know) and I have serious doubts that the > >support for these protocols (MPIP in specific) will be ready for prime > >time and still leave us enough time to get all of our equipment switched > >over...This isn't even considering the cost of upgrading (even with an > >AMAZING deal, it will still cost us money, how much you want to bet?) > > > >Someone please tell me that this is a miscommunication somewhere along > >the way. > >-- > >Jeff McAdams Email: jeffm@iglou.com > >Head Network Administrator Voice: (502) 966-3848 > >IgLou Internet Services (800) 436-4456 > > > >- > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

So far, the HiperARC would be useless to us since we have trouble getting certain ISDN modems (Adtran & 3Com) to connect to the Quad modems. Unless I am mistaken, the HiPerARCS do not have ISDN on-board. Lee Laszlo Vecsey wrote: > Sounds like the incredible deal will have to be a free trade in, because > even then it wont be useful to all of us. > > - lv > > On Sat, 11 Jul 1998, Jamie Orzechowski wrote: > > > well ... I am not kidding .. I was asking about quake lag and he started > > talking about how the ppp stack code was 6 years old and would have to be > > completely redone ... he said NETServers will becom unsupported hardwas this > > christmas and they will FORCE users to upgrade to HiPERARC's by this > > "INCREDIBLE DEAL" and he mention INCREDIBLE many times =) ... but would give > > any prices ... he said they just want everyone to upgrade to HiPER ARC's > > ASAP ... guess that's the reason for the deal ... I don;t remeber his name > > but he was a level 2 support and a team leader also ... > > > > -----Original Message----- > > From: Jeff Mcadams <jeffm@iglou.com> > > To: usr-tc@lists.xmission.com <usr-tc@lists.xmission.com> > > Date: Saturday, July 11, 1998 10:12 PM > > Subject: (usr-tc) Netservers becoming unsupported?! > > > > > > >Thus spake Jamie Orzechowski > > >>BTW: I was talking with a USR Level 2 support guy and he sais NETServers > > >>will become unsupported this christmas ... but they will have an AMAZING > > >>deal on HiPER ARC's because they are going to force the end users to > > upgrade > > >>... so I guess that's a good thing ... =) > > > > > >Say WHAT?! You *are* kidding us, right? I hope? If USR/3Com pulls > > >support for the Netservers by Christmas, I for one will start screaming > > >bloody murder and cozy up really nice with my local Cisco rep. That is > > >unless they make some *phenomenal* improvements to the HiPer equipment > > >from what I've seen. At this point, the HiPer stuff just isn't up to > > >snuff for what we use it for, our setup *requires* some of the protocol > > >support that the netservers have that the HiPer doesn't at this point > > >(yeah, yeah, its in beta, I know) and I have serious doubts that the > > >support for these protocols (MPIP in specific) will be ready for prime > > >time and still leave us enough time to get all of our equipment switched > > >over...This isn't even considering the cost of upgrading (even with an > > >AMAZING deal, it will still cost us money, how much you want to bet?) > > > > > >Someone please tell me that this is a miscommunication somewhere along > > >the way. > > >-- > > >Jeff McAdams Email: jeffm@iglou.com > > >Head Network Administrator Voice: (502) 966-3848 > > >IgLou Internet Services (800) 436-4456 > > > > > >- > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > with "unsubscribe usr-tc" in the body of the message. > > > For information on digests or retrieving files and old messages send > > > "help" to the same address. Do not use quotes in your message. > > > > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message.

On Mon, 13 Jul 1998, Terry Kennedy wrote: > Krish, > how does one get a hold of the beta code? Is this code V.90? > > > I am not sure about this - Yes the HiPer arc in beta does support > everything that the NETServer does and much more. Why don't you give it > a try. > The Beta is for HiPer ARC and chassis products, yes it does include v.90 code on the dsp. Now you have to go to http://totalservice.usr.com There is a beta NDA - you can submit it on line. That will send you back an email with details - which you should send back to bata@elroy.usr.com Then you will be given an username and password to access the code. regards krish > regards > > krish > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

At 11:59 AM 7/12/98 -0500, Brian McIntire wrote: >Keep in mind session limiting does not work unless you enable login >tracking. If you want to make sure you have set up your RADIUS to do all >types of accounting then set up your radius clients as follows: > > >IP Addr Port Secret Type >xxx.xxx.xxx.xxx 1645 xxxxxx NetServer 3.x or HiPer >xxx.xxx.xxx.xxx 1646 " " >xxx.xxx.xxx.xxx 1645 Accounting Server (for sucessful logins) >xxx.xxx.xxx.xxx 1646 Accounting Server >xxx.xxx.xxx.xxx 1646 NMC Login tracking is enabled and the client is setup as above. The problem was not limiting sessions itself, but reporting session ends so that a later login doesn't get denied by radius, thinking that it's a 2nd concurrent session. After numerous reports of USR S&A server's inability to do this reliably, I've discontinued session limiting until radius can do what it's supposed to. Thanks, Kirk Kirk Mitchell-General Manager mitch@keyconn.net Keystone Connect http://www.keyconn.net ***** Providing quality internet services in central PA ***** ******* (814)941-5000 We unlock the world ********

>-----Original Message----- >From: owner-usr-tc@lists.xmission.com >[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Lee Reese >Sent: Sunday, July 12, 1998 7:59 PM >To: usr-tc@lists.xmission.com >Subject: Re: (usr-tc) Netservers becoming unsupported?! > > >So far, the HiperARC would be useless to us since we have trouble >getting certain >ISDN modems (Adtran & 3Com) to connect to the Quad modems. Unless I am >mistaken, the HiPerARCS do not have ISDN on-board. > > You are correct, HARC does not have the ability to terminate ISDN calls. That functionality was supplied on the netserver by a daughter board. If you are having problems with some ISDN TA's and the QUADS, do you have tickets open on those issues? -m

Krish, how does one get a hold of the beta code? Is this code V.90? I am not sure about this - Yes the HiPer arc in beta does support everything that the NETServer does and much more. Why don't you give it a try. regards krish

> The tech at USR said they will stop supportig NETServers this > christmas > because the HiPER ARC code will be done and out of beta ... I just called to check on this and the tech I spoke to said they are going to stop making them at the end of the year, but they are not going to stop supporting them. Of course I have been told stories before.... Any one of the 3Com people like to wade in on this? Steve Steve McConnell EMJ Internet 1434 Farrington Road 800-548-2319 Apex, NC 27502 919-363-4441 http://www.emji.net 919-363-4425 FAX

We had a similar experience with USR's Radius, with Access it just hogged memory something chronic and it got way out of hand. So we moved to RadiusNt using SQL and to be honest have not looked back once. Apart from SQL itself being more efficient RadiusNT does the job great, had no problems with it except for the standard learning curve with new software and its database access times are far quicker than USR's Security and Accounting Server also the support is good, I found 3Com support lacking when it came to Radius. The actual time it takes for a dial-up user to authenticate is just so much faster with RadiusNT and that first log on time is what the customer will see and if it is too long, will get annoyed with it, hell I did! ;) I'm not into OS wars, each to his own, but it does the job for us and that is what counts. Phil -----Original Message----- Sent: Saturday, July 11, 1998 6:03 PM Thanks for your answer, If it is not to much work for you, please report back to the list or directly to me , with your expirences on upsizing to MS SQL 6.5. I myself have been wanting to do that for a long time but never got around to it. Now that we are on the Radius subject, I have a question on Radius authentication time. On my system it takes about 7-10 sec in averege to authenticate a user, this is from the time where the modems have finished handshaking, to the users modem/adapter is registred on the network. First of all I find the to be rather slow, and second of all it seems like most og the time spend, is spend by the Netserver and not the Radius server. It take about 2-5 sec for the netserver to send an authentication requets to the Radius. Is that normal ? Venlig hilsen / Best regards Nicolaj Ottsen no@tjantik.dk Tjantik ApS > -----Original Message----- > From: owner-usr-tc@lists.xmission.com > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Jeff Binkley > Sent: Saturday, July 11, 1998 18:33 > To: usr-tc@lists.xmission.com > Subject: (usr-tc) Memory leak in USR Radius ? > > > -> We are running USR Radius (Ver. 5.5.3) under NT, and have > expirienced that > -> the Radius memory use increases over time. Starting at 6000 k > and building > -> up to 130000 k in about a week. > -> > -> Why is that ? > -> > -> Can it be stoped ? > -> > -> We are not running the service version of Radius, and the > service is not > -> installed. > -> Our +1000 users, are kept in MS access, ver.7.0. > > Yep, it's a problem. Has been for the past couple of releases. 3Com > is aware of it and thought they had it fixed in 5.5.3. I'd suggest > nagging them about it again. I do a reboot every two weeks to avoid > running out of memory. Right now I am attempting to upsize the database > to MS SQL Server 6.5. I would have like to have used our Sybase 11.5 > server but 3Com was so kind to use field names longer than 30 characters > in their schema, which Sybase won't handle. > > Jeff Binkley > ASA Network Computing > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

If the rumors I'm seeing on this and other lists are true, 3Com will discontinue support (software updates?) for the Netserver by the end of the year. Can anyone confirm/deny this? I have been buying the Hiper chassis for a while now, and have "spare" ARC's and NMC's, because I'm cramming the HDM's into one chassis. Would I be ahead to put my extra ARC's in my older Netserver-based boxes? Will I have problems with features (x2/v.90), or is the switchover pretty straightforward? Will this help with the dreaded "Quake Lag" problems? And.. Aplogies for starting the "Radius recommendations" thread - I did not intend it to go the direction it did. NT is just not an option for me at this time, and I'm quite pleased with FreeBSD. Nuthin' personal against Bill or anything. I'm just into open source software. I'm evaluating "Radiator", and so far, it looks very nice. I'm sure NTRadius is nice too. :) Thanks, Randy Cosby <dcosby@infowest.com> Vice President InfoWest Global Internet Services, Inc. (435)674-0165 http://www.infowest.com

Hi There .. I am trying to get the S&A server working here ... right now I have readius on UNIX ... I was just wondering this ... when I setup the S&A server, where does it read it's password from?? it's being ionstalled on a NT 4.0 server ... but all my passwords are on the unix machine ... can the S & A server read a /etc/password or do I have to sotre my users password on the NT box?? if they go onto the NT box HOW do I store them???? ...

Can you tell me which source file and function to hack so I can do my own hacking? Thanks, Jose -----Original Message----- [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Stefanita Valcu Sent: Sunday, July 12, 1998 5:15 AM On Fri, 10 Jul 1998, Marcelo Souza wrote: > > How can I configure my Livingston Radius to log the connection > speed of the customers connected to my TCs. > > > - Marcelo You will have to hack the server in order to support the Vendor Specific attributes from 3com. I succesfully hacked the Merit Radius, and now it supports all the stuff. If you think it is useful, drop me an E-mail and I'll send you the patch. rgds -vsv --- Stefanita Valcu Network Administrator, Dynamic Network Technologies Calea Victoriei 155, bl.D1, sc.7, et.3, sector 1, 71102, Bucuresti, Romania tel: +40-1-6590696, fax: +40-1-3122745, E-mail: vsv@dnt.ro - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

Thanks for the response. I don't think I clearly asked my question however. What I am looking for an a definition for ``constellation''. What is it? -Ayan On Sun, 12 Jul 1998, Brian McIntire wrote: > The upstream and downstream constellations on the AxCell card on the HUB > can be configured. > Correct values with ver 1.17 are 8,16,32,64,128,256,& 256uc. 8 is 1.544 > (T1 bandwith) > > > > > Ayan George <ayan@datasys.net> on 07/01/98 10:46:16 AM > > Please respond to usr-tc@lists.xmission.com > > To: usr-tc@lists.xmission.com > cc: > Subject: (usr-tc) ADSL Line Card Configuration > > > > > > Would anyone be kind enough to explain what the dwn_constellation and > up_constellation settings are and how they and the baud_rate effect > overall throughput? > > The manuals don't seem to cover this. > > -Ayan > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > > > > > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Hi, "In Call Failed on Slot 1, DS1 1, DS0 0, Cause Code 0" Does anyone see these in their traplogs? Hiper DSP, sw 1.1.1 + HARC. After some workdays DSP cards start getting such errors, customers would get busy signal. The only cure for some time is to hard-reset the DSP card. After a week they show up again, and eventually start appearing more often Strangely, this is somehow connected to Hiper-ARC, because in the same chassis, Netserver is servicing 3 DSP cards, and they give such errors much-much more rarely (although they do) any hint on where to look? ---------------------------------------------------------------------- Andres Kroonmaa mail: andre@online.ee Network Manager Organization: MicroLink Online Tel: 6308 909 Tallinn, Sakala 19 Pho: +372 6308 909 Estonia, EE0001 http://www.online.ee Fax: +372 6308 901 ----------------------------------------------------------------------

>... he said NETServers will becom unsupported hardwas this >christmas and they will FORCE users to upgrade to HiPERARC's ... Geesh... I just got used to the Netserver! :)

After recently upgrading to the Hiperarc with DSP modems we have experienced problems with our users that have telepath modems. Most can connect fine, some at 48,800 speeds and have no real disconnect problems. Only problem is it moves around like it is a 9600 connection. Has anyone else experienced this problem and is there a cure. I have heard telepaths don't like trashy phone lines could this be the only problem? I called 3Com tech support today and was only on hold the better part of 2 hours before I gave up and hung up. But hey I did enjoy Fleetwood Mac's, The Dance and part of REO Speedwagons greatest hits. I may call back tomorrow just to listen to The Glen Miller Orchestra!!! Greg Owens Magnolia InterNet Services

This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --416219727-687689762-900380434=:21534 Content-Type: TEXT/PLAIN; charset=US-ASCII Here you go, the source with modifications krish \ T.S.V. Krishnan \ \ Network System Engineer \ ( : - : ) \ 3Com ............ \ ----------------------------------------------/ tkrishna@bubba.ae.usr.com ----------------------------/ http://interproc.ae.usr.com ----/ The Yadda Yadda Search - for simple anwers - http://interproc.ae.usr.com/tkb.html Any Sufficiently advanced bug is indistinguishable for a feature. - Rick Kulawiec On Mon, 13 Jul 1998, Jose de Leon wrote: > Can you tell me which source file and function to hack so I can do my own > hacking? > > > Thanks, > Jose > > > -----Original Message----- > From: owner-usr-tc@lists.xmission.com > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Stefanita Valcu > Sent: Sunday, July 12, 1998 5:15 AM > To: usr-tc@lists.xmission.com > Subject: Re: (usr-tc) Livingston Radius and TC > > > On Fri, 10 Jul 1998, Marcelo Souza wrote: > > > > > How can I configure my Livingston Radius to log the connection > > speed of the customers connected to my TCs. > > > > > > - Marcelo > > You will have to hack the server in order to support the Vendor Specific > attributes from 3com. I succesfully hacked the Merit Radius, and now it > supports all the stuff. If you think it is useful, drop me an E-mail and > I'll send you the patch. > > rgds > > -vsv > --- > Stefanita Valcu > Network Administrator, Dynamic Network Technologies > Calea Victoriei 155, bl.D1, sc.7, et.3, sector 1, 71102, Bucuresti, Romania > tel: +40-1-6590696, fax: +40-1-3122745, E-mail: vsv@dnt.ro > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > --416219727-687689762-900380434=:21534 Content-Type: APPLICATION/octet-stream; name="radius.tar.gz" Content-Transfer-Encoding: BASE64 Content-ID: <Pine.LNX.3.91.980713204034.21534D@bubba.ae.usr.com> Content-Description: H4sICINgqzUCA3JhZGl1cy50YXIA7F1bc+JIsp5X8SvqRO/D7ESrrTvgiH3A IE+zYzAD2NPnvBACCqOwkFhJuO399ZtZkkC3KslnozvOmW3FxtKG+jLrkpmV mZWl+XT10zd/FMXQuqYJn4quaQZ+KqqRfKbPT4plmpplKZqi4fddw9R+Mn/6 Ds8pip0QWP77g4THUJJPtfvT/5Pn09WnzUvkPvlBSL/Z+quKYiXrXb/+KBuW rnRVQ9VMC75X4Wf4/LH+3/wJna17irYd+Dw6UYSfzmYTd9Yn19tu14dO2uAT /vunH8+f7fl0BQu8XX/TXeA99l9N9F8xdeuH/f+O6/8td4FG+6/raP/1rmqp ptHF9ddAGH7Y/+/weMHTzvVoZ+O51I+jzimiYdQ5UP/0w9r/J9n/dP0/Rc7h 6NHvq/+Glei/1dXhDx31H43BD/3/Ds+HzgdpuXcjglaAbAI/dlw/Ig7x3Cgm wY6kgkG+7t3NnjghJY7nBV/plsQBYA/OM3xzivfQyN04sRv4JKT/ONEIMI4P rfbUDQn1N+Hbkf36TN8+MaYUeIbAZOdSb0tcZPrieO6W7IMo9p0D/B6EiE/7 kKEiCt3cprCfI3qkoRNDf9ZvZO05/nNEEOaso78iUcQDsNKBzocho0qmwEmS fqNvnQ9y6ZHk6tPp/Kn1P6ag/zCd31f/tVT/DYj/Fab/4Av80P8f+v9/UP// nPv/1t3g5Djh2zf1/5NYL6//4PGbSrcc/+nf3f8PgyD+z9R/8pfP1NnS8Jpc vTjhVRScwg29gngQp+Qqyf9cYURQEZWPL0T9pBO13+9eKfqV1iOKcq2o14ZK Xp5DN9r7DrFfj+QvHcbmLni6JgU0/EDm9MWNUC+RVC2tMzFoPdhuQdWHwwGJ jnTj7twNWdLw4PrM9MgDRhzaDfeO/wQtZ6F7AF7MFC2Y4cC/RtMFid+OFMxD QNwjDCv8RAgal4fFHA3MKXTjN/hH+EJDoHbpNNk7zKYdiBORKA5d/yn6SNan mBmaKY0XDEO+BiewTn4Qw7/CZ/LVjffQIogoUAMrB/YxRwDMEbnfkz+o5/0X m6rcnGiXOVFMnBNDuzbr5sSJgRh0hCZ2dxMcDmxHLxNUM4LaldonmnqtdOsn GQfEVhyGH9JNHKTT6IJlx42CxYsl4laOuEE05VozrlW9QPyXX34h4GTA9ELs SQ40ipwnit+WaZkFWqp2DX3V+v87WkaZltq9Voq0hkGIo2QbG2xhOw/+IPPb YQTDMHts5PCPfpmyXqSsXJtA2SxQfjhunZQu0ENqZSJdRqR3pQCdHiFK/9pE 4SdxLZE7bTkj29DZxQQJdTh7eE5o49DxI4+pSMR21aMTRiB5ACxs1k/Ux80U foEZiI7QmkagGAPPS0g4m4QEuAEABRE7gkRv0U0YZNJ39YjSTWYO7O2pTjF5 x0bUQRciawkUoM+pGqMAw8bts3YGgbE6iYYCjUfmFVy+QvbXbNSJ/hCZKLJm 6iSA5UOZlBKVhu+N9Dvi+sSnMdPF9VsMXMItarbkghw/UWyqa2Ttxmlnofna fQK3Zes6ftKY/Lx3n/YJmjkufwU4rkkbrJx6LTBe19/g0PFBC4f/I79Olh8J +bvjw2jVjygMXYUN0PZPh9S9yawGeGAR6CJ8A4xQRzFlkyw9szKXZQf84+Du wa4uP3Ui0OUtmE3w8kL2w6eE3yuL/5PZHSyX8/HNw9KWYA2QEHxX8oYIIYlX 9EG6DcGR2sqzMIiDTeCRv5HZbAbfdyXpb0SVfs5mGjyxYAurBtPX6ZxZkOR5 gLHI6JGR4qOmn8mCV2AzJ4pgbbclFNHEsOHnwUyuweoNMOY4yuMyOyP9TKSP B5sFYRFrZrBkgurnBLcVd0PlJShA+r3VgCsvSPZ02+FgEwAbEF362RMPL4XB FnhwoucLrN8KNg9OzOxcVlxp1ctb14thei7zqarCtUthk+VDScC0VuyGYPJw VtBsJzhdjAOfx/XlzxDRlPgZwllJYOmi52FmG3bL4YyJWQ5nFXEfysB7b1un CUTtihUPhXmS7rt5WE8IG7mOt3Y2z/I0KM5KvyWsaCE0pQCrDA58UDexciXz kMoKWnGRYBaGpmltBGw8+4KqwDacBKaLjcMewmoKLqu8iJ0cQ81oMEVOXkUv MLMeJj3CthSAOUmdZ0nSLIlDe5HIubx0DxQm4UK7K5bB8dajFRDiemJc1Y9P cX0xbogzt2XzhtCzKdAV8dQBDL6v4HSxAZkOFtAUsx3gtIS5PUMsFmCFX99K a8tguhCW6PPdYFmyBbrREjYNtjmGutkS9msYnI4XmNVG5AdH8ByWjvcs37k+ Sr3ebbfRnHGZwui99+H+B/1GZNgXdXOw2cRsBU5RfhslRsNOw3Aj6jlvTKov 273aAjf2j6dYvk+c0BSntcDdn+Iy0NBb4DKlzTkYhlhWGGyQZfBy3oz5Dna5 iTGs1tMyA1t+GV63/bTkgUavBS6zLVQeOuAvM1y/BW5y8mI3N6mSqUiieUTJ Byfh5MeSZKoS12Sh43k2+Zc5t5RG28N23Lz4IqxBEhnmzj24JSfE0tp4E2gP kIIkWUVj9QGtGkTfadwT7VnOY03BW2dBxmYffCQK+7cfpH9u6c6BOYWYt7pN p9Qqj2WUnBfgnG4ZJ9+naMUv8SemJCo7C2tWnjU+Aw5+Qrfu6VBDxmqjKimR NAqw/e0xgPYJXmxfU2SSWSoiE3i3WcEz7gF8bIr7pNVrw50XYhGr37DxuS+o d2xHqcZMpGu2mvtFlpMrP03qn2gw08tbz3mq4FXNqggXJgED33u75CpYAB8T NzsPyYR978L2eg7CMTuRhOX0Na5z8SC2DVAPiq6aUhFvaZwGy8tc5I7x8gep JtvZSaJ8rgs1SnROkpSmlvPBaPywkOdJTkhSm9pPHB8cf2ifJI0jScMuYsBK UEuitGuSVIlhpcS24PdSxqeuWbrXJ+00frtzaJCjq7donqdv8NvDvrMGq551 xOS3HOSyKi80aW/xmzOTzuxeSrorIH05ZksJ91qMEDmwxv3OOUtDsqTAZYVK 2QJJms1mUm5pKr8v7sbYQDvLSCUDBCSW2CTPOIvzWZawwj39VZKm4NFJZ4Gt /n4TBs5244CMVnp4bnMHq0B9KSc2XCpy2lbP9TQf6heFuZoL4PU33+TR8eW/ O5tgHdEkQofpyylYQ54B48nkmKb4G1M4JvMkXf5LPwtJBAksh+fTON/LUoO5 h3/nF71MAXo99KiTV8VSE3QUJjCjKMpsNhOHuzSDZVccW6GDceFc0yI45tey 0gC+QL8LQ7p7P6dHwoa7nZQpUW4ReJHCBIKpg8z6WtyD3k0hOBZ3IbM1haHj b6hX48PgZA+KB/E1k35uUdWx8u/JZlBZlFyLu2DjeJVFyZOghyBGJnp1fIWu XoaYcK2Oz2hNYTK1l3Ventmawm/on9f5ia0pLAfDwbBmFN3280Ad71DTh15r Cmx1aij0W1O4xUOFmkdV3tcJ+XE2LZNQO8zVYmUgAVaU4K6QO+Nw8RwCTzAT UcbTqcgFR2xLj9TH/AuA8Us8YmXnGxDdxMkp0hH1M9gxv+yYbkaJ8wTu7859 OqW5wNIelPrXSRuwZKnDK1+yh5KuNDX+wwl93FvMzjlIQb/P2WCW2gbXr1OZ uuLvl+/xLzBlldlX3klht6usH+vcIjjQbJp8+jX1tLM1qDDhOeLTNPnS3E0e BZjEOAw8GKv3VuxmWwojJ3YqcPStW1O4CeJ93Sj06nrxIopleKrXltYUbh0v orVTWYh4cZVQwTq80Z21Dx0w4Uxe9FS7Fc9YrmVCU29sOVhOZvWmu9zyMSFZ Y6IrND/zTHG55XjGM7nllpPxVMbWvcaW9mLGMaHllr/ObZ6pLDcdPS4yk/ih U0ptkCTnIF7uSl5iPKtNc/DFoELhS3aA0FahKhRg8Um9QrWlwFxhiC095y31 AM6TM4cRPmpFA17iA00etRr+NeaQY66EVHzeDF86uXiLwKGWl85R2NFcs3+j o1wqvjx3vrYRhQYqaVTUJA4iKg/+sx98Pc+cofWNvtXV+sleafuskMTBWpN0 R9qEQEIm8XOHTSvLzEAEuQ7Az4guBWBOPvf3gUwnw1w6kJwiFm8Wz73Ipfhg he0Ty4aR4PR0WMNGiuEzxGH3+SMs5VVRMFVXyHQJ4WNfHk3Hiwvc7onh7Cwr jDIyg+m4wN3uc+FY8ObXBQZn+M0tnqtkZRgVAvZLbVFDgcCNXU60lfEjzE0U jknyeNxkcoetud7DuJPAqp4Cgm+7IjCID485A1sccJock0dLW2ZuxLx4RIfT bgqGPfbdGBZbnr8mG3qZBhv2iI+/dX0BOsUPm/kvufxBaAdN/JcC/oC/4eNB 7qLIhRiVHlgh9imkVblT2+Hl5T6k0T7wtgW83TP4+MEmPmGEEXhxqQYhx18T iO3rkVX98SgwvM7Hz4KvmHo7HY/eW6q2Vbyg/0MHogbuyUQ6frN5/hZeEHP1 vs/HL978jTyI8P8nhbPi/Pp3+fj70H1KTtYGfoRTUaLC8D0+HpqfvFLQWOEv kP/0RIOd8IGz4ESlIg/E9wXye+u4HsisHAfZ4UiRCuMvmD/7HyB+7j+5I2D4 WxF/L8nT2r6z9io7LMN3lRbjB7NXd8aH628L1i/daYKdPMdS5AoJhrf4+LPd zMo+SlUf2H+jJ5TfJHYFEaZ+XLv+XbUVfk431H0pTSHDC/T/xgs2zxzeZ7zZ iK/lfcZbLfBRfQ8YXrB+cxqHWO6bHdqUu8DwvRb4X0PHjznyJ5B/2DbQSX+B BYDoldP/QaP83e/k3EreXerlGP6mjfzeoOdUz3/UBs82wLRuKSri7Tb4TJOj Kv/bNviHY7R3d3FU7X9Pad3/6eC3Kv+eKtLfuczyDnUlWyle5Pad7VeN7Tnj bxvkX7bDMAiTwokSIcQPFXH/MfPC6T7DjwTyl2WC0oPDyihw/x3ZLfCgwcea SUD87UBsP9HyytMg20ELRND+qgL9v8G5T53/OgeWyZ9g/1xgopUV4MuT6Uy+ A00uqDHbP/ut8I+GtgZP5KFQDMrWT9D/ydpdDePVbD5eoSu0KvsxgFdF/l+K X44mK5SAerz5Dv5Hx1+hUcvjrUb8TboEq4eoaEMZXjD+2f4tcjFHXq0NPMuP yP4npVDyzSnKypSq+79qiOSXJbJrQ7YEf6soSho8QXSN/TFHMn5YOmGbFrt2 cA4fu31ebJo5WCAqy6A8RlNgo3FNueAMbwti2xFlB+NcEoyAyEjfYtXnSBRc 25bASP3e11UW24OV2NGQ+tCZ5J5MDi9ycliEy2Z4WO+kA17g5IwWChE96Wpe SlAQEdWubvdjt1dHP2qkb+QKx34FafrqvMnj2fmeQR0z9WNXqzCrwVaZWedK 6/M5U0TZwRLeHZyzS43FxFFFsf5YPSzmq3Fyw2BVyakqr32mGJx8TAX+pQau NsHvhdz19vA67kZb+KJ8Gsrgpgj+OJuuuArD4FYTvOYaUA7ebYRT92m/DsJ6 eE8ET3Kdq7ROZFXMADN4v4l7KqSczjsieJIPX5XO8vPwtQg+9rf0lYhmfiOC D09xwMk8p/CtCJ5sRyI45cOTu7qr0XSxSq/RVuG70hWKgieWXO/lEEA43iri wDPu05t69gyutuBeT4DBNT6ckzMvwPXmNFCSSK3mghi+3xYPPlAdftASX5OL ZnhBGPcbfWNFTXw3HvACN/bBz72EAjf4SgIZ8LUuhpRlUBZHSrdYEANNNcFU p9ZhPFul289qFgQeM1cJts6uSpOZbI/upYz+2XhKyf40c70nEMDCllT1Y24o 7GAQJzlHZ+16buzScrDX7ykCP4QNkcXa5zrgKl7gh0yc12xxI46U9hRNKCXM EbRfQcKqvmqC15vxI7oJWXFIHd4QJnsTvvLAewogbNsfqnhRsvVSeldLgeEt UbKFZYnkwWYjT2pUneEFzv4yLXThEWD4Xrv+Y8YpLmVrGd4RrD9EyHkaC/ef tMJ/LTismJEGPxTwGxH+SzN+KzrsYLdF8b4QX36p4LABrxzFjvcs4r8TBOuh u30qXHOt4lWh/gbBrgkv0F+8hyo+bAC8JgoW/a3M9ctSPN8rZXDuRYIUzvdK k/NBbqSawAXai0eEfHSKtxpGv9iE7jFWuXi+XzqneETExzN4Tzx5CVrjcu+3 4q7x4E4b7jqX+7oVd50H37ThbnC5b1txN3hw2oa7yeW+a8Xd5MA1pQ13i8dd U1txt3hwjQtP731wL08xOF/jzwYzu9spzx2/kB0EuGDDTspHeZF+iucHomkE V30HQh5uCQ8n6aF0GbaC7zbhl3jAgt2oGB/EG5rocB+2q52zoXJ9VMfwAn8J nM7JfP4g3C+13H51rl16dEM8Vs9ub5HsZq79GlPmQNVlTAgEvrVZMt3qdWsv 2ZawdTsLYutuZJehNdE+QrMbjvVRF7e+C6F6ix7XhfmINZp7jPG9/Mjeq1SA mmLo/PfVeDqyv9T1uPySB8zhlG6hsYtCNTE+wrsNA54Nhr/VldYjtifuNWhw 9qYOvwS1jCbol1osQhvmajGYcaFW2w4XSsAYtNu6wwUsQnutO1yB9hugnAQC QHtNkjwZD+trNQHbsDp3wDPtceE2N0Ib5omXskBov6HHvHQFYPvKe7C5VAVi 1QYsL02BWK0By0tRILaNrbGTV1gWskqINRqwc4qjPFYyK4i1GrBZufxXN97s c1eP9b6iFjUIto60ghMve2DlZid3UZt7n7Vw3al0Sz8tLq29wD8YDperpT2f rB4W9nw1t39/sBfLUnFrA/LufrFcDQfz+dielwpa2yCB7+N4aJfqmhuQ49Gd vVqOJ/b9w7J0s6kBubAXi/H9NA822yEHo8l4ClO0uBhv633Im/v7ZekGUwNy dj9fruz5/H5eubnUgJwOFiXgudy+BbIoCJfy+1bQ3DBZOX77kT5Mp7Y9slPf R9XeAZ3NbXsyW6ZYVX8HdPGwmNnTjK3aWpCY3EKfB4+D8R2DtpSk4eDu7ga8 gHwhufUONS2uq9pSlj6jtpU0vHexHey4kIz980t5coX25aJmVm2I3jS4QTXF TrlrJRwk3misK/PKXTMpI2eLh6y4VB54Tnjg3uirQ2J9IuUUZfe5yM8PN0lF LbgRrLavEHUVrqWUobeOL2SqqlzoHw7sEtvgiZfEVzX+9D4dkiKGtB6zAtW5 0LGff62FXX7T2kUvqlCcHRFWNVtyReEtQa22XCtYlS9LOVjtGqm9NtDa5VH5 0oQ1SufUM9Z5lq+BKAJoUp7Fi0A1VQjl3YhjUL405YvKnLhaVq7pAvFPq/hq gfhCNi50GrB7H/Iy8Kk8onHyNtkc1BRB74LgCJFZGLJrFCW0xpem/6Z4e7bW siRQvjTN8S1aPBxC+dJ0F4ATfL+TF+6TX3fLWONL03zzAlzDA+Y06vA6X5pA cNkr29jbRlKvtABVRfabHtJDj/UbXvcoxTpaE7RQpFeA6kLN4QPxPW584/9c qOpib115KbzLrTUUVP+JRpfTPt1qDb0rvblS77aGjn2n0GWdL00sK3FJdrFV KnDlS1NWDcTecZXudvl35RlKOyirni3OsSGwTajnyC2pGq1sWoYmho59HpIY ejNXmCCIulglW/7KiWGIoaxWtB5rmOLFufEAi/9NiKpbYPClaRDjf08EWSWj LVMxRLYpef+0nNJIqmJl+3VDKb6d3BDZJuTFwSHXfvMMs+TA6FR+a6ipNK4r B0lMtbXmwMaVvvojhfKlCUJ1zCQGOF04W8uwmAAy+dKUvsAve49B7OD764JL jt00Wu05yRthiiJhms17Th0OoVbLPaeKN7vv2XMKeLMncPQ2Adt1io6iswY5 3oNAmf1/sXe1zW3jSDpf5V/Bm5mqSaZimwBfJLkqHxzHmXgncbwWnOy3FC3R EjeyqCEpJ75ff90gKb4ITYC6mdndO6syk4jqbgDdje7mQxDoKvTmcQerb/dq dXuHNMMt/3q12mDlJjViOX0aAcp3ulizaLWJwY3Prs92ywrf7cVat47fkeka q6cP81Mf6q362uhfPphq19NDZsyKIVXuyF6y0hquLdc+k0VqK8EOHXPWVrPD jui/fUPgQrWrtDX0DFgVyRVZaQ3jqmCiwZx12M2qbjBnpeerYMeCXV1fHJ/j /w+rpdMlKz1fr9LNoZx4awjet7t734zsgwpaaL+4iQj2uTyLgrhv7uRsvRvf rKVJTnTAD/MML6sBfJLzzSZYCnZ5ekb01u3klBUxweyRnH/fBLMuTp/kFEkx 5QjOIcn5D+51so46x/nJcckOjzvH+cnhb6J5lKl0VQNfCNZTyE/xXNE0Ywat nq5UBmJcw+oCq3q0zNGxqptsgi90q0SHaU+aQHpbhrT/MtqVzrNFmKzCjPIK RvsSFExQoKlWJu+AL21Wd+R3+jAbd7F29pnbnS58PeEOJ/TEeVernVOH0y6B az6KVeu5rlrsnLbrxeTNZdd05X4n6zqJSJ/gtF3Pll/DGYRSKpJy2q7SbXH5 b74TKi5Jle0P+FjPA02mNQUNHFvP04pIA4fpeVA1Na0MnI6EIpQmGwCTYzCR Md79WnrbYOC4+riBge7XykEHjmcWMGpMA4d2i8vzYkRy1bbcTCg3kDPU84j4 a7hC+KY00Kgrz3C3qJRUHujQ/vA5SsIlBJbS8YNpKxVzuug4Xy1wP8gZHZpc V8tMzzrXO9BVEBdUBcFsm3Uyn2KKm90rJQBzd7p6M8+WHczdzootUwKAmdZY 5RDqYQOzQdIiVIanJGrTVgcz7dCTRZxk74LNkrAZMI/0pprPLlYKnQHzuGta 0B4imTXFELZ8Ga+g8V1jATPTMtPd1hREVcu7/MDc7WHv09n7SNlpyezqmYlB A7Nn1LJq0MDsm7a8ww/MtIe9m5QO+jnKFp8cb9dUI0PmeJO1+IF53Ome76L5 Qr7astswMHNdue3JGul9/E3KaLbMu2PYuWo2D4CNm01GyT9ABtqfXofL5RTu 89/Hq3ljEiObp2WbLFpzH9loN5icTS7OZ/OwqAOK3g1rN77dW2YxZh++vpoo bnu7+Ry7yccN+fwWn2PaT95kdA35uNvk8wz53FGTzzfkG7b6OTTkG7cUMzLW y28NfY5N+dwjt85Z3/iym9E/GtVbZKYew8ZHjb4yU5dxRq2umvrM0Guopn5z qzG+15oUpl5zc/nb5cfPl1tmZuo23vDIb4zR1G84azGOjCdG03GYqedwv8nI TT2Hj1qMxp7DvAYnROsqvOk29KMDnI6TDnE6TjrIaXtLhjkdpwx0/6hYPWNO OtTpOOlgp+Okw51eQ1TA03LSIU/LSgc9LSsd9rQOSAc+rWXo0Kd1Bzr46Vg7 wp+OtSMAaj2fDoH6SUMGQS0rHQa1rHQg7GQdKAKhsS+xVpvmvuQ4LVYDXxo4 udMPBtwzofZLagOPGbh2ST00oXZL6pEJ9aikHptQjx3HkfSOgfkHnu37fk7O TMhLHTrchNrZ9sUxIXe3fTGxp1dayDGxpzfc9sXEoN5o2xcTi/ql/R0Ti/ps 2xcTk/qlu7j1p4e6bX/pKkPHSVcZOk66ytD2lqwydJz07ZSOk64ydJx0laHj pKsMvYaoKkPLSVcZWla6ytCy0lWG1gHpKkNrGbrK0LoDXWXoWDuqDB1rR5Wh 9Xy6ytBPGrLK0LLSVYaWla4yCNZBV4GhdSO6wNCy0gUG2VNVfUETK8oLklhV XdDEiuKCJlbUFjSxqrQgqZWVBU2tKCxoYlVdQVOrygqaWlFV0MSqooKmVtUU JLWqpKCJVRUFTa0sKHTnAOhhC7E3bCH2hi3E3rCF6IItlAWFjlMPW4i9YQux N2wh9oYtxP6whdgfthD7wxZif9hC7A9biP1hC7E/bCH2hy3E/rCF2B+2EPvD FmJ/2GKHtV5RDHgPH9qpJvK/zQXoQQvRC7QQvUAL0Qu0EL1AC9ELtBD9QAvR D7QQvUAL0Q+0EP1AC9ELtBD9QAvRD7QQvUAL0Q+0EL1AC7E3aCH2Bi3E3qCF 2Bu0EHuDFmJv0ELsDVqIvUELsTdoIfYHLcT+oIXYH7QQ+4MWYn/QQuwPWoj9 QQuxP2gh9gctxP6ghdgftBD7gxZiD9BC7A9aiP1BC9EHtBB9QAvRB7QQfUAL 0Qe0EL1AC9ELtBB9QAvRC7QQvUAL0Qe0EL1AC9ELtBB9QAvRC7QQGtDix/xA 1PJ1w3xbass6/sU6neE7ureP1m9JlC6sX45r64/r23Rb1uXHy+oNftuiyKCw +LKdVYwkw1qgouMkHWb+is4h6TDPV3QuSTdstOuRdJjDKzq/cxw1wiFN6DZG MqIJ/cZQxiTduD4URluEs/pYGG0TPqq3zGijOKP6WBhtFW/YaJo2CyqnIuS0 Gl2MCxUhrUYMCH5FOO70nKpph9ajDI0VIa1HGRUrQlqPXsN5nA49Oo2maT3K OFgR0v7t+Y2m/Q4TNpqmLeM3TOjQluENEzq0ZXjDhPWNJXYctzEJ3Y6ww7zG rPG6J0M9lPlkSPG+1KMZG3YHPSAvKUddUa/e9phWUSOqcFJFTivgMpLQaUS+ +rrqNmHdjI3301qEwyahS04w1iT0SELecAxOmoY3pizwdaStpq/Ro2kGfJee i47bFEn7muM3ZfodkbcpsyNQ2k2Z9Hz0WjLpCek3ZXp0rPSbpvToGek3bemB iaqdLZu0x5ayXvmxKlmUZ+sO5IVFEq/iTdp8baCbsbhecQ4GFVyyZaXO491e /xKtvlRfil9rbRsJyH+S3AOuZS2oVQ23MBu9hFrLjdfVtyKoA4U3aXly/LuJ 6Hw/n5IwnUZZ9snh5F5mhhI4HpOoeV+fknAbLpfMdsgXqlzTPjBKgmfUB85I NdRALZ0mKT0MTUdBKmKklbAK5+AN8gflVnpjMz3Yo1v65TatiAfO3gbfz5ZB mioNwpiBiGG3CG4gYtwtQu+XD0zTC7ePLpS+xbw+uuCafQEMdKEWMeyjC67Z J4AU4XARJrcx6VpjAxGu1fXhBt759qxbBDPpxXq5oQ+H5Hz3Dr99lPssS94k 8Zp+iVQrIUynwTqc4AnZK8VGNBbXSgiyxVl8fx+siF1RHa2EaZAkUZjUd9ii dlwhJET5hnpR9rh7zHpr5xVCwv1q3bW/jeVrJWxWs/AuWlGbw9Z3YiEkJOF9 nIX0KUAjrYRltPracYqQAqPY7UNWbGeqPrWa2UadeBOl0/znD+m8dQI803vl KsY9P4stP7sjN+0SD8EymhXFa2fkpi0agCuIuDgIvityk2613fxCPUeYZ6AL 3D8Pd061tDu6ECK+ho+nt3GSkWFiaGLU8PUmfSRFjAwGotrnU73TCyHiIVbt lqXe8UXTC0qh3MQ7z/KIRUduk2CRyZ3n1N7J9d754PJJcHsfEjtKq27fFSJe J2HwlRThmYio5vrZ/axrXxpaxMXs/PtU7lCHBWfH/jQdAwlmkzAjTiPiI6Ne 5CEDz5H+vBNA+djIIvLIBxHjG+m7mdDu1QtVvHBMvHPVNUWs8i5N3xeHy60G Z8Tua47eR2cQuSbhdJNE6s3fHNcwKea7uLwJV1F7vjh6H11CLiGLC6ux6S85 kNQWHaqob/5LiVgnUF1kl3F2LtPKzkxxTCLolRQCLnaxQsSjYysd2jtOk98/ qI5Kp7DbnZwGzF21ksuMB3KxuoT+XP99RwQ3ci3ctRcfpykH4hgVKl150dV7 Z7DJ4jUUXNSxAK7eO9e3v4arMImmclN2hQjfQARqAfjF96sE5kpbIe6wjwgB fv7YPMrCqm8qTIsod8KHQkGRUtyxgYiiVlRLqG8ybDKQ0/cKEIeZi7gmRPAe uvgQpJDo24PxHAMRci/TD1GaKs819Vxzdc7ep58X4KE4rpsqRXom3vlxk328 K28Q5V5hjV6YeCfk5h3GmggT7wSn/hxEGVGpeKMeugBRMBwwb1NED+/8+JDc Lb9dX143qxXfNhcBt0WvN3e5oPptpt47k+nDrNiTDCuvnZrL13tnhpt14X0i 1ioKjfoGmT1dy13pk81aaRTfNbnlLk+f/BTFy/au4PXNjUnkQCJJb4Pv76B2 3Kx3daH3zkWayXvE/MiE3aH4w9oqz3zH58MsLneQrkui4RhmLIGCY7ixBAqO cYwlUHCMayyBgmM8YwkUHOMbS6DgmKGxBAqOGRlLoOCYcY8+qOGY+qpRg060 4Zj26lGNCAqOYbyHS6jhGOb0sKgajmHmjknBMczroQs1HMPMXZOCY9iwj1GV cAwb9RiIGo5h5t5JwTHc7t2LtkJ5H+9UwzGc9woWKjiGm3snBcdwt48IJRzD vT4ilHAM9/uIUMIxfNhrICo4ho969UIFx/BxL4uo4BjH3qsX9Xjh9PFONRyz A8No+0LAMY65j1JwjOP2TIq7cIxj7qMUHOOY+ygFxzjmPkrBMU6fCKqGY5xx H+9QwjGuuY9ScIzLeg+kDce4vJdrqeAY1+lVqKjyomvunRQc45p7JwXHuH4P EWo4xh3uI6IBx7ijHiLUcIw77iFCDcd49l4DqWMpHusvogXHeHwPXTThGM/p IUINx3huf3W24Bivj3eq4Rivj3eq4Rivj3eq4RhvtIcumnCMt4d3tuAY3+4v ogXH+ObeScExvrl3UnCM3yOzE3CM7/a55VbCMb65d1JwjG/unRQcU4dhJtH9 eonnGc8OP1xeHb4PH8KlXPUpay259rO+YpSihgHLL+VKudpyTS1PuYBo4Oh5 8gV57nbB08DV87SXZA48PU9t8eylVIRvPp6yc4OhEQ+z5SLbkZ4YKujzbIrE Y6UBQS+3UXp4k8J9eWFAKZrpiUu9lksl1fZr8pTj9Sr7VWde/b6BSv+/FUu1 8k/7mS4z5pQbmzcWVdUxxfxU3UPisSAElcZ1ZszZvlxvVZ53WR5ftvvGJb5+ 23xz15jTsZuc3JjzsnWnVDPNmxDPOSsjBlhVNNf/tVmZMWeUzlZF+G51V8f5 e3lm1253q5PVDs9UT1pXcTbZrNdx86B1ZsyfKhc6cGP+TZoo1ko4xvxZuJzG Fc6wu0xP3/4Od/N4NJ3+3iZhWFd+a4mehh9vme4hSGaneFhnaYNhT/7r8J8I sgDtzvI8E35pgXquHvcc/8Wvn8mleRoB0fxbu/ethXl6ATv9bx2kZjIEMbvP UmJRnkbA7TQfAb0kTzeEUCnA3Auni2i2K4KZu+E6iecKAeZ+OIXfoWa8CpLs sRLERr0EhLMWf/PINY0V8J5oJ/Vwc08M5DFXr1tiuLknzvKztVoSuLknxvkN VeskTd7DE5XLIrm5J05bh5DvLr7TO5Ks25uQBa+/nWY0HV9P8+ysWnmnm00r uDFForMYfDItxsJHB/+x6/+OjpNgNrs9vg9Xm6M0gIIyfPZHf2w82cp1n9m2 7XAu/7ZZ/h0/jud5z2zfcfyha/vchuuMD23nmf3sL/hs0ixIoMn/9SDx49r5 32z47D/k86MlFnBncRctQ5yhWRCtUgudAb/dRfPiHPMjfAkymC7yn6IMSpJF kFoBFmn4ZmSQZUl0u8nC1MoWQWYFSQg/rTK464cLoXV5OrG+LcKV/BVkSQnQ 7nQRA9nBj3DpFMStrPC79EFrCXI38HsSYvUc1NrNo7kFk3RTNIYWhAQbgBBx /v7yXEDT8iD1svUFnrG8Cu5LtiMYdGjdxcl9kPe+Jj5KT2R3bibXhx/OL28O L8T5h8O8te1T7lfWzeXFPwYHPw5u0jApTyjOb4peFefP4y8vgSL/VobeV5YI l6swq355h517lXdMtnz5UZxPTix2ZEHhVvUslUpdJ+Fd9B0G8i3KFnJwKZ5m nuER3T83+/wzNGHxfKzbnoPO0WSgGBzBS5AAV+APFOtWMM3gDm/5CIrHl1qh 4IlSlCFflgvxRVdg+xqGa9luhEgM5DVrHSQwVPCH9foRyZ28yQSCPSoXaSF0 Sw+Dhv4JE84C14nu8ra/hdDz2xDRxtzYMzRM0WwAUuabZZBglxJoUkr7Gb+k P0unRUI3bzBX0oebiQB5SItVbwL+koa5KqUM6NY6XoGDSHWCkz+EeINSNAgD rLhADHRl2zt89oCnbQdznCSZ7Aq4eBKBLNmzrbawYzBjwD+st5CqzqTHyiPK 8db5YmY9f3N5MXlh3Qao6DRc5meuv5QiC7eM0ty6iGCG36fhGqeNdHe8jPx5 UZDCiNbLAFwLr2+95cg6P5ofKTyZcceVlz8vUPP4VWqiJRVImnzr9brt/wdK 75eg66xw/0HxrcTc4Perq6vq+ulsBgZJ4TL3vKPqP7ciuQyz+yD9ukPivTwo E19B+UHcABXzbHvnpzMwXlIEhVfWp2B1+LdgGt9C7DkUZ1eHF1cHreGmy+gP Gu/k/cWVwWjaHchkmDDrQj3gkPGmGW40rSdLJP4DWr+WgnStD1rNy4C9E23/ qLGjdNYeMfNt9uc2yQ/+DfN/o/6DuAGhJAv/2vqP2w7b1n/clvWfw9lT/fdU /z3Vf0/131P99y+p/549ff4/fMr8L6fUnwQA6fL/0C/xH/gn82T+Z0/5/6/J /xCmFBVAWq6fxNWgjUoAQl0eoeDfwAv/tkIsDNCBjqw8sUYJhMe7KFzOyjCG v/6cyhyMIoFxCskewvRmjTF3BIVAkED+ASeUkTtczbOFFJenp7u4eIb1XLa6 jYy4QvxFlQuXUZ5zgg18W2XRNO9yEv6+iRK5Ij4t+iwj6bbPWIkEOLTpcjOD dFVky5cY9O9BGXgUtuw8pu36NXy6aa0297eQ66WuZAmzjgpdzbB4KXJgrgLg L6VDy5+xJAIWRX8xe0YY3OXKHesuie+LgdfalxkDEtUDbqeaZzQowSCdgexT K12H0ygo8p4sf0DCD2/O357evBc/WIUFyqz7HLufLuINWA0uy5wC4ynzHG6A VnRAykN/eYG2k63cPUJ5F8i6Yhbn9pARRdYVhVfJ5osUvhXR6GipGVTZD1if bDuZNxJJEdAGSMUmUVJLdYVdgAaakDVOJfX5cZhNj+XX2QsQ1GLN3QJ0Lt0C c+TgYjUDAlTO1sWy4LZy1hfSAUv3xCohK/0fuPE38KkZNpAn2OZMKqwGfb3N fQ6rrmD6Fa7smhrJAmylKL6iYu+qvH6V+iyq3qNyStddGga2mqfQ3a95T66u rpS9AV6phqJolvXQvDIZWDJG1RyAsyTht3pF/MP9dLVZZo8//F+ChaA9Id+Y yEu3U1mnAekH+YrN4XWYxptkGqZAd5VE90Hy+OXN5eTLJDcZtOqOjxjjR/zI sQ8OcG4O6irDC4S+TivnDKXWtn0/KGZwQ5KcLaaSyPz/5wAAuvzPhvX7fybz v8v8p/z/lP+f8v9T/n/K//+G+f+PzEFPn3/9/T84KXoBFDBH8XL2F+Z/5nLX hlwPBB73+JDn9/+u7T3l/78m/1s/vQuDWZicWMcPQXKcV7TH04c0ieMM3SPa pPL50I6rvHyw2JFjsfF4eGw7x3xk2faJzU5cZj18xQ2xV4F1/n1t/SQBx5/e x/MTq8ENP1jX4UO+kgpFKWVtheFTArnh9tnZaZkSptZugQ50Z3Kd1cwqqnKZ mychRLwZfoMa3cogMsngG61hWGXtcjO5roqfPPKCtKrT1iKYYTi8Rww7lS/e pi8lVi4fc4RZUfp/k3kUsx9Ex69lhRKnIUgrs/VWAD5d+biwPofL5X9JVdV0 wiud2B7qxOUnnkontUcwedF2L+udo7ZAVgrkx2xscXZiD9VKxgFJi8PwoQzJ 4kKNiDljSs+rqaZwvybctbh9wt0T5jSE//LLLxbcZoB6MbPcQ87CdxbgaluW 15DF+An0lY/3k+W2ZbHhid2UdRYniVwCjz6RhHcIylvXb89SGIY3kiOHf4zb kp2mZPvEA8leQ/LNehYUckEeSkMhB0TpXfM1uStG/o5SKssTfNQCDgOMRYmY 23qO73IG+IZu9XgDC6vlMhcRTHMRUB/m9es6xloDKofT0mmO8xN5rgKoXYqp IN0UiWR9v3UvLOLSqiBDN8b3EoDOxXo3yCcWyPiEywxrl7B5+WxtkLu9dWjZ h9xzrBi0LgvzfCbCdbe4hvcCqzCTU+j2EWvpZIYTcoAPn+Yhkjrcuo2yorNA fhvNsVqNoPaRxNbzRTRf5NyyMMPKT9blBryHGAsgZsB4oZDCoeMHAxP+sX79 IF5a1t+CFYyWvURHGNpygOdwS4AWwQeOVWmewhSCK+0SOA8OldmBP1/GuWP+ MEhhCs4g2sF9zvbBLLaXPzXNtXsqxPXF6xtxPgAboCC4dtj8WJYl/4ZflEgM XB8OBq8sNnheajpcTeMZWO0FVn/bJgpIQpZ8l7t7X5VbgecG32GjNvHl3Wxn 706vDv+HvW/tbhtH2uyv0q/gm8u0nbFs8SrZmfRZWZITbduyR6KT7p2eo0NL tM2NLGpIyrFntv/7VgG8gCRAQpruydu78enTjkk8BaBQKFQVigAHq9fAlh4m 9o6K1SVfuVHpE8GuwNPLYc00J5gwiM+TnBkcf8BRgysOSHqkjxwuCZ1lB/lU d68QTstO75GCTfxNlPtQmHwzV9/KM28J7hPDT1WtHDsmlFc4IlmqOjbOF3+C UY1jtuYLX15UciW/189+byFTHYYcr3Lf0KlWHveyCLxcLngzAW/9qZx4KMwX 8XKZO1inEoZnApFv8cZ+4TAdSVheQ2jtHKzUuWEWSCkcXhx/FAEKtkow80ft aDICNrr6CacCWXDiLySqlcM97u2DpUl299nLLmtUkcM9qFUz+bDGR1iW/AAv niE2L97h2BDQnlI5b5XO1+lUy+BosXRbnEPutG41jhMfj8+wqcaVsyKSTyur WUe/Birh9GoFMu5NoSiGIG5zZyjp1WIBWvjpuTC29DiaShidz+c9u6ALdEMS Ns59faKbkrD3gc98G6JbMiLfW4PlYDvLz634VBO9I7fQpLhkwujd7XD/K/6e VT+uamZvjjcuwQhswtxXx0bNSkNwA3fpPBOpZg7ulcCNVutN1LqkRmhyTIwE 7nITFYGGLoFLJi1jYBjVskJgaViN/aZ5i+oYxhiWNFuuQJdn3evIs4UFGl0J XKJb3FbfwXguOdhFAnexWUYew9SG2W5U8ZHcVtr3N6uo0TDVhlBloeGZqnz2 SNRa3UNW3MJH81aNJBIM54IKS5OxJlAfIIVGw8orq5cKPQcp9nuykL9KnYz5 vX+gtMm/V37858K9dYCn4O/yVCQSK98lYhRsFxJb8VfL58yXJA5WhLmAc2Jl J4259xZu5iSh90jdJvcp4i3B4Hv42M78UlrQD3FAn3ozNuNaoUPzkrPNm33p LljjBpQp4BDWlZz0BqPraWtCnXbm2AdB+eL2ckNrxrmmCspQGDetUY61N7Lk 0/R4CV4xZju+kRwpwSuX2m4MXV2iOEvfEJcHxXAD0y5piCku2WPc3ke6h5Ac /cErTuYckcyYdKeCdHFzIjnyo7KHWAMpfNxM3Wgl8dqyESq4c40GuNcNZmhK 7/F7kUaDjnhMNfGyPtItmgI0ftto4PkQjVQay+9PA99ZzB0QwFL1aZlzYLG7 ajAyIaTSisvqTEtZRysvqWVPTNRetggnJQPanuROK/HIZLXkHLBGg+Zas3UU CtDPU9jxKFKAOsmBhAxHCkVQydIDtxqUF9RYKfS/aMZgKVTOWc2cEv6aHYlS AXiAaxaaw5crRsQrC97e4pE2GCfKb39ympuWKMtW8T3VcKXuMCXO/bmzLHWH JUEOXWxQJmIuP0mGTjZWmTgaHntDNvNpw8m+tQeLycJdu2TDFsD4EKPvycHC EY1UroHnTFI6mXJU//dzm6GFmUaD+i1appFuerYyDzW9n15c+JMTrHAGmU0a /IX1UEnOP8p2M7IwPv0Y4KKfBWlxa5rogbw3qGQhuRmWp0YAztAxyUxooc6C iXXJOnbtp3bbsgo2SyV8tGqRBPEUPuxWw4mHF4QJmd54lKt9eCyE9/Nf6Jd+ 2k+nZ+htJMHJEgH6Df9oUUXgdFg0oYr4AS4IOeeBxWtnuRAE03o8RYBMbz4F BJ91qsBDWBEFlROwJQDHFklrYA95Zw8RtpsV3R6RtIJla/JETeIiDdLtgRh/ BqaMGB3j+/X128L6QWh7dfXbFfUD/lSMB7mDdQeUpvuwxvg9flVTkjtVDt+y 72EVu/eXixx+2DXE+B75Aqf10V9GhcgcU79WIbZPa3qKk4ACweti/BV++9LC U5uWz/G0LeMr2t93QM9xjgbL9d+s59906UfCeX8sxovuTc6Nf0eMF10/nMN3 xXjRLZg5fIX8i47tYPHHFfJbd+4gqb+Cf3VHvBH8WVX91Ye1Ib7Tlug/qD2e 54vjP6wYv3il8W9bE9xXL5EgeEuMT/VmEgwtxEKx/Ua3Un7jLEYwDzl3OpL+ q1L4wnWSDL5i/pPzgQR1p3izFs+tO8VbEviQ3wKCrxi/+NKDMPGUi00g+K4E /j2YfZFA/irkH5YN9LrBfAudZShof69W/i5vW8xInme7SAR/KiO/p2g58esf yODJAhhH88M8fiiDT2ZyWK7/TAZ/vQ7vvdsoLLe/25Zu/7j3Y7n+rlo1fyfY 8pC7kRHjq8y+VH/xr4Wl+LMa+W+RA6poOLFACPH9dnX77WAjaj7BDyrkLzn2 Po7WlHqB6+9gKIGHGbzmMAHxZ71q/YmatzX2kxU0RwT1r1ox/+sOzyTyV7F+ ig5oza2fx1L43ImqufGraP/FjTfrR7OryWiGptCsaMcAXq2y/2K8PbiYoQTw 8eYW9a+d1QyVGou3avGn8RDMrsO8DiX4iv5f3T+HHrj5nB2zVH6q9D/dIGid bsIkeF9e/1WjSn6J68112Sj+rN1ux84TeNfYHnPQwl+WTg8sIMk4qfvYORb5 psIjUynNijbCmIrPW43xwwrftu7IVkKgSkmf4V7ooMq5HloVSuqvx7pKfHvQ ErdugCe0t2j2GIOvMnJqDtkj+AojZzBtK1U/8WgyGw+ACLmj2znodHn0w1r6 BrOdEp+s2xpdpdk3vMrUg45WqoyDLVdmpfkHaWQsdEkoDBNhJyRDNx84Kk2s T7Pr6WQ2onk3s9FVqU/HZGII4jEl+E8cuFoHv6ysXZeH82o3ZOHT3hUHblbB P16NZ8IJQ+BWHXzsCFUSwDu1cNe7u7/hXJxK4N0qOI2qz+L4/eyjVoIf19XO Hh1drt2pgtsbspAUYs0s/KYKjh/gPClVnJ9XwfubyL+9rYIvquB0OaqCu2J4 +XPQMvy2kFiUs8RorrqAAMIx104AT2ofn/KrJ3BVonY+AQLXxPDncOnftWxn LWadqteHgWggtRwLIvhjWTzYQDx8TxLPiUUTfIUb96P7THawxGY84CvM2OsV 82kaLvClADLguSZGI4mgkOslcMMGimoVrI61w+hqFi8/syvfXxJ1RbE8vdq4 uGoNB5eNhH6qPBt0fbrylncggLklqWzHnLqwgoGf5KydG2/pRXiOTqGX3XaF HUK6SHxt2mevFCwDfIUdcuE8JYMbCqS029YqpYQYgsMnkLCyrUrxej1+4M7p t6k8vFEZ7KX1tnrLOx/ctvuHMr4q2Jrts3IpELxVFWwhUaJWbz5vXXCmOsFX GPvJZUUiAgTflWs/RpyiQrSW4J2K8QcPmaUx9f7pluq/qdisuFJq7FDAz6vw P9XjF1WbHSSHGrPoxPLrVmw2YCJe5Cw/V9V/W+GsB97ijntpd4ZXK+ev79/W 4SvmL2ZnV282AF6rchZXi5bQLovxYquUwEVfMCRwsVVK9weFniqFV8xe3CIU o2O8VdP76Tzw1pEqxIvt0omLW0RiPIF3q5lH0Zqw9mOp2jUR3JGpXRfWfiNV uy6Cz2VqN4S1L6RqN0RwV6Z2U1j7rVTtpgCutWVqt0S1a6pU7ZYIrgnhcbLd UqQ1CFw841OFmWQ8tybOKhcdBHjFgk0yYISefowXO6KxB1f+MoiFW5Wbk+5D IUW8hO/kEyaTbwNEaZNKRbZunOTITeTt9fv2zB5OLsA1H05mk+Ffr4fkCjD2 iqAa5Pnl1J71e5PJaDgpXA4kg4R6P476w8K1QDXI0eB8OLNHF8PLa7twIVAN cjqcTkeXYxZsyiF7g4vRGFg0HdrFS4AkkaeXlwm0I4e8upzYs+FkcjnJviOT Q4570wIwvfJHApkXhOyyHyko003mmh+Znl6Px8PhYDgoXPAjA72aDIcXV3aM VfUtoNPr6dVwnFSrSgsSkVtoc+9jb3Seu86nBtrvnZ+fJpesFi7ykZmm+XFV JWXpA862wgzvZrqDBEgVetIK+TgnZC6rK6RxkfwKtzVahW7A2d5lLscSIDHH kLexzVyLVUReTa+TdBpwk5zgoYDsViKLd/SyP8dC5IfrU5pDdLmJSDZDbp3J XYJVhJ45q8pKmeuvitBPTjS/X2Dghh+2YC6+KrH37oFu28QZKCWoLoSOVowD 3xoWv7hkL7sqQpE7VVjmmqvqWlF4C1BLttYSVhXLEgPjjpHalYFyh0cVSxPu yqbONma2iC+yKkPphrTIy9DUSijZixdBxdLEbqM7UTmRTtMrxD/OW+ACcxdW FaFjn2S6tmxwqFsDN6KHQXCvquJAz31/3epvgoAkjhbQmliafnYxw5mrWYr3 QhWhE/yaToTL3wdVhOLN9Bg6m+Lh4Zw8W00sTZP5I9QaPIAWXvDwuliaQHDJ p5vko5YWvfw2B1Wr9Lf7EId5bp4xwTXfYF2rg+bSEvLfclbOHDEQv+cUK//P uX1s8nHPY+6bTmlov3Bzmm5JQ88LX7DrHWnoaOXkmqyLpYl8JUNuZr515i4d pVytYmlK9j/Jt27xasd+M2u05aAkXyjPY6NCN+E8x9ponkxp0TK0auhoJUIq hl5fKzAIXDyyd88m2RpGNZRkx/Cxhlk9OKdLwOLpiGWzwBBLUy/CA0GxKtrb IhWjSjfRc2haMQ2aB9QaPs3pTQJGlW7CugQ48gVoPYfJzs1gUzw9wGzXjqsA qZiq9MyBhSv++iaGiqUJnHP8BMZHdiG3YJnOOeemWJriD3mTb00iB79j9bOo gmlIrTn066a8SJhm/ZrDwyHUklxzynizs82ak8Ob3QpDb+6TVSdvKDo3IMf3 IFDmcZWhd+dXQK32VrWmHtICP/3dqtYcVJOxEZPpk1NQll4FjbzVxgcx7k/6 ZbPCMraCsqNjVax0uXyxFj20ja3VqtX+SSiuaE93VGkoqlRyMlMCFXOYSVDr EyO1sMB2dHloodpOhfZPcyJHvNNllI4pAeUsrggVcxjzoAQVUminGsqvkELF 89VWj2z1ajI6GuL/W1myWAIVz9ercNMiE28Nyvum5OYo3XaTvb08/6kKphkM yVFyAr+5Enm9+rzyv6z4ZrgQiQJ4cRfhYy5SFyIHG2dpq+NeX9BaoxJJLGIB 2BQi/5pcBS9AWkKkHcRTToDsCJE/aWYltFvZz4+6IWzwcWU/P+ragF65XCaQ u4GcC+2R6545VauqRK29FW+AVK0GagCU31tVr4Pyq1QKN42LahU0WCxJU1je lq5YflWxKA2jezdYuZFIKlSxLIHBBAYaLxerFHwpQo2uVSnD6nEVtLLNWrtS hCdTTdcEfNK0qlorp44mFgnc5Yrz9CivCnBNPK6j6WBcNV01qxK6DjyhTGji ce0vP7sLUKUiTaqJx5WILSY80QM3MAmH1N/QjusxUGXIMKiht+sxBY3U0NV6 DLKG4UpDr1hQbO6QNQCkS0xk1HfvE2lrNHSjXm+gonufCWhDN+UUBgNq6GKx GA/jHpE8tQme5kQHSO/UY2z/s7vC8E0yQN2qdUYzYkuJJ4G6WB4+eYG7BMWS CL4zLyzFmtjoGK6gyrm7EKsmw6gFi2edYTbrLIiRyIJQ2221EtzDJW7xwKUA 4OrlanAXLSvA1cKKNYsIAFjMsUwg+N0GsMSiJWAZHnJeu2xVgMUCPb33g+iD s1kKxgzA3fqhuluMVhyeAfi4alqIJYSAa4whrHnsr6Dy8mABWK0Fi5tdYxBl NZfxAK6WsPNwce5xG03ARj1Y0GkAm1I18zoNYEu25hIewGIJ+zBNBPSTF91/ 1M3yUHUlwf4mKuABfFwpnh+8u3uSzFuuGMBanbltEhvp3P9CaORr1qp12JA3 mxsA0+QmI8E3ECCWp1N3uZyDn3/ur+5ykxhhZi1sel+Y+wgTi8G0Px0NF3du bAfEreswjm/1ISGq2m6dXk05bm81Tm/ncZokzirgdNl2anmgIYnTjDzOlMQZ 3TzOksR1Cu3sSOKOC4zpSvPlxxw/j2VxxqHBIhm9XgO0DrtsjaqsxKjHh7m2 qrIio3cLTZWVmY6ZYw3r3NYMvlmYFLJScz3+cXz5aZyCVVmxMTuHVq6PsnKj qQVgV3pi5AVHlZUczcoDNVnJ0boFoLTkqGYOCdo6U291RxiJFVwdUqzi6pBi JVfbWqGaq0MSRfdTBjWlkWJVV4cUK7s6pFjd1XNIpPBqkWKVVwsVK71aqFjt 1QqgWPHVjoxY9dWKg1j51UEr1F8dtEIB1kq+WAXWTxqhEqyFitVgLVSsCCuh DY4ilJYltVCnvCzpegEqIUsNnQp9o6GZMqWtpLSExDSMdlK6I1PaSEp3ZUp3 k9LHMqWPdV0n5XWJ4W+YbcuyaHFVpnjCQ12TKa2nbdFlihtpW2TG00xGSJcZ T7OTtkVmQM1u2haZEbWS8ddlRtRS07bIDKmViIvB7h7WHXQotjLqkGIrow4p tjJqWyu0MuqQYneqDim2MuqQYiujDim2Muo5JLIyapFiK6MWKrYyaqFiK6NW AMVWRu3IiK2MWnEQWxl10Aorow5aYWXUSr7YyqifNEIroxYqtjJqoWIrQwBt VBkYtWIkNjBqoWIDQ9hSnn0hLswxL4SFedaFuDDHuBAX5tgW4sI800JYmmtZ iEtzDAtxYZ5dIS7NMyvEpTlWhbgwz6gQl+bZFMLSPJNCXJhnUYhLcw2KupOP 68MW9s5hC3vnsIW9c9jCrgpbcA2KOmR92MLeOWxh7xy2sHcOW9i7hy3s3cMW 9u5hC3v3sIW9e9jC3j1sYe8etrB3D1vYu4ct7N3DFvbuYQt797BFCcpaFA1t CxkqWRP0tzyB+qCFvVXQwt4qaGFvFbSwtwpa2FsFLeztghb2dkELe6ughb1d 0MLeLmhhbxW0sLcLWtjbBS3srYIW9nZBC3uroIW9c9DC3jloYe8ctLB3DlrY Owct7J2DFvbOQQt756CFvXPQwt49aGHvHrSwdw9a2LsHLezdgxb27kELe/eg hb170MLePWhh7x60sHcPWti7By3sHYIW9u5BC3v3oIW9TdDC3iZoYW8TtLC3 CVrY2wQt7K2CFvZWQQt7m6CFvVXQwt4qaGFvE7Swtwpa2FsFLextghb2VkEL uyZo8ZJej5Z8bkgP4lSUozdKb4Hf6N48Kz8GXnivvDli8o/Zg0kVZXw5zr7g byuiYmBYzNJZpQqLoS2QldOE5XDlz8rpwnK4zmflDGG5Tq5eU1gO1/CsnFXZ D6ZgR1zQyPWkKy5o5bpyLCx3zHZFFY+IprJ9UcVjonXZmlXxoOhdti+qeFTM Tq5q8bAgc7KCmpiNBuqFrKCYjagQrKzgcaXkZFXrYj4S1ZgVFPORaMWsoJiP Zk549Ao+6rmqxXwkejArKJZv08pVbVUMYa5q8chYuSHUxSOj5YZQF4+MlhtC 9mCJkuDmJqFRoXZUMzdrzOrJwKoyS6hSzBmrzdROtdKD4knJbpXWY+s+FrMo p1U0IYv0gsJVhQX1nOZj86qLBdlhzH2fVijYyRc0hBNMzRc0hQW1nGBowqHR clMWL4QXL1t5WRP3Jq/wDfFc1I08SbGs6VaeplWhefM0KxRlO09TPB/NAk3x hLTyNE2xrrTyQ2mKZ6SVH0sThgjMleFqgZe+5sseKVx75WVmsnBvE2yQB/eB v/I3Yf6zgWpg/DxDNhpZuCSFim4gTJ/PvNUs+yN+y9QtRYC+IuiGVguNS/Mq LsRs6ikwNec+V09JiK5Q3ITJXbkfsvMhud/niyjM514UfdQ14VlmkhQ0vBiq 5nt9EYUbd7lU27rwgypDtg2qiIIp1QZNFbKBCWrVcVLEh45sL4SM6NZSWLl3 IA3kBfcovWM5PrS7N+KP22pJPGrqmfPUXzphyB0QVZUg0akmoUmQOK4mUS+X j2pNK4xteMGVLdXchhdazbkAErzgk+hswwut5pwAIQlds93gxheK1rEECUOp +tEkpPOsX01ClWnFerkRX4elaWUPv3h57SIKBoG/Fn9EWkvBDefO2p3inaAr zkE0ilZLwYnu+/7DA94KX3fSioDC3AkCzw3YE7ZEJ64IKHj0QD0vei5fLFs4 eUVA4WG1rjrfRrFqKWxWC/fWW4kOh2VPYhFQCNwHP3LF9x50ayksvdXninsT ODGKchui+DhT/j2daluqEQMvnNPXF+Fd4c5btV4qVz6e+Rkf+VmtucUi8egs vUVsvFZqbvGI4k3Lth9ffVuluYVilR5+wZ8jqinBCzw/D09OVWpPdBGQ+Ow+ 9278IBKqiY7MoLqnm/BZSKIr0RHeOZ/8k14EJB593mlZ/BNfalohYqgmI519 qrHEmltGWUTk5Dm+dGr10vloaFPn5sEVnCjNc985JE4D1/ksJGHKkMjmev9h UXUujZjEaDF8mpMT6tDgrDifpqIjzmLqRoL7F7SuVCuoysCbMz+VFKh2LDUi 5H4J28cv0ssrYXurVvD0hS4jnauqKaIkXlp9W3SNHDW4EJy+ptfL6AI0V3Lx MZeEIbko0lNcBu7KK84XvV5Gl7CWCI0LJXfor7AjYduuYAV7+K+IxDoA6yIa +9GQLCulmaLLaNArQgREbLTCiEfFUTpi6egF/7jgXQ4rit2W1jQAV9lKhird kdFqDO2Z/LVEQpMSLTy1F7fTuB3RpQyVqnXRqJdOZxP5azC4RNcCGPXSub55 767cwJuTQ9k5JCwJEsgFwNtPVwHMlSJDjM42JGyQ8+f8VRYKe6iwmERyEj4Y CpwlxTiWIBHbinwK7CHDMh3pnXOCOKo8iYmAhLYFLy6cEBb6YmdMXYIEOcv0 wgtD7k1upiHPzsV5+OkeJBT7dZ0tkaaMdF5uosvbxEEkZ4XlWiEjnbA2l4AM CRnpBKH+5HiRwFIxu1vwAkhBd2B48yS2kM7Lx+B2+WUynuStFastTwLcotPN LSXEupn10hnMHxfxmWRoeZVsLqteOiM8rAv9RLRVOBy1JFb2cE1OpQ82a+6g WIaMy53ct/XR85fFU8HZw42FkQMSSTpznj6A7bhZl3lRL533YUR8RHplQrkr VofJ8qQnPrciPzlBmqUkDseo0hRE4RhNmoIoHKNLUxCFYwxpCqJwjClNQRSO saQpiMIxHWkKonBMV5qCKBxzvEUb+OEYNmtUohHFcEwxe7SGhCgco2pbiAQ/ HKPqW4woPxyjygumKByjmlvwgh+OUeVFUxSOUTvbDCo3HKN2t+gIPxyjykun KByjtbduRZGh2jbSyQ/HaNpWyoIXjtHkpVMUjtGMbUhwwzGauQ0JbjhGs7Yh wQ3HaJ2tOsILx2jdrVrBC8dox1uNCC8co7d3agWrL/RtpJMfjimFYWrbIgjH 6PIyKgrH6MaWi2I5HKPLy6goHKPLy6goHKPLy6goHKNvo0H54Rj9eBvp4IZj DHkZFYVjDHXrjhTDMYa2lWjxwjGGvpWhwlsXDXnpFIVjDHnpFIVjDGsLEvxw jNHZhUQuHGN0tyDBD8cYx1uQ4IdjzPZOHWFjKaa6PYlCOMbUduBFPhxj6luQ 4IdjTGN7dhbCMeY20skPx5jbSCc/HGNuI538cIzZ3YEX+XCMuYN0FsIxVnt7 EoVwjCUvnaJwjCUvnaJwjLXFyi4Ix1jGNi43NxxjyUunKBxjyUunKBzDhmGm 3sN6ifcZL1oX46vWufvoLknWJ7G1SO4nmzEqKg0dJn8kmXJMumYtJkkgauj1 GJqQZ6QJTw2jHlNMyWyY9RgmeXZMGGHJ9ydpXKMjhVHbJMm2W18YLOhhNMfC x9wBBL7ceGHrOgS/PB5AQlqtL5zwNUmV5I9fHpP018zGL7vz6h8bsPT/yUnV oj/FPV1VGkkONs8lVbExRXqrbkuwLQhKJfdclUYWH7O1kvsuk+vLyl9c4ue3 +S93pZF6O4/UpJHjgqfEDM3AxXvOEo0Bo2rn8/+KUFUa6YWLVay+C82tQ/4j ubOr3NzsZrVWn7fTuvKj6Wa99vMXravS+JCb6KBJ4zdhwMmV0KXxkbuc+1mc oZymV19/CZ2/Hq2Of2eB67LML6To1eDRZXoAJRn18LLOZAw6W+In7v/GIAuU LaXnyeDJCLBr9fGW/R+9/yRMzash4N19Kba+kJhXT6DU/sJFajJdsBcPUShI yqshcDOnPRCn5NV1weUSkJfC+b23KJNQ5cVwHfh3HALycjiH92AzXjlB9JwR UrtbEXAXBXz+yrWaUUCfqLT0aPKS6JBrrk4LZDR5SVzQu7UKFDR5SfSpQ1W4 SVPbQhK5aZGavCTOC5eQl5Pv6gWJ2O35kIXGfp0mNR1P53R15mXe1c2mFTim WKjvg0yGcV+0bvP/3/y/w6ML57N7C37+IUaP/dV3v/1PG6/GMozv2u22rmnk d1ulf+OPqRnt77CAoZmWqWnwXNV0Q/+u/d1/4GcTRk4AVf7bncQf7AjpXee7 P8jPS+XVaHGiFITg4FFRDzXQscedo7Z5pFpKu32id0/UrvL4GT+VXDnK8Gmt vGq+bAKFc/+ORwLeKhMwUMlEQ3pcgilFKK0egh/irp2AXHUd3btK/+y8934K MzfyldPedDiLH+A2x/Ane9KLHxySljC1qaXajBPczijUdhr4n11Sk79cpH2g 9TnFPpFaHbRs8XPS9dKJbv3gASgRe3ftzsGbm6egkLSp+bIRg1PiAFImvcHo eqq0FHjfmJD9CqW3gXasovjyTXIjvTJaKdehGyix7icUp5P+YDR5d9i8nk5m wITheDq6HE/fKa0BPvk4HA8uJ7Pp1bA/Ohv146cXw/E1Uzh+2uv3L6/H9mj8 nn3XvLqejM5+nl1e2eRvoHzrkyvjwZxYLlqgynFrxQ3fPbuh0vrirRb+l/Dd yldasE62sJPv1pvAu30+hL+VlrMEzyVsbUK3NXfm925r4QUE2mSGFCq506Hs KvSU1tpdOMgJaGb4HJrKq718X/ebMejVHkNiH8qxQrHfPB/QYs1+/93dfN58 Cb8V2jQom+/mvoIlpsPJx+Fkdnn6P6fvAmfhbcLFoQ8L+DyCX9CDIMTfkbeE Xw8LE/7vRFGwBo2KBZw5KfcIxWAID/2Y3OD0oori4uZBnigpnDQTRCEjOqdE 53Ez55TinFCcMxTnlOI8bea8ORr3z68HQ+Qnla79I0r18F7JHoENcHt432z2 zs9PGnGtCvzG3YxmExqWPj2EP8DmAGGBfzSb86fAvT1pNsjv8mAqLXzeQjO/ BbLkPtF/3kcP8P9L8gsakfV4v9mM6znJXiB/95uNV3v9PspBIhEtX0lami8K f56PThla2OaMXjJklSRJN0sImAX0eYG+f6IU2YuD9mov4T6vrjkP02xSmWAJ xmMqT40CgFQmajl6jLxsQTRDgUR4xUbGAipPjwKazXjmsbQSKZcnFiNiamQi bU9wAOOMIsDMXEElZD7nKqDzcYsGE0CzmeoTllo6e2sIMuooTz2b/k1Wt+xS R8IUlo6wslhjnCSqI1V6lGOiCYdFBZDcXKPvC3ONPNxyrlFMs0lqYulRhZr/ +76GHsE0m4lOPEm1o6DDyWumXFGvZG/YxqVP5zUtYgo2wUOPQD+38Dco3htn /vgEo3o+GttF1csvdHjIcBn+oCyCfyQiPF+6zgqqCB7AmFDeHGZqORnatMeM cm1+9+3nd/1h/D/He/p96qjx/9pmuwP+n65bHXAAdRX9P9XqdL75f1/B/wMh IM6fyvGedAnnj+JfSfhi+lfxxXhOGBDrjX4ivliTdR/etQbjy+mH3uDyE6g5 6Fmz6a3my83CLTam+f/C/L8JF19n/nfo/O9YhmZqqkHnv2V9m/9fYf6DEOTm f/dIPVY0/URTTwyZ4A/Fi+Z/nlpx/ufmJqoBEu6dDpTLKby1771QCe/9DeiG L37wGactvBwpke/LRX/+e2ocNObegWk3D57X0X9c/zDzH8y6zdPXmf9Gsv7j fyT+q1nat/n/FeY/EQJu+NcwTtqWhAZIKNRFfym94ow8R7Sy8N1QuXceXZjw zsL/oqyTD5RCmpJA5iIpNb60lRV+r9NarsKlsvKDeEaSt16UvAxx6y36AyoK yhFQFb+L8cHM/9BfOtDpr2D/Gypj/9P9H7Ojfpv/X2H+x0Ig9AEMCQ2Q0ZDx A4z/TpNtSpueX5lRryQKpLBAX8YbFH9Yz+AwDgP/nnVUz3+VznlLt9qgAeA/ nP+gE775//+R+e/d4jfI+F1L1ARW4J7b/N4JlDeT/tRbKO+UF68+uM7CDU6U o00YHC39ubM8mj+Gge9H5IkbBGEsRURtmPEkR3tfaXdODJjnxwW18eJt86W7 Wni3zebRm6byJlYhKZVX+IzRHKbCJZppDiiOqgN3Uh/jrWPx/ubch6pxj9VZ KvhNEuoBf40PDjFN8wtSI/kit4TQuDcF/TIPQMWAalj5ESiNDWgdb0Vez5ee u4pCBWf9AXmycr9gxs6d763uElpOtrkLGgfozP01fph2G/gPBOTh51H41Uau 5CHgC7ww8rywkBeGUeYFPdwYRms+W3iYu7O3T3KpwGGC7qwWM+T2LHDXy2cl 9KENTkT74wcBZlnRLqe8CHHHg3QaSZLTIqGxCMh3DRUqUAYOkQKBG679VYia t9QTPemJfqR1FbV7YmgnbTXfkz7JuAFjz73Z3JFPikPsANljIrUv/Cgi7+fe A4wn9AeqhObQTXSfDuG9H5Ke7HmrMAJxTp+7T06CXG0ebtxgv9xMarpaR6p2 pOqKaoGBWG4mhrehGZs18G8BchBzER4hy784wQq4EWLzaEbtzXNxr7tcscpU rOJ6aXZO9E6+4vgSMCBMYZTKEZlXydglC1wvHZbsjXzqASGcAs+9R+xQBKWH +FEHDAgM8gGg5odpIetYays/+sCAvouFlCsn+PzFeU4LXAHbQui9vzpQ+j3M LzVMy2Lr6fvr58C7u4+QFRoszPDLqKs9o4/fS4eEnRHZssOBWT8fYHardwu/ iR/hhVHg3WwiNDowyODfRjBg1DZwVllr15tg7YcuAX3xontMKr11XZwb927g wpDeBdAZd3GA2W6P3oJoIjKtvDClMk97hHTWWQtX+C0FUF+vXVDAaNosl1RN hKRo7Puww7fw55uHRNhj5YMfTYF4V7GIKLEbl8zolBbMbGfx6EIF5OMx6Pt6 c7P05vgdLrQycrwVmfF+xrBshmU8CnxgwkPKn9QEg/qRZNpdyvu4z9CWO+/R XbGNybqb7yZlKXKRaEt2APEtDMYNM2QZe+t4oiiy8q08gJGHK0FB28Aw3UCf Uxo4HOHGi5wbb4lcJKziCFgiWNCGEa4xLDOpFL1wwJcNX6RcdZ+w3hAHiXxF AkWAIArf82GqAdjlPJzPQ2/xt78r75ov/sfey3260jbUQ6swxURzCzsOq3bz ZWzoNv4Cdu9R9LwGzX7/Q+Fx7GyXnkfeg1t+Sszl3NOVC8PuRkfeKv/cCdbO Eb7BxyyVaOH5JRKLm/yj9ZdF/kG5OXPsUP7RZgXSVQCG3h3YDvlnYAat/HLn vjheobUvksyaF82m+wQMXtEhguXicXazub11g78Z7WPr729zr8mSLX79Bice zv30MS6QZNWc3S6du0JpaANZ/hdeUH4Drcu9uB6NbQNlzguInM/ANAATKiwU iBe50ltsCOEOiA8tiRYEMl/Z239L9uxnjMWwh/ZE4P4DFAQe0OPeLmBNxp/e tf1hNhn+VXkTl3jbjHVFlBZ92/wXPDwbnQ+VNzBR8IESd8xbz9AMIPoR642f U/MNn/5N1bp/T5/HrDZVjTwjebWzq95oAqx2kDl4SAA0d74JsCvQD/A3o2C+ flb2MpoHSq7auOGtH7y1s1gE+/sEhiawgkZE4OLHRg4oNLQd/OA5DoWjuUhI HpKCR1gVsYBulT3azgPlxevw6HX44kBhhvaA6R3p8cNneJph2h3TzDfhU+BB CwZuhCnOZGLW1Xi0IIVrKgZTem+PDAi4FLf+2l0xdJwX+/vKu3fKHh23fWV8 fX5OB/1fzfhrokLlzeTyjBdg1EQnoMM2y8Xq+0ghpIlnz7bul9WLDFLVTnr2 w90M5DWpK31+9AYWIqyD2rQL7NQXsJcdfBZitBJGDYOUhF2K8iv8312GbtyR jMoVyAOMMooN6OiHdQJQEmECHtHp0U4rv11vwMfYi6fNn+KC+wcKYSodxJg8 HUPXmd+TpD9i2Rw9kivbIp8sSpiVSXiUVowiDbWm8hngx9thlNT+Bb8EV/ZI qf+CgWJnQzJcjX8hh+N2vvglepG1jTzHAZxhg2bQFoUKwwGpOCkRI1d5ZNw0 /NX6YQU6BZ7+mudKHhO/mi/RVtvLPwX2LMGPQ5fu88r/ggFimFyXPxKzxoVX LvXI6NBn/Ck6TJmS4vACRC2RtT2qe+LnmUZ7G0tIk/bvNnBZ7RBzn05Z9wGD W1mF7QMl9P7pgjGxl2jEfVIyR4Q8Af9tE6zeNn9Fd+C3+qH2ReNss5rjYnBS 5E38/oraNCfgYiDDYsmLe0YMGTB9lF4f70E9Hw7eD9FlXYYk9RVEF0k0FMrs VIoVKsXIMWoSo/GECXfApZB8PJtYTLEV9Fv9oDUllADyN7gU4Z30ksXKDIHH z6m0ACXh0kYofhhMKEUstpmF5NPdyI+c5Wzpru7oc1iMNujGgy2Ga80MTWqH Ho0jeP0GDH9KMTYpIrLMYSOALP6TLt9LMgxMSRpf+Jtq/T0pT4MHMUq0/sZN 8FYzbAFYmLMe/CaqDDsHk34v6+4+awHFa5ZyijljQAdkwQHFe08iVXTWIoXW D+iMA52rT2woaDKcXl2Op8O3aTES6coW50U88chiTks8kgX5ICuUPCAt/Djs 25eT2flwTDVx3JXDkPaMpU0WfqQ/GJ5evwfdNcVAGBgSmXeu4HEsML+hVa8X OHNeg457He7HqxjTTjAvwNCdgQPtKHtxpftSNgcrLdC+hM/YhYS5575DAho0 KLS69e421P6j0zBM9+nJDCRMB4mJO9v6YeFEDvYzXjvorBEtHuxaT41Wovb3 wPQGBR7PsVSLo2T++c9QE3nc+iFVEOkyGJKjGeJaWz+gWU9WqGZj7sCqAPJg /3w1nE3tCQjECS4zwAogCCKJ/0hw8CfpK12J0mqxyJ8VjTxMbL5U00OhA4WL R+78+R2dS43CEPw5T/UGz1h7W2wuzL7h++HkpPj4qjcYTE5yTUyWCDJj91O6 dOrC+3vw75ZpP5dMKxO5J/34E31zUKCX60/+FbdrgtakvVy4t85mGZ0wDxu/ JmNJJScdbGoCpMsnXju7BqNvkYlishgQkUTLExQqkTx2Mc7LXH70oXwqa4jH hz8obeVPfyIF/0KnCxUeMulj4yflPozM1eXEnl0Mp9Pe+6FYenLMJisIvN1S Wn7NmEFnXjqrcZBBdbDQxNzHu34XTPz6+zCJcadcY0LHyh79neq/feRnO89D IIqhBMV/dKleoJhDZeCTbXq0jh/WuIynZtXOOpZjX2eNiOPTbmxx0AB03BrW pIuXKGbgUwlJm0BLpdKQNJhZi2AUWAYfFLEHWU0ZmYU5Q/ZmfM3VfFAYbR4F LucSanyGZcZkVfPb5QYT2QLjAFdknt2wr/yJNS2SWtI+AfRA+f6X9veZHknK U9MVCgC7wBC4dR48Mtl7Z6DthnbupZNbUmMNVlzecgiSK5LOg7ToZrEmr9LJ gGsw+gKxlZotaMgoeLiXGGGlgdoDa2e/wEH6rE08ziK/UnakjCjxE1nya/M/ 4/8dsl/sfJX937alm/p3bUszDb2tGR2T5n+a377//UPt/2ZSRDaBDe6Wmdwm cI7UK+7u51fYjNPzm3EaJq8YhYoHsOiAYxq4dH+SbpcSjtF4jhMq/hq9YrKH efeAD6v3G0lNqnZiFLb9wCdV3Id19EzmcmrwJN7577iL+IfdOvy2Z/htz/Db nuG/sWdI9g0z5dxAnSg1x36nvcP8LuHvuh3I3737HWOqhXB5MaZKTTyHLjN4 gl7y5W2S2JIafi1i+NFoKgmpxCYgzhQiA2d0k+c3jpaWwv1prJ/aqXSnh27P KbzdNfTnBqO+PaMH2rzBD8GR0h06FsQqzr2FN8WdO4Nu5uWCmcSPiUNDdEOB RoaYHRpufCixweNNKOzMi9chWEe/vHhxkGxNsHtINBC2l1S+H5dJ4kGpuR4H x7B16FGjj5QEE9AF/689j+580SL7+/t0F+tfyWZWvkm//NJ+et3WnqBNpPhb WuxX/EU85SJ4E80p5QMl2W6Ji5NgRWGnBcp+/+L7uGh8rlQcwSlxLg1VxYsO CsE7JTeKlCVJgInDROQAAWLshh3u4pZTaVjIRmhG8YDUn1JPO0V5IiSyXBSo sC1m6Yi5EEfm4v4QD1UDIcg2PwskhYJW6lFhc1LYhEHPHp6kYdEouKUeZFJ/ 4obG5LC6DyevL05eT5XXN8prV3n9MwadG8SKpdA9/DWLiNufb39VB36BX4XZ UtmJNCTIo3i9wt07WNbxHNPX2TCR2VygRkX612+fkvPzv7NjAL5S/rcKnj/x /3WjDf/R77/1Tvub//8H8v8zKco+HSm5nFLuf47Sq2++7Ddf9psv+82X/a19 2UzLNDCm+DXdWJkU2K2d25Cc8Rn+FgmwyCWhC1zMPS0mnZZzSpsv6Z2H4AKO B7OLy8FwNu5dDBttzovJ8Or854bKeTP9cXTV0Dgvzs6vpx/wxHzqYeJODnqZ zQe8jW/PCe7mMPGCu8d9JsEGHubyb95gAeqCkgfl5NC5D2Kxiv6mtjUje8rw gVKm/u3CiTYPhAjzZ0xhQazdBAfLbVx3kjJJ8iVpuuQLerLY2rkDc/dy9mly OT7/Wfk/8M/+ZNizyb/syfW4f6C0rXZ7f1/5S3GHNjWiQYhg2SameTF3Mq2F zM4vgYcaiOTXJa1MDWz3yQM3rqUy+7Fx0l3sIQq6AHLwH+gCZrr++13IRBdt ocMXSbdgVsB6ECV9esHbEOe0lWkqgQMZyYZlmTRY4SzAr5j2qBcVyxLJoS00 gUjd4YKGIxLRZF6g+8fsf+eakIhoAo//Lr8uEEmaw7rxoEtB3xP6i7TBi4Rp BRecP7SUBJ09OK7gTpJ8qIaSTaADJXHxcxxMUyQUZHg8wKR9tFB7//fOkUzH rJwdiSmadLeWbDvHXxVi9tQN+vEtatHAsvnZfU44R+N58ExTYk0P5eb37vxz nJtFrQuaORNna4UuGAN4sC4Fg7Xm4JeK+Endbx//E8ooq2cZeaQPUgn7VyGW p5kWq2azvEQkEWcZ4p94aUExW5+wZXbrBTSduZR6mbxisuAvUYukiQAkwJqm waM001Vly5T1XIZ+rFMOYkdkdj0dTqa5GZNWUkqXD/jp8hWTKK8eX9PMPRyd WC8WJ1EalhFMoya9HgLall/E3zJa6vbOxYQFYZyJdm+/Ji+LZG+Rqop1JR2G MWuQQUsTmkCCgmdMCqXG8/9l7+m/27aR/Fn+K/DS11ZKlYQfICU6Tfe5ih3r 1rFzltztXZr1o0QyUWtLeZacON12//abD4AAKNJ209ppb93dphEBDGYGg8EA GMyQq7EezCVJDLd4pE9Z7ytPGDyA/exL9PKyv/yw+rJ66sr6ULuituqPcgVD Kk92V/hbe4ZXDnyRFHQRQ+TIR+y+Pn9t/arh31cWAjYpOyX0CZ0qLJxLszke NVswNNR1jJ8wxr/8Igy4lQVuHZ/ysQtP2q6wTpzL1YGc/9bWhZZJMeLIENl7 5hS65pjWHi4LZevLxwzXpyBe13nwRLkC2kjpQgsx+5ODnCp48MBBUH21RttA qBGhdomO8GlOftm1uuB3BLxOln003SqgB1JOThAZZjziaabyhBsozhDjn/q9 htIL5vmCUj53B7g3c/7LQb0/XfwP+BZF6vzXl0Go4n/c+X/dyj/2yStLQs2p 651D0t0h7t0h7t0h7qc4xH2kqcFTW9ZQKgUZRigMHgXBo0Ry1c/AkuHzwKx9 fJyevH2TdtAEN98Wy+L4uLOBZ5x46XU+x4f85KW54qdteCWFFs1aDXrqXVbh Wyu7v/P57AK50UFbTX/EyGDOh+fHR/vD7zvlUarO26SOa+ncFftHG0pDRNIa 6vPxLmFTbeEgN1lms5pOT9PpGyh/NJvTGYB16LtWBftI5w5+CLQWt1OY8Yup i5qu7KCVzi461VNz2MxPV25bqCZ4u3Znrt2A/ccZNj6d/RcEgU/+/z0p4zAI IxX/Td7Zf3+h+3+WIif+m/8o9EXgb4YJ+slf6+6/hNIY/80F+rEWqDTgMIRa f1NGm3780eBCC1wo/B5mNpNJXRwzir2mQtgejQ7Fd8AEWP5G2r4o3TaXaDzQ 6SMsnypy5f/bwGR3FvydBX9nwf8numGwwm+hgv9YF4x1d4gGr4w174crvPt/ X3Qt4++g6Cf/5a3x+JB92TH66NmHY6PwHzsVLa93VZNv8dCFHdZsXLJrcj2i +8WGCp/AXuPvFrOsY5zpuX/slKNsrOhkvAGf8jiaqpU+2Ayj7rJGXz2hp+/q h9V3iPGm8C4+v/hhNQZeb4rPsx9WgDcve3rVo89WgCbsTjsI89+Vizj/wFHT f1+DZR7CKtoUMCtmgBBFcXK+fKODSzhHzXwTbGyTG7sQJk94dAGoXgirdROv 1PkNvR4bCm+b8rKNYzD89mi8zalR+UbXrW4NJVh3+AzfNCfpuqSpujGmZn/4 1TDJqKZetDtWxDb8bIVsy85PTz+ATn0ZW042KBfVb4Bv9RNSX/1GSsF8o7g2 sBM9xsh0NRPk6icm+loaIZUxcSgwLfT0+LKJytWGSyjTortVRjl6IjxjH//G i2REeXiwv3X4P8YDh9l6/Zvk3+pvYyRns/TKsNLH17r6O3c75a2yGg7mwLWv kpm+q66SFWy8ETNv5Uc/zd4qM3/5Np1aoSmqN42frd80euuf5uXzHev+9deN y0XBOMmczaenb60B4nl+vP98AKPte9rDh3tolB6//onLZdLWKpWe5YHQhA/o HUAn0dhcQhv0ChxqN/UMqHZ0vy0Vn4eGhTQVKqWyQxo+685+uZymc3dO8P8A M603ulpZmIBsrCm6WhWQzMjGR1VK5k04NxJ+lYLdCksGRgqh9zkFljbTwfhW uHNBiaK5DHZmg7obdZwbvsMeKTgkqG90cABrvOLFYPtwEWnfiND/SNLIelfR R26MOHrgNltms9e4Dtznoel8JMYc3+JmcL1cwNUYwVDcpz39O97TL9f29NoR C01u2Fjsbn9fGcFLp4nLFS3+Wp7vfY6P/r6wwjjZF/R6ijkgdCSodLWYaUDr A4SODqgC1ISBnvjs+V6pixyg9CDrSeX9ZBWfBsAYMeF1fnY9yOp94XVB08u7 a0KmN3vXBIxz8npg8R3ele8xryXqBPgGVY6JQ4uJDIz46nBvaBZaUttWlra7 O+BbACBFLdZlYYdMDo1F3ZbicqYwL3D3CWBP89NFE82Xk2pFbrP3G1p5Uj1r 8wH0KQOv/K7G90pTr2ywtlmB1vVT3lh/PCDD+TI/W1Gw0rkO4WMGwWxxmvdy UK1+a8A7pIrB0GCNkCUMaiay7JDqgs3W8kct1spkN0OpV2+1av+uxZpHkV0D /1TLtaL6NyzXDUbIbSzXdzbGDWneVuN6XKeTeZKxMDdpZfXivvJuvlYtU2md Xq4+t79lxcyP9lHCzWFQqZzdSjXamwsq2vtaClWBXFOo+gjOVabKqnsi+ISg xqVR7U8f8/W3t1GGOOUzus5js/dyz6Fu/AAKOfo6XzU8SkC2FOegwYyS4Wh1 52DB4uOETNA5uAovYmrh7KZsOn/86ZFlL2zYJLAipe7tp11mRb2lM1Cce47d 8ERYiPFGXA8yFthhJC45stRNarq/NUEpZvPsj5YUnLG3JCSIPvOclJD97kR/ vFUp0ZuJ6nE3Yecc9PwF5QWE/zriwnPkMlHhGjcoJmqN27DRpuV3TUrUt/XY RKT3N2gFr18wSvm4LJhNk3xY65vGqlY6oNAWDkamXMmaRMNF4rZk4xprztWi kUJBqium6vFPulwuprOU/BtuQ8tUxYeWIuu+ypIiDp5f3hNcpn1uT7Bc68pI F71VEsK2oZQRdVNyd+eM90n8/06z6Gbd/67y/4ukH6P/XxwGMvAiiv/jhd7d +4+/kv8fSZGTN971hbuW+58GUv/+5HL/usN0Lp7tH4HVn/H76D/WZU08fxoN Hg7EA3E42sI4v6kY5dPzs9nqAzvjdLGGdhN8oGLNw3KwgCpvTkswxsulPegg Rv6DoNsEU236M6r3UGydnKAypebosAdb2HeY6WaD/ISmOQa5h80suiTRcni+ rHqSwd+Va1jFMwzdECjH6wy5NyvQkydd0oJ6rwk5pPe5ovcp0YswtjTJ98iT CxbyUyDhDNmKrlPAVeXVdZYX+Vk+n3IWWQtLhKKznhXKcnCJhIIUMwVpWoBo dIUqiQZpnb1LMWC7eL84+2lZErtB3lBA7/J8+kaVEV8cqu9Rezs3r2YBtr+S C5ewYINC8DdzQaGOblSAGxPdxP5G56/pYj7NyatT5IBFfrahfMBO8zOY2vNm PzB1klTjK4Yg1t3F8IE1Zlo4M55j5Di25jCGza/hM4a9IeCfYBIz8eM3QJny zluKU1DW6KN3hjnd+N0G1VfOiao1omXj7XrtgYw8wts5RcxD/XREPWK4hzqI Y7vCXJ1jZqEVP5eHgR4DlktMLy/OgBIVN+FRGYRmBIqlZ/3C9ynWT9Rc1k8p Aqs08EVk/QpEYv2CltL6CS1NsJxR6AurMIROfesnugVbP6FpaH5KX1iFEppa cCU0tVCS0NQvndnQrczlyIvDg/HB8d5wNAYLjyzdl/JV1zygwUUFHW8wRqQN ZHtOKZpMcxiydttpJu53le18v+u82anCeprXwVpvqoFeBguIO1Y5NhzSXhzg zeNhV5R/uQYUzIZRD2WGb8erEDQIF2G8lhzuP0Mmiie0VfAu+h7l6/gd/0cw XfEJwWz8+phm205XPOuKXVLiQ9LKsOMDJqCC1cvA0p1wO+2LrgB9+HMHWNq+ wHCk7Q+djvgFfv6bf/6MIXN1/Wc19X9W9T/Qr3879Xft+lD9nwge//zZqjS0 K3Ex1v1FA0PaYOi3xtvHe9s7Y1AdK8oScCFO8mIl5mIyW1Xosqoj8LlG9+uv RXuu8IWf33wj2mHwAD+pfnaQicjFXXZrHg7FSs9QtTpQ5A9MX78UfleA7RFy VUmJPg8XSk3OKF5MivFieBlMs2y2Ug7soMDfYawAndAn5SXaGZqddtoVk66Y dkXWFUAFhqSZdsS/xA8bop12MDbCDtAx6WBKFfwj62BiKCTsK50oqg0tHusG Txw2tuETNFp2TAWACODoJ2w4y0F/dg1Mnt0GJru718Bk9zYwGQ6vgcnwJjHZ MBmQYCl9iyneZnP1H8w7xIcJFY3NNR/XllHrxy2YBPQ3MYGNyk+lN5/z0pN6 oKr69rGoNkLtirp7MP6eI2lccIAg+DYkr9Uv1FdyXoSvR2/purf8XiFH1dqZ zVXqUyqzgPyqNxkUFoz8f3lWiW/z1zN06Z9T6YJiONG7BRXXTF0JKlA8C3Ht 2Shx1b0wKzRZ9zVdLeSE+qFpVz8xf+L5fPXSe6XDf5lv/ivtpalTBZ6mr0Ff u/hjKzaiTCLhEhAuczkD9y7inoyC0PMfr9fgri7yYpqlk35SUyPgGkl/kmbT Iq+pEXINH8NNyF5sc5xH/ZxHsGTwQ7T/yIOzZL67u6N9ihkOsHnBRl3yY5AF 2t3lozHqgNUs9aKM/Q0h6odNC9O6LMF/9srZceVI/u55wt1dPVXcZl3ahF90 yRLH9irJ1kBlf+OrQQQ1+YAr4ekiE7FU0bWwJUXOt20iTCW2JpGw/IW4aHsX 4U6ZyEuxzuoCVlcTuKsGDOolnZdQU4wrbdhRbBZfX15hbV6gh3HN5/qegIog YfQVu4B64MYDZoWmyxjasKM6xW0OZY/GX7DxWs4mdqZupNR08EQDdk+CjYG7 0SoNUuRnibhycic8wJQ3dZQ4arCPDUSDZtudf90qWPNQAy2S9kyUaD4WM1hj 4hD4XkogfkK2dDZal/fyBTV5OXtl4GuR8mqyBs74u04mS37cZ/mpemPGkk4s tbhF7hG/jWFfCI1WV99Nq9GBYXa0f4ErRKn7t9FMq1U+dQuBUim81WfNo8+h QPP8nJ8tZj/rc4ZavaOWJ51E0F03XD1iZfxF7VDpT6uTa601LmCcry9V5g5X GSmVklkaZYRJ1+vmutpVtvFLtzIVu6JfqosXsGzhoQQYtVGsFJE1jz5KGRU0 IRhRbMxQvoYOOuJvog39qLndEZui7Qde+btiS5TqX+38NPUl9irvqVLN7Ule YIRMdHWFYe6UgrsGj7liuDCiyJo0g/BIxR5EzciKTJTzzY9LKP9LApZjysTl jA7fZvNy42GYam2JrVlU4mZlN9dS03FmCO8K3W3NQ6Mfl4qO8rqQFiqWc2tn vuGqEUUN1XVu69h44PdCa5OAqvNron+VybFTioTKhg1ALH/58Gta/grgV1b+ CuHXBafPxhtAPsbArZ+yHGJZcvkQ927CZ17uwA7KMeSpz5EPOzvvIuvFaSp7 MMw46awWULFsdEF4jfwAW+T9aW/SAzmlFoFpwdC50QXhPvJDbIE3Nj0vm3CL 0LQoUUqxRUgtJLaY+pNsmuc5t5BNdEhDRxH1pl6RFtwiaqIjMnQA0b1pHKTc Im6iIzZ0pP3Qk7EfcoteEx09Q0eRyTiJPJ9b9Jvo6Bs64qTvJf1MjUfSREdi 6OhPpCx6mnLfayLE9wwlBfwTTSYKL99vIsX3DS39JJpmvYkaEz9oIsYPLGom CabuCFSbsFG8QkNPkSX9np8oLvuykR5pjUzcS2TY17hFjfREhh6ZTKTXDzQP SADs2aMIfPZsjUCEEbDUxX4eRLGmr2eauPSREAVE3tST3iSUnmrSN00q5HE3 PIHiKI/SSKOamDYueTTCAVGXJ5N42kuVdAdeEzGRISaLg8L3okw18ZuIYUFi agIpfRmpsQqCRmIiQ0zWT/087itigrCJGGkR08vCYjJVkyKQTcQkhpjAz/1p lmstFTUSI62hCcOe18t0m7iJmtAQU8gs8rJ+TzXpNRHTN8TIKEp9mWs29xvF LDTUpEke5okXqTZJEzWBIaaY5kUaFopnoddETM8QE/fiwguyRDXxm4jhGc7U 9LMgldO+krMwqM4iNby7u7WCF/pKG6VhItUsCq0mLnXExJCVXq/nF6UQhdI0 qZtFIZOXJVlcKqMwMm0q5JFIhEqB51HY96aqTdxEjW+oSeUkz1MpVZNeEzXS UCMnWT4tUs34fhM1PUNMEU8mchIrNRImjcR4hphJPoFZ1FNtpNdITGioCfrJ pJdP1ZyQfhM1nqEmT1M/6BVKJGTQRE1oqMlkXoReX8m3DJuoiQ0xst/3Mz0j pGyiJTGkwPDLzAsVl2XURAqLt6IlziZJkutu4kY5iwwxfpEGvameebLXRExg iJnKdBrFse6mX51FirzhsNaSkzyLZJAEgZY7mZgmLnkkRJLlLgzSokiU9oo8 06RuqZW81E5gpoapbuObNi51xBDJk2iahGnJ+ChoIoYZz9TEUTSJkqlaWaKw iZrQUNMvvOl0mqj5HclGajxDDWzFi0L2lDKOoiZqfENNP+rLKMuU6oniJmr6 FjFF2u/lUhunvSZiWIqYmiIPpnmcq8ka9Zuoia2hCT1fhr6SgChpJCY01Mjc 6/t+qqiJvSZqpCVovSjs5X3F59hvpMY31EyyMC2CUAl4HDRRExhqgjTrZcFE 7RrisImaxBCTT/pxFiaaGKmmUXmC/NUTkT4uP/Bh28R8COjD1HwI6UP2h+xd L5xd64XZrvLmeanOkczR32oh+ApAuBfdnYdia7k8x3M9fGXF7gupOD0/Wc3e nlA4Jbm+k9Vb9Mo9yvVuUdTlOJ8K15wBU26FuiPeH4l15dkdMOBHOkuD/3xN rcTsq6/w41f0Zs8+eWQEXv74yjlaIQaoc8uXs1d0llIU5eGibiS+En5tQ9Py m29Ev3NJ++Dq9n58GYDwagCBrAD4VckEb+5LmagAcWSD5eWjZEIfITTKhBr3 q2/UblgmFFdnxFHncBzkg2+6K19JAOguHAb5FzU4dbUCroVDWQ8m5AqBLCfs /mJFnuhvTzAUyD2k5GSxeMsBr1BzzLP0LBPKL2RW2GfvVqgrfcCkHUiah0Hp EOGMg/74Wwegwn08NDdsX2e3FtffTjzqvzXia2gnPalpVz7xV9DuRNL54+hu l3FhuLeOkjiedarD/0QXdPb/fvMJ/b89GQXxWvz/0I/u/L9vOf4/ScKfPvy/ eLZ38O3W3sNd9sU+3N7hYD50yVV6G5S1ye0OA3CMxPINRq1CB1JUTLjQzinS ATZczE9IofPd2Onb2Ul+pkM/0pKrXdAwWyC5k+KF/2oBXWPgbuWrClro5GTx Hi/Z2D3X6l3ls8Z+PexpthJv0iWFwExPMBcT3SxOcoynxQGyWfEODD4YaVC7 iim/fdNB6dxj9elZbvalvuVqwC/xOp/nZxgTczGjeKgU0QKAr0U/Z+WpALC7 Hq6mgQVr9X5B1/nouZzVAgH2n63KUOuBASMtMMXi/MyFc+NR3Z1qhlvGXXO2 LEcky/HGjXy35+LN4r3NbKtaOlm84/v4IfRGPiGmIsVHndsd8MuoZfkMvSvI f+T9DH3dyc9E10jnepap0HzMnyYpIPBtrNuhFooPjXXaHZsFsIrTLHtD7z8E RiHWntCDh4O7Jw13TxrunjT8eZ80qOty7ehhq2R+VLuhd+SVm27y0eBL9PbW t4OnHe3OwfXY5SFQ9VznCwpofX6yEME/YynaJ8uJoOSKJYjK/Tn7y+AFuuWQ xl441ODXDeVBAouF9qcnn0bHmb70MsGTF11NOT1U3gKUVa/xGkBDYq8Yp0f3 VYOPB3UOEn8l+19HPP5U9r8fs/0fer4vIy9AE9r3/bv3n7du/2tJqNkCJPoF Jtjs+PxoM5Cbsu/a7FsZqkfzagDNBUx3QM5FoK3OYUnOT+vyGPQd6LC7gA4i WYEOEDJeGGGBwSwx4nBnsARcoj6tkvCXZB10zwKNL1M3PX8ziuoQVzaRDqe0 vzUSw6cmhsA66LguJ0VSBzrVwNGUUXkgoAtYNIrZBb6sYLpSwyVlwpC5QtHo MUQ+cTNPYcWDz2eL89d2WlOdL3gdz6j6elZ6m94tZKeQZp+HT9aCTa+36XnV fd4U7MElJ6NYvMdEuyqhsfZqA5SCyHuIyyaI0Xv8Y7k4zXWUTYMSgiOu5RfT PGczkHj8QFvlKnxXARLWb0ri8QmSafyZttd3yTnuknPcJef4T02vpw0ATq+X CN+H9fhRIkX1kTTn4bu3UZ4kbB2Nd4+/2x6MDw6P97b3Wy3r1TGVvdgajepL OEQwlwXSI2/y9GJ2en6KvAjYP+DS8OkanFU6fNpqySDZK48zKnsf8fb9cQqK 7PhNdlbug86PaSswVTnkyw+zTP/kIyxemZwq72ARWJy9rLDhlVMHV2jcN9G+ hmruYphhlxvwiVnRst54D3a3XnDAHCx7Nt4lLppjnH8cU9ujpy+OXxwcjrFU Rk7xYDB2i93mVqxm6NlbK1LBlqHMXy+jcMmI8FoRhjyGgpDFjAJk85qijxf4 5BalCyaWat1S5Gzvj4eDLcxlcHy4/d9H26Ox6bymztbg7xYKtUD+CwamFTpV BoODI6gC8qf7aMnGCqMXB/sjIChqqDEab42PRq1WbDMCBf8fB4dPTQe92mLC v9VvaEqot5KGjp9vj0ZbzwAz36uMOhQcg/Tsodhgub8+FFuV8OQ8Gs5wHI22 D4/3t55v2wLQsjBsVVhPAmsKHZ4P9oYwKjRDXV6rAhRRKo3WUIB/vxsOtkm4 LDZj+c4hoPf0mHbpg4M9i8tWKQoqcMRis1W4vz1+vjX6e4XLqvDw4GhMk8Nw 2CrdGe6Nt1np+H5N+fPxEXIuqCkaHDx/gTiBhEINh1F7B8+G+8e7BygzLV+u Fyl2QGG0XjgemNluC8XB3lN72HxXGpH3pTS1fEccnw639r4FMT3eP8CypL6M pCRw5HD7+xfDQ5qEKCeOBrHYix0GQU3h8MX3MDZQGNqFONmoibS/Dva2/o+9 dwGM87oKhEejkUaSnURxnHfafFacWHJkeZ7SSIpsyZJsK5Fl1ZLzaBLGo5mR NfVoZjIP2U4TaqDQACm4rltCSUGUwGbZwAboQtomscsGmh/KYowJ2d0Aps2C KaENENiylPo/59xzH98330hyEqctxJDqzP3u49xzzz333HvPPQfHtzlkE3+O JQM+20gyJegfnx7bNQqIwGcbUcZGxkf1t+aQjSgw7rvGJqQIEn0M2UgzjLNv hPDFTMgk4YAzgxQfKoeNSrAXhVSUZdvHUAqHbWQCnr/7HkWPsI1KghfGh6Y1 s4Qj7hkmdo/g16j71x0wRJPwudtlgIYmJ8dHp4fG74hDP+5oDvcsmQfGEngP ssXsRKjK+P7dE6PN4d6qdUyIWRYCkUDV95HR8aF7aMDgc7Dq89jE5N7p+O7h 6dHpKVQSqjLAMNtyhKsxYIYhLSNS9VktPPA1WrMwI9hdA8FJmE2i/Z5aGOos saoski9HgbJ7cdGKVBNy197x6TGzM9FqYuKIxmmhAYFsIybJeGNt6Q44WZak CcvqYJWYGR/bNYbzqTvkznFCeHWHDR2V1RBres/QxNQ4zZYpddgtzJqm8DNd x1kcNLhaNGIm50rG3MefbJJayTazdNg1h60WG2PAkG0DKspvdrYYgaEaA/UL enTnKOforqLmHlgqpvlrj1P5Y0VHlnYX3NUZezXpBO6WXEGnZDxnBwknJ0EM OIg3NT5Gifa5tGeIEsNVTfBiKqOQVTUxgRPf1EMxcdue3UMjw0NiMbSNKVBO KMyu2dX3ajyMtdfkmSp87hyaiN8+NLx729SoWFextzaGhiUqvnN0aASUAHNB D+kmiXcsFsJTVU1Mj47TGmfv8x4q5ewwYjA8PjpUxag4Y0CFmSYWti8DQ1g3 cKTCx64cW+Ojd46OO7qu9hU8HoGqD0KDdO4K6NP4bljWCEHVpJDbmtKOplis w589084q1bfdk042409D4zB1JLc14+EtUoMbc7RE4mdo6p6JYWev6At/qJZY Y1MjE/w15P6RKo3fGQ+GAvYBcMkSDNglBGW5c2zP9F4iXJStRYXRyAif7lrb 8VR9At3c23qlgr/B0LdtTpeTeK2TmmkzM4jFUeRAv42J1DzmSiST5TaXmmQY ueY27Xe2zZlN6OzAAm3JbCadK5eqcqCYwe90Sl31dSeoo/BxLp9NuWeAGQDf s/n9eMpc9XXX6ARo1m14bN6G5MLzx7TYaWvPwYJSjv2/8gqudv8quOC94RBv 3B3GiCsM7CcyVgV76bdoV6WDrDkxsTZKf7kPawfm/e6YE1Z21KX7Xo3+8j2q qrIKB5LR1UhQ5nghkVmWfoYH/otAQ3ElnTW6JMLMlouUdK/jhOl+W7d1J8xu i3OWyaExF9rTkVEx/YDj6lxEl7IfElVShTgeTdY4SXI/aeJjpGC3/eSolE4W 02WdrFG0NgI2sGkva+om5zLZVLwATdEF/aRwS4N3WflZ8dF+n09+RMqJ+YKN NrKnTBmsaQJ9NiSSZIPCrcpberEajL7POM0aGd22d0dzZrZdB8ntEAFDdJ6p 0eHdEyOg2sC6OTJ0D6gt3ZGAFsi7hu6WpyZCWzb2TbgATuydFMq+qU8ZhaZw ux6whW9DgQH7UVAIpoTyaDs8pK+gAGE0TPg7un3sbstqgy+b8MumsenRXW3M fcLZTHWN4ijre+/+P3URfUAvef8f7A4Go2EPZogEQ8HuHvL/HAxF37X//V7y /6y4SPiAlk6go5uD3VYo3Bfu7otEV+YE2qypyhJZeYK2V2y73Ax2WXzvnszP z+PdD4VrQglEF/Aw4vl5fOxFt+1z6WxBXqjSbWRIFReO1Sp0UC2vXA3zA7ym cbn2DgUljuHNoZgVjPVFg32ArBPHYXV1jFe6iGpaeEkjFKbxDkjc/8OqUKS6 pWnCnnQ2HowHARG8EnW58Q8FnChEgFKRKhQklVJsmZBOHpA20KhBC/Nkq3S4 RPeFaDRdypvGERkySOXNOQfRpct7vKTKCYvEhJVEvfVgmm0308oQulDMQxFr plLM6TBMXBnfEEpqCPMEcaMvnuUpYtDyIp9Mof0CWuWm8uUymXQkM/OJLFpY 4E0YaIJcPRaey5fKaMdQKmPoOnFDCdxwKCFLiYZcLth7bdQNBPrg/0MBN8OP uXI+l7UOFvG6toh2mfTkl8ZUBI3Ca0G8x6RbQJgMcdDG04VyewcZPBC6+WJm P1mgjWdwagEn0YDNiXh7QFNQrqwxKJ2eFyYic+gUCZDfj0TAqvE6+iCaHNPV P1ug8K0z3Z6iAx1qD8g+k03PWzPpJI44oJ0oIoZUmlhP3BmQmW4RqzuI7sjy C9KAJZspl7ObcFYDYxSyiTK51zlIthsZOeRZZJNEkc1ck8VEac4S1hvAWemy UOJdZlYwpgkfiCLhI6G+YLgGW49MjE3J+2Fmo10wtmLWAzsU8jnkCOJO4AL5 8NOl2Z4q46doXyC6vPETcplh9yRIPDK6fWjv+DQHb+OhFyY8WEjSNJkQZuPC yBXqQIPgTGk2A4Rshy/JtP5E1QvTGLIhJosrNGOURNXVd7h0r3vFJlJSUsiZ jGJA2RkXpXU1z2vuGnBbFi9M3Qgb1S0HwmQhFOkLRpeQlLDUAE0FO5GxvLAR OsjvKGbSSLJSZaZcTFB+Ns/JUpQ8KVoSyQMYTpweV6BuJ3Yfm+TuwzApoiHL 4MNLYXeWADGSXBAWsNrCopAolQkb9MXFckQ0QoYH9MhC+HwsFSrFTL5SstqF WXcFSHOY8pcTmSxXxytNSZtqZ7EBUWOHWh/y+QMw3w7CzhmFa/oAN84NIwHY IoQEZAnxx9A0ZFuA717WrVvnMiKR7xGbtmBYIxrqtQJhZJ2oA9G9hoGaBTKq WMzgy1tEqAsfZsiGaKGT+YgtEiTh0OgEN4AkhWetyclJfrqhCmbIn3JS2Azn MQcbrIhey5mAdtxoE59y6YgZ2wIWE1iqo1XawoVYfwVXECvjYlj7BQMXZO7H Vt74aJ45PQhrKRn7dRPfJEEjypMJdzZR3J8usmaBE/0gVkX2gsLCjiyaQFMT JxiAq7Rjqcay9ztl5BczGg7hMAdAcXVQZ3vmEE0sVGi0jEPCx4Vuxo9BirAx L4DgIImv5d5sMS0stWCUQN3IHu6qZQ6r0Ojpi4ZAhXaiUSyV6dFZNo3dExMY fynzKhCMuxIfAGZJIq0qBeQQYRqUQKt5lo3EMlkQVJiBVAiWBsm5PM4tnHb0 3m0e1uWuWga2BrKgxYZib3pqRO3VwdiDXh5409VFqqoL9AV733R1YXt1JHnD wTddXcheXaAvGutDWfOdebP5rknpuyal75qU/ocxKQXC5TaUSfQTh6rNOp9k dFrFilylU9amBUu4mjiA5OcsXUnDp4Q4BE8mS5nUvRj7pE0bq6a6ks20RVvR TEUytvVrS9bm20qHS5vJCLFrbosjuZRHVbo6HQ/Mq1NRL7Kn5tIYIqi8OZOz pyeKhcRm/ILJZi3lVCZfVUVqxp40m8yVs/akwsGUPaEawyT20Z5UyQH7Ogri q7aEo3ZQm3P56v4eTGRkB2atdfIx9sTuqZ1DI7vv6jBzzyVS+YNUgzg6BwZZ JzPaDIub26Tm1tbSQoOO+604PxOMBHrxAoRvRHIpt/SNMsZ4fwveheAQzqYE jPecEtZ3EpyvkDiYM35jXrpC4VoFWvFUpmikUCZKEhcpMDkywiV3vJRO5nOp kvzCKqNOTh8ClszRdQ2RVwUNkhcp1kZ6NxlXtztLXWKYs2QX6Fc709kCG9i6 XIDJM1d63ggDHp+FXVaWopCrpDnQfW0JrOfpROh/HDa+Jd76YTpSrgVdp8P2 trg/2YmeEhbMWNyQaIt7uhEzCIcuNAgJ8u8ifoCYqWTLwl8XXUjhUOI5HmbD I2j3T0VSKFy+xQGtjbDAmJ/wnAma2lhaoLsvZd4tr+30YOBtGAyFPVEeB7ST hydxBwsdEqjRPacECuLej27nQFwjPJuK43kq+n2YTZXkVxzJSkkEA2BGtgYs opMIKoA03LSJMmgelr7tNRdDCsXRMLgUA7RoGwD+yEwtvrEBAVSOdZEksNqn xnbs3DvZKbmCump8A/bu1Ezk/Pq+vWNLfR4bH1/i6/SeocmlCu9equrtk6NL VT26Z9cSn4d3jo90mmzf0b/MJaKwqSarauHfwHbQbV4xKFdyJXEZarU7Zmyn 1TYF+83DXdZEXpRMLCQyWXwZd1/uvmJbR78hRt0vIGkAZUByYBjpfc0IASzm HkYM3rBpgwzoK2462kUwXxlinDgambBdFLnVCiqXaJIbdVbkUv5ZAqUhOUcY YIRgbKOlmU5bNyQ29GF7iAhWIaNZCyybRXEDGeE+rdnJziw+mjUezRoJAGdg JA70q0ZTb75RPU1W2uYS3MLozL9JdIDVmhWvoVsM8lzT7pDz1iYrbHWQUMKT 0GJJF2oPouMuUsnuy6lQNZh0X5Fd4aRhn2JobfcFrIQ64RQ4ApM1L8nDN3dt LBG/dlouqHUKQnYsT8nleZ3pWdrQR/YOU7DQZtMyGg9uuNIKW0M8BtxYZEGM ibxvY8I7Mh0SmWziN2jPyBO/zzGpVA6Olf1wC3ufHJMhk1huKHsrHc6FTHQy FM6pA6dtwO5SMX0Iv2wKKmeDVRUP53Ozmf0VoaBYd4rrJ1V9kr5eYAOwbkLf 96fLuJLOHKbVqp1VOBj3tkqq0Eb5Keg4Zh6g4OO2xbfD2dKsZCrQTkE5Ql4q 9aEwpOtEPpeV18SboY37cm2dcsaoZVPJqCrELbHAkwdHseJ3YE82bSmxvQ72 jPRGDM9AewCYXtvjYxOjsOJM7R6+Iz6yY88QLCAB3TmR/zZnX9pRV+rA3SDe W7S3oR7BdbbVxpBWIwod4qbEdFi3GCqQ8kYq/dtByU5rw32BDdojKWfv4HUu B13NwERIzGdAcgxY3DfbR2ytq0R/IMfYBL6ciQ9N3GPLxGTMKrIJpQ2SZjIg R5gqnQpfI7IHFO9Q1ONiK6MeVr007fiBk7W7kM5ZQ0l5W2NNif2cWoHRy0kt DiajSJOFreW5WOK9Qga+ubT55hLxro1xIXuN9rGvuqvWw6IXkpnxqrlktefK +Tn4Q6kdarEWe5+V8zPnX35Eksyd/yH4WVDlbeRnpN7K+Rn+jWRKIKlzaH1C dyaldEmctBqBv8yFqUqMF8ikBxb2A7xtkYyNHwhhoQq68/Aw+s/Dkx2sQIjd ZrvMbbZ1gdc53cIW3YLIFugwV8Ml+1ouH1b9JGefODDhUL9VxhBnYfi7aZO9 s9hqGdcyFs+33GLRTzGOEpFkFs9W28s2TGyHGrvieyfG7u5wipbS4RLeauKO Di9hExh5CIllxjksAY55zNzetjmVXtjMmWFq747ftWf3xPg91kMATuwenp6+ RzEQFQREQ/b+pCqFkPjYCZ/k6DH+mKy4RlnISoTHZtECB8/+yMUG3vyhNiTV JDxhPIh3n9msMM1Asx00FRWlITv6h0sLEyRDpPLxBF6UQwugSupqREmjGGg2 81a+Uiyls7P2UHVaMbP3V57CuHOs+npx2VY1Y/Auk5z5SGiuUsJuChoVkLc9 WxnBiqKM0jKMMs5ZsCedTKPBLd2lSXLrTeQyYlUeh8gp09/v2AtuH4m/f3TP bqv9Fj6JsJGYEdwyoLsOBaZGp421XZerIluNokqM2orKXSOdgOBKlSYju3YM 1iBzdloTe/HMQP+vHV0uiwSVjWI6HbFh8ujYxPQe3mQlObinGAl9DBYMVLGA QQaUIdCPsSl3IshW6SgLO6FWLDESYtzVsoLHRyTbVE1q2TMOPpFdhXrbTuHn ZKVGlg5nnkCnHn6xYImwcc22FWpL9ZaTT7oQOXm8hVXDV9QssmR7VLWkiuY5 T8nIQ1qI/Gh2iWkgd7aWaA1tsnCdFTh0WuZk4e0vzijHIotj4jrEqlOK4AFd VQ1mtQ9wFau+6QGWNb07wOYAmxL04gwwu91/u/6JS67m7ezDs08SkdMnxYVa nxLbe0cmLfEySgnvTmumgo8wEjkai3xRRkrmDFhPs369JO4rE+VyAo1ppUnO JmHrgm9XyDumch4pSuMpgnyiIexqyUBGVcqXdW/Xv80tLfpYvEXxFVrYdqqH MJ2WZA1htWcLRIBZpcd31wc08inMRlGJ4S1eemMhv/CcqVAuqrP6nSN7xAG+ OpbPl8kkUf62vVCSCfxdvcOCKsqiUiNJPd1CyzrjGkCYKonAkNVvlDi6QiGO nRZbTipqvuoRtz84vM4vhWJ6oSqN87leWLBywBPaGsvFh+ixkqFnTBbTm9Ce KilPrpFZJP/YH9Ox6iHDKWtp0q4b77DmqTaUE0KSyW8dHR0wh+V2yCxBi/kK zoHItG4+XzyMetwKTntahMRTCBI3dFiaiyQ3QA4Wbph/0xZmUqIT00xvICW7 0iMncWKALI/zXhCNhD7mgm0+WZEN3AzCP5OiP6JqAPnkCu+C49B4wmrnljo6 LYGFMEATcAaKSmw7bOO3HRVu5aU5nU1pDZEHCEoXHLirL3KiwTdzzumSqKJK FGxfyB54wECVd/AU80LlEo/aZC/kL4erJHuHRg+RBa+7vFN9g1muWkcuxdbZ InjTgM2dEt24qSmFzGBOH8F9FLQXJletr/pOhdvYojfXcsOiXOkMkAwSd3by i2AyezppH/ztNtzvCfWCW5DrmaGrPuyoEDoast83uD2m1DdUfAkwVhImIbAI oeknO1MsVZl+bm3RT+JdKxIxjshwZ9a0Ii25WJG206xQFv4YxryCN0NGffa6 A/JHjP+iYSz9C0UYCIfsRW7dxP+WAuxFHsL6sOKHrHFBd9iSF/cncnJhJhOd t9rI2IjVHgn10j4M6QSN4B9lbfu2NGI4cxL/HhJ+tkUnRcpbaEUxgWRbZvYB Fyc7ipXRxf70OPyv0E6leLiF0jpxEutzNBGiR+iD2AarpJQVVw67izenFojy 4NYBR2VKATVmTI0cWnbUyKDu3ph6O9JlNmuqwfPC1C4vtA6yV7OVd5ajpRaU +oTKJm6uxLOAJejGHqubq8WQjYL97xClSPu239w5uIN1CMlLxEyArV2hUv0g rcFqNzQvqTAIHpPLMGvdKauSO5DLH8wZlBCLrU6wHTqoPYfs+ZYB562lsymz ZhjbPPF5J/6Ass7G6MCJ6666D63CxDi5aHdfrpzqlf7KChYPk8s65pwzK9Cy WppdLteaq/QtvYUDZZFYFZHftEVcamDvBSyyim8mp4ocrCWrHBSSRH4UjgPU N3yZXnO1bjYsEFRh1Xs+A8ILXbv7wz7nfBNNSYcCPO94LI0JZct1L3/HEFN4 daGyibN5GlQkeB7jYuEvXRGOuqmpDNQYROSRZodSI7YBzc0Pq9EhbuKsqNso mlVlZc2H00Waus+uohU7Yupz+0TuIN2+oDfIKvLekjXp6rYOaPKKrFqoid8d /x6oa1oM0OUHixmEYQfRvpcF2jROh5tTHUq+2OcX8bhqAR+ECAbucLbKk1Xr k7wiGFtfu5yXkvFWVDflRbpS8eVeccCyb1xF2Bq1F5Bx9i7uaQwdMlUfyIiz J/3mCZYJeSTTx7mbrZq+R61NzlcKRWOrR4WbmxPyrAc2dBjtBM+30AilZL5o 5VaqPI9iC1U3K2+ydqfTUah7r3GBYLzZS+DzxRLGWnr7z4RqHPnhK1u8flN+ qKqOLKTBKGcVZztKmpu7T9sGTEob9xHsM0/0jRsnsdqiPatIFS5SXBB2v9fB ggnNGellSspZb8O3ihckrlS5ZgrXqmvX6+QCs1bTdndltSoRZfskRYGc6QEx xy/2LDfHyjnVp/BTiV3dqAtO5PlCukjv0SXLWwnblBbTB1X2opYW/OKd3VvJ F8EyiJOI2iQKkrFoSTwbFG/nGAd98ot1w1zF59Il+UQnjYdqWJ4e5mYPk/2d NF9jRPgBTBrPgOUcbk9VClliOVFctkK3vLOZbBkfnKJjhIsysZebLBc6u3XO ZKVYZWqN6ycnchCiShEfOWhrcep7nGaKOmOdL+2/NxQVTpNqHbraPSYhp3PV qFhyxFj62S6sY2wtScNrgbJa/QyXTIy483xUnjfxgRKXXzew3JkoGQdQZhB/ Emtx4WndcgsdFfFX5dUJVmybryTrtgHZRSn7MBY9M5V69dkJ851YOFPmTSjZ cMjuuGLq2FmYtLAGFGbC05ah2Ak1RX7mAk4tRnzWqbVIbr9Ich4QCPSVnnaR ULI1U33jqHabsn55NDtQdVorxtSoXZzGmhlTxihKpzEJS8kGJS42WR/AUGOp Yr6gx1QZ8MJUga3fCHws0MM3WbxPnGSDCrrJGhvps+SZNWJlm0wOzPkAW6LY L06C9sdhi0mN6U2goKVTkxTfbd/k1apeZ9yWY5Ou5hxw+hIzpoFB5eq5tY6N CWx8JEktaYu+V0rK9cpcBSi4yTqAh/KK0uLVi5qx1S0pNrKNid57t90B9eHY VHLsvATvF3mRgyrNkbE1ZpzaVA2Ae5/ZIEV8pm60q4+dlngRYtvwayknhXez MR2qZplNhpK5t832xWBj8x5KmQvZRfAWm8c3u7isxd5qCcWDm/lE7nBHLT5n Yl4Qq7sS2ylbXBjelC2a5+UFt2Z7k1RDqZQ4yHfc9qLdleMCSJ6WuK1DWqd2 MIHxSc+mAb38tqxkXbDd6jlWBZtegGxAc9lmsugQ2o4Sgg5kH4ahYw0Hh2Zf DPsxkhDqU5WRpoNntmPB2UQGXcDM5ou2fdlFZpeHq5Cttuc0ZotwtgNZO1Hq cKzj/XkrgReDNq1WHeOvbO9invQ5+W9Pej9a+Il3IsOa9q4MZci6qg0DhY23 vzTUDwP5VRyZr8bVc7pqlbHazM20esUXqwi1t1M1HTB2QTSdodo7rbsmdu8c mtihOrzMgzCH6aywcxOdEvdxKhhweyJzSF5yCWkq5egdY2TBJl9k2qscGFAG kMrqyDRTs62AtTVQ/LcSNbN6+bTxncDCtgous3BUr8JuGrXrsdQSq8c7ZtVj 7JCdG8xheXQivBTJ3eTbvs2iObH8Zv1Ct1rmiSeKKDcrE/I3E0evTc4vsCQj Om6F8tlUrU8wivjJmax927h+ITc3avdWOBhPUTRi6QjXxdZGZISWZiqz99oC T90vd3sZ9diWvOryaecKN4xC6sl7P0SSPpHMk7S0BqoORo29nsq1rsbhs3O/ JwvYbkvoxlWF5ZGz1/68zIaRrkV6OtYLjM62ApQc6qnUTicVi5qq1ERenDsK /5GVArmMWPlS+ZaVKfmaRE2agL5j0DZJK1G9XN5jjKPHCuUKDJYs9ninvZYZ Nu7Ez7P0jEQPhb5VukXPBPmDmN/tKd4FjcBYDloA0YzDgG+OLkRPqUZ06QEh pwzF9AfIbluRXFm8CqvtKsXiOz2MdyJ9pOEbDeUm+iC+3pUWmzp045NDR55C 3UanNeLePoEewQ6TexqQJ4cLZeGWBsvms0Lvwl2MXCSkG0gKzZ3IYqhx5T4m UUrzg4u84CSsQB3Pi3LCfAqzg8pAcdbL/CUvX2uo003IlM4RTnglrtxJ6jQT MVEW/b2US9wKV2zmqlGnKFyEzgLf8XfslcQ2Z7NIFZZqXdqUcLO2+MJ8dJdl GrjKh8iuBJXKvlywlha/Rr6VCmBdpFoEyyN2KYGN1ZEUXr2Kuhz/LFGvGaVL 1m0sr7XqtlHBrN8U+oLgd+Ix9GFxCD2TL88Zw6pJK8LtstzWwszWS1cqWg9J OyMb1iugOIatR89JaFGWS2t/mrbRvmAxKKuc5Hq+Z0WhzqJXjFofxQpykYWo UoZIUUdnJ1JUKP+lckHkmSpUQbQ2tWl/epNCn1c8O0X+5aemUznSeKgqqlUj hU4N1gU+18Ula1Bmc6hrc3gFHV/BOkB+xZzM/hZ5fZwqfpfj30aOl+/MiknY zrZXDXyn1YYvRds63E9qhhP4CJE3clqikQhGP9sbytLRqnDWvNT41xh7fpOq OIgbQ7977DD1XT542yTfiFb4bKoav82U20t8JiaMZ6o5psO0mBdb2U7Lha9U ZS4FrFv1505TAzErqDa3h2pS0TjqoFa72lp3WhIJRwGzERsOvNnuNBf6qobl JpxK0hFdhu5OrYx1mz0HJN16q+P0jrfzmfut7xswTgEy9zuGI0Me8Q8LhUW4 BWbXvXpotm7dajw8LhdzNJNVJ1xIb+/AW9+PSZTeFcwXdULadi004m/rNKt6 3XLxJ9hSM/sdmWB7C7Z9cskp8HA2IcYuhFWdcGKrr7HEbZ92omhRYxntuGA/ DoJjI0DPu6v8LpLyyEfNzsmaLseNNtrNc5fqijpqEsCu06oTnorI4XrGYza1 zAnPm5qyK5BDlZx0/8CIamUdeMYhh1YuaGpf3lFPCgcTyQO175aw4DLipqao qSlmVi5iqsWLFC0X/47BvHxz3jLIwG3i5o4WtLx8NFxthnpRbLyWuxt8Z28e KCSd24eV3iLY/Youf6cgrwLUrYH7JUGl+tqA2oXk5SzPgNPYX6jxbnlpV5Pp XGXeNsUoy57RyfF74rsn0eC1s/rD6K7J6Xtc0neOjk+6Zb97bNol+c7RPYiF mLSyC9uL0KUUMGs5n8xn2Y4snZKmcZgFvQPu4YA7ZvrE0NTYyFRa29Fh4jCG K8rtpvNDTZg9OIbsXRByS7sF8RHrnyoDj06JhXrAiNmnAlS36fwcVBWLTYoI HVBiYnRaPEvcYumsOotrJEndPB+zT5HTEpyWUKM8ei/JRPKHaC83eihT1t1q 25HPp2YOp9fZc+LZvaRfbTy2CW/Ibt/NKXFnIjvJ007FeVOO/jHam/zRJ+Kt rUdc1o+QLZhb6LX1jOsKPDXa/KRW3aGp4yIl0azv2Xs1eXq03M0aHh+1y82h y3or7AqWNFAxXiW4Xr1hrOB/HzduxDbq2DotX0Pg+jjMNylCN8O7Fbm7gl3h fpOZ6MgQcrPYt2nmEg8XjWwz3QSl8mIFISsajomGxuCJTLbWwXTtAZpKg56M 7vm3FdGu+2JvA78Lxs6c8tWnw+/IdWnt4Xj3otR9BJdQRvgGdaPFwbSKaWG1 CSJ0+x4QnyMYS3d69/DucSnTyUWNuONL8vsGLes3WjK6FtRCPHIwU5oTLzdS GY7jlkvvz5czONMTgD+qHvhWgnQPOzJUwwYd14sfWUN1FKVL2Ms5aujk0GQK GYEGuelDJ6FmUXuAsBpkwOD0oySh8N70gUoii53BU/952M4mOWIV9fqguGiW VSVy0uWbWPdl+hAG+MtwQA9qxhbP0AhQph+5yOVN1sH+gkq6h7J4l8wyTPGm QMSRc2iVj8JVwkY9n9skAgfJgltbWqRTVTXdOY6UjirKw2oMCgYlAX6tFERI EtcRxVpZaZF3Rkqj57Vffl43UGOt5wzVS72DT5WruppKbbDfTSHQ+KmWHOqA zrGEDlPVEfR81V4TmWrd4M301XQobj4SpFBkjgHpsnag1XmG7IznMvOGL/CV k2wluNLEMY0S5Z2LKqEXA4f63+HqSt3puuEu1DPZWwDPIaWnu3hfcGxhguar DnfHKGQdJA0XKF6uDpTpKgO7TPFhqyqfg14qx5oYfBMGwDXYJrTj6qujJp2h QHxsBB9Lbh8b3ePGEnZCicC/FP7tAFoGiLCuGRF+k0RCl60o+nEQkmJspCRj C8uAwlwMJUBe469ZisedlOOqce9wc25nc0gvNm7k0WBLW6dVXYOyPjU3ohc6 tMPojym1aUqEYtqEbl4w8mxHjUG2e+Ex1gv7IHNITK6D2FOFlE3IGmx1zSfK yTnc/VJg2S4kfhlDUcionCC6k8qcgmLjyoUMhsJWU0INFMl8DM5nD9yHsYkr JV3RTDqZn4eFFR8Y2Wvi4AJUlvAyuNNQLLAWoV2MTY/uWgnfDuOufoTEBD7x HRtZnnXFQPE4jY2IiGy6EyoAtU0Y7lHraomVV5skIC/LFJZNnFHDBiHdZQZI YE8Y9qpqcKKrjNFi076/tpNshbPdaRJhEsu8O1GqA745NQyz7BqJ7qa8qlim m9Wn/80ru6ywT3LbcYjbnYW2Iq8+OVHmwKZrDpMOZlxYUncq5CXLjG7eydFd 2F5Kl1V0ozlMdoP7E8UZPNyBmZwpo+s30CLxEUER5WalsHJpd5vLombrXsDh beThGj2rZmChhXUqPVRysi5KQXFJgcvm806kbRWuc0HTYdy/cqXJUCbHdFj6 VCbF6waFQ8XRAanLYamlWC6w8D+YVlW4x5+3bTuNhaB6H8lz2Vxaqk4SO5bE 3pSnStuQmr94P5hLZWlJTaULafHuu1JA89BZVRd8xHjXmidlRZ0iXJDx23H+ 2Gnli7oa5+mkjRAug3qhuqhj0YTKhASF+mALA51Gjya80hwWFKBgsAnxcr1K jzHi4OoDYPVB3JDYP5hHyfCp6qC831RFq+aSmExSVDoOoNvaiJ9rt0An7k51 l7TYuaJTUG7YuqFDq/wPPYQ1K4XXnrUNh1jaF9XAzRGMZxlE8QrAFU+XxvEN mGx8GTwfqOisNfAUQ7U0Fe8em3YiV6NBDtqjbK9cmzTOupdpme86nI3bC7jw lNvSqm2bE2W19VXnX0q5c4hVTOcjMHtXlzv8WnbjIwUoVZ7QmiOj1gUK7n7p HjJlL00yV4kyBKrkiIp0Vr2LchzFIaPiNSfRgxDKV3JkD4Nynv7aT+NkjXZ6 LH04p0u5ntIt+TTaZWI5L3qW3y3sZAVfRPQ+SIpDJiUtG4igGFo1oSPVF0nd VuHiDHU6ReuvldifyORcN3o2jNVxCL8elNTfxn6YYWN0MwZqMgt1WrbFrJkP K5Nz5HbW9gBNVuPYfy/rMWeZeYRzvmpf53pg6rhAsze8lB8Iqg43ZgWzOj2T OquPYJcbZQoajwqdc1TeoVNbdWguVkjH0Newn7A5wTeW0aVLSyMLTQv7kfGK whNudnt4I8MyqQ22Ek18ilhGPwuUy/T4zioATF3LYXjd73wZ4mpyLuti9/8X +EREM8JGPjatbcOUyps2TMKkqct1Ii/1OGT07smxPUP21cbamSjZj1hlI4SN eL0h/GeIeI6wZZJfbI2ZTvWEtwUqcFv1yqKGwHj0awxEm7qCQ9RGRVv3FUGS LzM7jVbFEQ+72FPyqyKWD1X/XbjbEg3gPuvmlDWSOFyipjq5w9ifZht6FTLP MHz0LfN2xniabHpjdmEC2/GQ4mA9iPbXUNXDr+xcahwWGy+6ddZanGo8667F UaoSI32ZLdzKH0YZzlXc2pHHOTuHJs3TiSXapmA7DgrZB8oW2UPnXJJATl5e boyn+OkfbdhweHG8jXdTcxmM1lA0Htt16sK4jpfy82l6GW/ac+E5FS7tJXHc gm8JRKUpdUuq2UVcBdHmKQlLDx7BGY/8poFt0pvuShy2kLa61AULG+eZkY2q FziSm+lQje7nYbO7IK7ytXoo/LmLMxYlUYS/dAq9qluVCpx2miNdzqIXUbM7 1aqe9H0sTfKXzKyMcMvFFdn8ymJLGP5isJQgeuVCSgmORAOl6Z3WrfhpSbxM V9TWMOhoyGIUWEtTUewd5oVdu924wVEdhgfkuDJVyKjNBAtf+wSRUrOWCN9c 4zyx2p21PFFzQc/1uJA0oJUcGcpFQ5jyuR4TatnPuWqfEEpfK2gyMoxRDxCH YaUU26kvd6iyb21Ke9a7U4leDeVaRvtpuydfsQ4mcmUgGHvt5KyH85WtW3GN 230AJvkYHTm2yUg8bcE2u/a6rLOt5pWroc1unrmatRZo0NX2WsqFoZ0PpiRZ SB/NZQ6R5wt3E5ASX/ZJNmX+c9VNqpUTh5bYLLnZ7t13Bfg70XCdLUs3/bCr hzi5aWOvp2brF+jJevlOuEy+lc3/t8NHdPUSxH6e19kWd9ZLLwwhp1tlN5W1 xun0ip5S24JtrdSOX/KCqyG8YUG/pBmwW0wP45BZHvEoT2fsugpU5I7qa/1O Wz2mOQr5S8YjirmMcVrVrsRQh6s+seQpsWTsWscK5vn6yo8W2IeSUfeS+3vX MdDehZbdtr+V5wUX/pjhnXmQYHBrtfdsfn9gunGgS6GEtWf0dtCAutg0SQQq k550D/OVBx9IAb8tZFLpi+Bq2n2m2Qd46dcKQiqzzX5tF7W2aGKOuJuWDrhZ 9Y1icoJ2vtSLAEpnBcWhWt7v6rRIRTOLyyBoVSHQOELaMoHA3EJkEUllnCxx LrONAteVyrCBSRRT6iZYhp5St0eOAFEDbs6oHaFeVQgpy5kbuWsJ94DOklXO v+3lZRwry+ZD1Rm3yh60atl3fuYYWM7IU/zCrVCwHZ3LKaFohsrBuiX9Btif Epv2pFiewpaIAywRTKpGAJPqoFnNxiYLSb97zzQsOFNTQztG7R+V//9mx8aI 5pmKh8EbLOK6ZgdxbjVrsXv9nEozM8uoA3xOYjKXGZpNxzw3W1BPCu0m4YpV 2ey75gttRX818CKX/UGonhrQFbP5Tme5qjelamcoN2a2Fjsd5KrxJtTOo7Im 1yeovFAthXLAjuQFxBVeabx2Do76pgO240Bnqy933KK3M09URberEcnPUaUZ 1G+KL+D3iGUFekJudnEZxJAcN5c62EbcECSdrsH8MMbfMq8u5BxAU2HlxVUf iuPwQWK7XJGq2EZEhbWPq4wUK+9pbWuVOZDGUFWNeEfHO6J3KE3wQlQP9bjr grQPEVCVvIqmhQX2RdJH3LRbEpXU9JvWTMRvquPN6yo4l99VV1zUh+FhWPri irP639UZvot1BoNCYjpncrN5w4pJJFaRiEyZJFEoj7AmXop2Ipukntl5slWv +mALluToO89/uaobp9JG7KWaNHhXaXpXafquV5r02fi7etPF1JvIt8YF6Ew5 a2j4jondd42PjoDaJDQlevWj7mjmEiVhiFmq0NOF2UoWKhMeRC7WyU1NDyFv KozQd9UZzXdGjVHnJzDaF02FcV9YTE3mO7CwmM2/9YXFrO2iLSx2lN9dWJZc WCbvsoZAVnwvrCr2cTVXle+mFUTck7zpJcRl5y2MCLVliOnKmfbe7/C9QNVN EF8CXcj1gGk6pJ4fv8lrg0q8NIfTw7kXfpNLlbGF7rQ24uVwXIBQM0O4aYvb t9jy6jrO65SIq5dlsxpVq907knvYBJdl8m1f9Zbcs9uP/C/ekvcmRdY7Iq9W cJ4wnk+k8K29cIyZm83sr7CZKo269rOuJV31zt+wmmVT4WUtZN3iMtsdQjpu sifzpQzhRcZDeeA69DYoQ1vlheezktzrFkB3hEVP2NezM3pLP8mjjzgrOuUP JlKCTw5guqJjBuwemexBOzN4npB3e4Ukpxda0Ir5xEcFOhHNquQHOfHUl1C/ 7XQhYHf3defoxAhw29Tk6PDY9rHhFtMgFui1aQtkuhO4Kl+cEu4sktJMo+rR ybSjZzi2UNpaoOLSHUZSi2lyJ8G9VrUkZmVwJywrmsbXdkg7I2WqqjbzFexG g2gwXR2dFLYaKrY3KxcGNcZGOmzHR5KmnZYKHu4WN1yRHo39bN/dW2QKaxPY i9IoHuIMWCFrY9VnN3sGaUTvIBnR9YNO0jo7YNquSjMizsMWRFBFLcMhvTgY 6jiXtptJsnmRzL1lwOUU0f76wqzakRdjcplmxkwvc6nCXuv55na+qMfKgbC5 5jnPHVUttc8eDeOiGpZOtaycZDecQ16zKzWY0zTOv0DOfLM9NU2oqnx4yFeX jF51lInvmiPs7/hp9QWcwjLRhKJFojb57rnsu+eyVdvni3rw+V2yRVVWwNVB +PCplYsvavMFhdo+oJWx2Jxq3xboCvnt33E6zJY7+QFHh7ldxA+2/aPII/aL TGV+97GxcDDVX526P10uHIRqzFPJjelcsnBQ/xT2944M4jFKXATjwyiV6zhM ZfvE7qmdQyO77+owg1e274oj6TqqMSgRYjexPZZkjYL5iSwytSKzTragoz6h R8DquEPibbT+pUJh0J0eNjFgaQIgMTvIgLx67ZBBRjcFTccMdjLQW7jUpi2F g3E5DLUIY7eltpfqtNoOuQb+EBeRCutSwRVr+QzJwBd9vriOBCmJzj6UnJ24 SZnK1cxdAmlyMFXoNwZJtCL3Ow8vPXx7Kjkz2lciuz9fPFyemxfFiR3ReFrw oSSTHRd9QswvPG3RGYjOVE9VuWUHuirE7EWUUoZHUaeckq9cS+ZJGj1pFe5L J4amuix9Pl4SO1iUVLy6i+0oCDnhpJ3dzsh3XlUhSKEgBZKTLrVEM+hyL7OA CsSB9OG3X+jZPKo63amKIZKnVOJrf83TNhzR7WPjoyC/CPPZlHEaJdZ85Wyb U8V6bwsBSqcl83av3MtH93Q54BLHYvpsR/yGeRwXaUZU0O0Z1nR5ZB3hIHld lo9Y1XI8o1/jb6bn+MVEKlMpATkhcc/QyNjeqfjw+NjoxPSUil/dLmlDoa0L Nl1P1VdsEwKmXZDTNRq3xKZUTqWLAgngZgwdjdGIqOab6eSFfEUwL9lcoxaK +f1ioRMNV4Ust01JJpoRnsE4UZolH5vVPZH6BzfQacnedyyzdUBSbWQ9Ef25 3KTcudjedxrPZErJRK7G4NDYCL6SKia1H1qqTtldk2FEHbZdjMxXdZzo7oEa /3c2mQX5YilOsCnIEu1AFfEkt7rEvjRk09ikha2j4zoRDNOaIIdLyUqRBrps gbQhl1BpfppPjumS6Ngih9YoXFfJ5lSIe7nOpZdujpYkrW2z1Omn2uFSRPqu LCr85zMleoNN7kSgaYdnX27k7fCOrXcnYq9kEJ/ZZam50aKexwrvsrT3o9c3 ZT6ylZIf3QqsdONn7PckWat42y2z3JupTdabD30jlwM1mxW+t7qWrMKzahNa A+HlOX/FY/TOaQ76bLw6/gfZS8LAD8kTPSMoqtzxpdIl8uGwPXMxNjPmyT3u IRHi9VwsKmJ1dtyPibAeH+RZL+pAR3POtaeC0r6Nnrl2Woaja7EqxfEgM45e IHTT/Y6y5OHBeD93kfeiwiOPfZhGMqVCNnGYHZuC8DtEshB2nkVW0jLk73h/ MTF/EXabdJrW3tGyzHPB6oV+L5YkoXivtSmBsruMKod1v3XvpnnxzI/cyfGJ 3f2YrQRf20T4Qfh1yKLElJWaESWVYJU6QYfehVwQAqKllTdBG03YcByC7YOQ qReXEVj8O1lBuM1KW/Ap72J2zjNWfIUq6Dod37ImLPQEgSwzX3j7WcS2VlVd Wmt1G36K2eymaSOC8TL9oYA1pia7EgV2fPcOrbxSS1pzVeUTb1JhHXbqq7OC wOhd5y3oqtxZQJSGhxYDAwPqBSKwKRTpCkVKyMrQ+aTIfAuX7qCzY1GSNTYq +A4vM+K6N57JZao2qNCbDKiBD8LW0+1SuI/zN7uER7M2WXfhY2EKJkZObsQJ pNyOdlLBZrpknc9XcvSIhuiDoaxSakrI0MH4iYvklcNdyn+wyqs9uVgVHoyE GWPzNLvEF3eY0r0xLUwqHMimUdUJUUhu0jJEqETxMJbLVeZnoBuAbCpxuNQl KXAwUczh7ZGj94kkerLMplP7DRLYo3Rxp7AnxfR8IpOTLmOE7zzT324uX0av KFiJKAVY2H05UY0XYQ+vWUQsKJY1MjY8LbyCwL6dA1XZ0oBquEILL4Via0Ez PCXmjf17m8sgyBlv1uo27114z7GHrPE81LUgogfqKylTG1U1U6PDuydGpuKT o3viI0P3OAJBL9OluwRvrLQ/TlZaWWeqS11gT945gWOPs+iUOVNpHaTT8JZG E2TmsJYnedrHAYTLJBbQnKNNDQyt+GIYkK0kXmRHtRJs9zRnyZMjXaY6JB58 c4uIVyimF4wrALkslQuOxAfzOZCWDxbUNDQ95q7ATKfmplQ5NEOfw4cy4ojA IAp5duczX9GFKk972AfLFQfj/EcWXmkEL86/Egd5zoAdjI9BcRYWjL2qutrb h8q0It+ARmhTxNLcwdlcZuhqnbXOY+Bu2EfLfar+2kHChl4p1PZs5n7El8vj VjhfPEw7KEOZbrap0Ype0JExWBiEoqBO6c3TGk0xUrDaTBnvoK9twOzjVZUT LVVEJrKpGDGfWqlMyqGV9NjkqERZUziErGUf51oMagwmWbkaF67ZDAbu0M4+ ga1UXTbmknNJ3+RXxbulWvanyziX87OgeaAWWei0boE5TSSs7k+50FVewOXA utUmWd5JSa8dSTqlPHrLKokzrLQZUqJkf2zCpaWatYcw77MmbEqYNZMGCZQ2 6QU1JuSSiHof+7ehSxCKO3EwA+p2QGzHxVsWMqbYFKQkjNpWKV6EQxPTsyYA OJwdjiUA02y3vSsQ6kbxuFAi5YWFTgHtrazEv5vqUzMusskvil+XYkZsQbPf FsvW0yWv5bCkU5OpHbC5RjugfDvqkAJPU0PMQc6t6uh3ZNo8UFtvsuVE4ooq Ff2NK1t7vg7bWb1jMi7kM6mWEujaswk8KwfJLjfmdP2U2a8Pz+hUpABbhC1O uhzA/Y/63mlNje24YwzEvjF87qKfxDtMH2gnh63fnOqwLQJ4Isob1tlspTQn i7MIwrUh6OjHXKVQsxeG76J37f++++z/ujYXEykUx11Jz8X6FwgGAt2RiCcQ CIRDIfobCIrfCPVEo92eQHcoGgkHQpGeKKQHg6GegCfgeQf+VfCkFpp8y53E f5GAh/vk+R75d1NmNofHxlmYtC34Lj2T1HGB6fFE2/qd9Paiz9pcKRU3o/l9 dnNyoVTM58uUArKhpLmocwHjBmOo4O7NwdDmYNgKdveFw32BoLVwoJgpzeUS uIuz1repk1sKJLnRWj+e309h0VVF6zFZBSfGal3rVRVjdnLEnqZ3DvhCBMM8 FTF2JJ4IgcTkRQO1BTSkg1TYb25K5EoZa1MhnUrgkY3QCMyGg0bDQSsQ6Iv2 9IV77A2zfgwVi2Kils3UO/wuIgrQcaj+SRZ21pA9pPsIVjOWE+9yp0ScSVGb KjieWcBegHCwRvF1BEj6UrrUCaWSXSpTd28oYN2Rh14PpzGTNZkoHjiYOKwy TAKtStBlDA0zPAQJvZFod7fZznC+cLiY2T9Xxv6HlmtWV5wuzmdKRDwRl0dE 2+q05vMw4PAX9bBUpiR3AXRJUsrPlg/iAwyx1dRoFoRCKQJtZcpzGC5hNk1B FfDNBwzg/iL0Ip3qNA7b5yj0GUbS41qSqitYT0FjiCduSai9UMCwTGTHlMXc GCuUXDVXCsgqeAoh60rlk5V5vOkWYXXoKANvjEHoLkUicsnIxjyqLlBBEqmF NDRQ4iOPQmUmm0liaGDAssynhRQElQmGWItIbppG4oZJ0Ue974D2sUrVXUF7 7jPgsj+zgCFPNTK6u/ZuCpIiFemY0xxA0sZBRTeGTJN3OZpgHLuVMTZshQ+k MWYgTl6KaFfml0CJGeizqoOu4iqZcmImk0Uq5mfdGUwyFuAwVrYMVlFc1Iax 8Eptiqqg5JFRAZTPzBeyGcgCFSLzSaMqPDIypGgpmSxlUvfebw20tA2239Sh pFtzsCu6stmFXaf46plcMltJpZtvKx0ubcZ9calrbosjGW1z02V7ei5dxmdl mzM5TDcLlFOZvD1vJQdjmqoqn5qxJxUOpux1tYk7n665NkgUFovWrqG7J++a GNrVHLMlDU1NNTcHu1ta2HoLhPMCG3PfGwn04n2TsutSZt6OLxulstrfQsom 9BrvrvirsEtweZ7P3/NZGgSHu2cgMe0H2hPF/UmYJcX9C4Y+i4n9dks2zHHv /ayrIxYJw8+R8Anr/qqTltC38OBTfoKVAW9NNpYWCuaz0tJCkozE+2s8PhXY 40Zc2iFzWi59EOkSrCKMM0eodg78DENWO8N8KorfHSZ8G2FMxLDVNLKTycIn sDLIk70moqp+r9zVFH90dVaV0aaCaG9MRt3ilkPyHz6ORDYI3K+23cgpbBdm 7tfkTb3eB292RESn+ugQSI6NrD0oaodxZhtiGPmZw8JGiWcebODaKqlCm9qb U2bj2YNklqoNdvUucSKP5yVzMsQ1XmxuFmZTlltr4hxNnRnK7kk2BJRBw5hD wz4eqw7sCezK7E8ZJC0M2zOOVmq/SxNdMbyNthsc4TC1Y3Q3iSLycsb9oKGa DupemS570CzMstV3X24JAiAFSCyhWRZJZaud34bAZn338B3xkR17hnZ1WgE9 ZCL/bU7M2nGj3YFrKloOtLeJ6pZpe5lHL0oGrezNC2V/809exiZwKxwfmriH RlvPVYxzGghFsWgqb3/2pfLceqsy9nN/HqP5ShcyGFEG156hKztB5E5Fg6Wf t9BgiBgmBtK3Wd0R2OWpgTM+bRngb7bO8M2/aFuNm3NcEcGlR1WyaNswuuMh dxjqlQRUQWKEZ6qUIc75laH1zxaSwcXmjpfITkvJvbbdUEq21tfWoTq/kfPq iIn2+1fsRcBxo6RxwTPwZXCRy5KJzAQUc0VGZn4bsKGHREvjFDJx2pPeRLcV tXCT7xlcOlZVb4eLN3k1+GYDJXT1jjKKjFyXk0jKr0JCd1N4dlI+PpSHhSV9 NCzpsZn8OztcMNCNCyjKqfx8XCz0wP70d4m3gG/af6Kb4wJlYFu0JtRKaz4L 3Ts1uicO+ipdMKmKq0xqjYmlnqBi1i1K4a16vypqkp+1ZDLfnYoXkiGTGHSo J5vrtNQrUfMwj9UXl0NLVaHouMk01X2Xo9dvptt0OLOu0ZyO7WKvszbZJLO7 kw0aWYJq8FUTTS5YrGmSDa8zUIxBQ5lLTzaDjlWeqTA00chKjatZ8LlbLQs9 15jaZm6JnchUbV69Uttq8TaZW1rOsFqp2Np3BfT/bhkwWY6jDIROtDANzVcS dsccQuYjjLvDm4LM/YZ1nYNjazKbue5UM+7u8ZF3gHnNsfsO8K5ajb/LWVdx 2NvIt98LXOrytj/r9rb/u/glenz5V+hyQ8d94QfmUp++WM/LsakEc7Gz4/1m IFA8R6KHw9UoGUdMKh6wQEZWaeTocGQJdJrI3kLIaFNHbn5L9X06psexXrwa rSY/t2KjdacNU67DodAFjJ2NcwOBpYUCWL3h0KVBE7Rhhxtb0DPYtYB+qMOc a5ouYFZ1CibOXWQ5x+GYVhQt+1GLu0s0dV6zjF8xdWZYyB6OL+GGk/MZ71JX 4q2zhuar+yJR1Gca5tTXXKHyrbNrpjUU+j3pZDqzkE6pYNrCrwoLFGLqlZ04 YFRdEVVRPOjDWkzhKIW3Sb8VaRwXrJ6vePWpemlm95qolr5ankeMIV7Se6ce HBkc0U4EWz3OHi21G2PLX3SZ6DqKTH/XUXy4xYiY4x4uZ2j4jhoNK+XFzVGv 2YaLJbHBemLbN5LOZeylHra9LjKK6Ic7cm/iNCJ0PsVx3/fZBYY8/ZWn6Vgm lzdOYpGpMBFmFz/HEEYqbuu9Hrp+h1imWnG1SLDJut09u2TpW0RGvTjhUqBy c0cMiw5h8sN3aO4fkKLfffv/rs1kkXcRrT+Ws/8Id3eHAe4OB3qCkUA00o32 H4Ged+0/vqfsP5iLyPojiteZPZsD4c2BKBpLREJ9wcjKrD90NU7bj6jlWqvN BCPYhebWIIFHJsam5EU2fgh1WbugD+JZo3SfVRJBKTMA5tDf5EK62vAjIlsN bYbGQoG+ULQPmre1KpospQuJIu7FyF0NBa/HxihkfZdF7hhHRrcP7R2fZnt5 fnkkDGKxENZ1MIFY6TDOVAeo2fOZ0iyGN0dVMpnWn6h66yB6vkygG15++5Sh G3179R3VvQvL3gWBrFawpy8c64v0OuxpxPEgWvEKei7t95G8copHYMU8Niuf T9Ww4wkBVUN9gZ6+QMBpTgPrPTkyYc2gRE/UaBkNhmKIUCjaTQ/Jksn8fJ7c GGQTxf2Ylaz80FLgIFaFBvQHhaWPfHQizOsAVXlv/a7Nz7s2P+/a/Lxr83MR bH54TWsGkRJ6h0x+KDtoyW/eEKi20Y9OqG4hiThy5eSNYGTbLrOh1My8+Kq8 ikEGIqCrJVH6EJAkZzlNfjgZ9wXauUS/Pbd+g96vRgdPS2ApTGdTpOuDYswf sCYcJVjBS2nnB7z8j+O5Gt0i4zZSWjNtH5sYie/aPTJKt0bNAZcPe0Ynx+9p Drp8mbpjbLI55PJh+/jeqZ3N4ZalHDpcxOc8qFbEsc/O1zzKvVWOYkcr9UMq MpQgnV2hSzNYvstp7c4MzzNhVro92yyJ0Pb4UBFljNg3k3cEKincksNk1m2S GmB61+qy3u53PIoQ0pGjCAJO+PLLAvGjlmtH8ynZRqOw22ejOmMLnC7zo2sZ 8g/VGvUbbzG3Ces4xysK7eKs5vcW7XR9I7ouK5ZQzudwTdJLGypXsC6i9lQU yjLFBlfF9qdz6aK8f2B9j0viumHEEM/yE9Iu5RBK3jroXnSq0wPRUdh76I/G M1Gmg+MYX5Up5wW+Kl9/i/nuRFqTPIxrkHZisU07sdhEfhzUtJvcsxv9UcDf 0e1jd3caOFHN4omLeBzebpcVss5ajKO8Y2A7NsdDcuQftvQ/h0twh0hgrfMi +r5JF1ciFkj1t21tLq5IoPaqpcHbLQxU978jwkC+H7Oz19KIKOZCs4api++o 18RtGR4xVw3WWSH14vJJjVVD5BoTdoYo4eLqMABNL0kTRjUXlfiAkH4pEIpC GErkZIES7CWSc9LxprLp7LKGHecMnDNd4ki1RcO/J61x8vvbzcdCkLByc2Hc JEkWF2cJfEX2dnO7UZ2tQdNRERK2tqeiGq4+DaNfxNMw8oXtadrpckGgPIur ovOTQJc/GVouxX6ozAsW71c/0Skk8FCq30XnpfNY4V5xWDlRFFcHmVwBo6Q8 mC7m5TUQViwYkTZaZXy7xKspXogIQyy7SipMlckSSg6OXEMxdZ2biRxZ0VEZ +Ar/99BDlvp5X3mD6U9fPbe3h65QMWNxqTVd4DPhjRshbaCIzcrvt1nBlbgp NYmjLKZt9Km+l6jl58Lwibm7kDYmMHkJ10rLinxe2aeKg0vIJd7MvHCzwzfO tsN+8phmsAkbOQuud/GataSb1yqmu1A3WiCJU2/FjRZNQDWZarsAMaZVTTcM dkLSROtK2dmbE/GssJrNLDUbkYxpCohCBTQLygyyiqpLGFurbXyi29Zv/+po XmVThKqNh56ErqiIuQX8wxf8Hf1ubsON+x7B05O0sdXeWoVrL8XWoje6QRaW toR77fjcrya/4WyG98/iMbIx7G63WQ7HrTihBZbCmMFhzuzCe7Y5XcXQpmNW V2+tuODMFtPoQddAVMVtMim8hC+DKnGa24ChSGqLVxaLpi8Es7Aj89uCo2qy mhuEuuTgBtfRNOan22i6S+i3MKBLd11/NfG6UMLY8lXJ3Sq/1DXdUQvRvBJn 1PN8wW9fph3huwxP4uKmSPkSpfiLemeFBDPCbHHE82KObpkltpq2aDtBYkS8 Z+A3CKw+cYb7jWXf7QtqAB3w0fDlYG9OybpOq0dGQ7CHf2JT+BUUQ6qo6PO3 MDo9oNQ1Nz8saxMah2tOibgtvwqRtoRYbNZB3wycVyLgJCIXKtyam91mQnNz TcGGnxxijQhQY9ZQTczrzK0i0b5yaDJVqZN0kKk9c7gofE5n66w7GilCfbQx Q43hsMmlZYdDMpGbkJIj4qQj0/ytDM1SxK4loC5wIOiPoLGDbNZdado3ptA/ kKZMdd1MO2MThku9ub+RWYyNmAzp5chi+rGxc4LpkV61XWPHs7egXM4n0UoO /UHJGI9qATL1wZX4g1uqg8v3r5YPJMe4PKzP/ieH9kyNGof/xum/8Wn0fXuH xo3jf+MTdci4ADA+jU3Ax7ERvAO4yCd6NIGqHI9jonCeypO3nLfSh8rFRFKc Dbuew1wE14vqDqbFZbLTyMUNh+Qudqe2cwZdQJ+wy70/lcVuwcJkiyMCHTSS yKvn0PQ0Gq6WhY5sJJFrUExX7lDfhAdVN0/q9rRsJnfAjEwC+IWyedAOzEfS VW+npUuxeWtjeb6GR2cW+g7WNk8NmB9MTddM0spujQAcrmuCM6lTHTKIRDpG cITXcIS1RMypkHTBZO9Cn9CutCN99QIMxbG6EGQG6JQahI5vSZ+k91c9xFxA uWEkhcrgCOWJ0Sa87aJeiflq6pP0cPM75cgiuzf6AEZ7Rb9ehkZoUnagav2t bpRYTUl82wjUXo9qdKkm2tSIRPtO4b3WMRhi5pljoQbjzfvJpAFy9ZVp684K fGbKA1DL4TzTYXmpaSHvu0wnmeQRdIsuXO0cU+TgoNxLBAp2BP+lkOxotkHy Gq/HxY0ccC0aHKGVFttH6MYyJV1eWZKA5N87Ze3Jz6DtSMnYbAhUq8MRS5Sr vih7P1WYXXuK/PhDDLGc0zqTfXhqRaw1nZHa3YJ2shjXI6QYs6pC7cvNiM5T SmX245Bu5HqMvYndH2einM9I1u2o2qcs4UhaVkx8qvZmbl6klUJL2iVHxVhK lbfvkOz4Gu6jbWWWoI92aic34kZ95rKzcpqjU1dVo5vXfflpHp/Kov2pw8e+ ykHXdOy1UouQ8rw+hJ0e2zU6vnt4aLxGD6RzCKyBmrLaRXF5OqAqMLTuGnXM HxB4cAVSGXarwUYcM+QuiSPbUC8pcZd3ZiuXBa0O1fRkbBeKthKW0EyWXBRQ UYGcNsWLP7E+gTkY21o6vmRcrkyXsPGrUVE1arXUmlpRjpfPX9u150W9YBVL Y1UgVBTzCQ7yjnn0NadYOrssawgmurQbFokqGGpZXYiK0hdNjydvoXp9F9YY nValULZr8NrKRSVtrNCJ9Aftt3nq4Jo/O+6u2mqfvFaf27ZVHdvaf+f0xZc0 I8GG7ZdcphWK6Ye6Ci23GzJLdEO/zdaz3LhLceJtOfAsL9sPcfinUgbsGTo3 uJrV2HqrvBdUddbRA8P168W2TKGIAVU7WXHSUJIxORwBGbvQFruQTSR5s5sv wiqfS2Q52gkdvaoTV6GwSZffaI2Q5ICl6fmSsK9V5goyhzjFYhP9uQwoNXhi g7a2aEV6MYJBKUrI+3wzXAHBhNNKjFSq4hdUfaSqzIv5fDYl7uVXfE8v0oIq seb1/IXGGxJGL/3VxYJLl9u5e3xEPTrflV9IO26CySTOghEt5IsYLAZVBO28 XRxcieeqEktuduWXJuoalmu6ufRWLl83Gxfa6PdH2EuRENGvTHR/tA8y0lVp RJ13zsG3Elv0TV8yB5d72Ka6ie87dDdXcIN+8G3tzMFiprziG3O3vtQw5Vja fgLdQcj9Ho4ze0cAWnRa+RyIoSK+n02ouMH8TNSIGL/Cyy5iibd+1/WOXVYp NdY8O4chAjJVhMOnTA6GbV5NY+cZgGAbGvH7ym36BsCmSBihVpbTZKuiG8oG dB28o7PHcFGKstog1miGlfCa/YD/5wZIQW62LDNQjOVs0aZoV9d2X+4+ckXn Qg+x/r01eoj1ykEP9ob+dtFDdcFJEtGBAcvZ6LIkMQhSNZvR8H+ZnROHt5Sz wn6Z47h9qzHXsJUOl5s5Q2k0T26rb+aWxMGlW/RsYckLwpo1Vl8hCSHT73ap 9E5uuWjcC0UOS2ePbQIolMSTbNILWBcmtzTscRzPK/jYHZXJDJl7XpStFcdz zOfKcyV6d4RyuO32BHns3J6ewT+7EkX8M1Qoil+H8c/tFVylMG8lS18r+/HP VLqAf3YnUd61TeQX8M9IOtn2cD9rmW5nLKZSKZJ5lXPcPXzQoRFGYvfbn/kb zkCpT+6OfYIhF28+NuMCJkjmfnkA2GmFO2yGVOX5TVvK83HICPVmxOEIuqQM O82oFEIjCY50JYtiaBR58HcLXxdF7leL8kT+IJU7jO8MzYKU4CzYc38HRsDo DQSQtd+J999dmyvlTPaiPv9fLv5DONhN8R+6A4FoKBCI0Pv/aHfk3ff/30vv /4mLHMEfzMfdK3v+L2tZ/+6L8XdfjL/7YvzdF+P/MV+Mkxh8B0NEfDe8F3d5 /30RVXvDtZxTtRcBCNFFktLuyfe7ONeDQTU81GfwPVgZJ4qMA6tfnemjXqPE RYjbTKt1i81XHjtzNF33yYgJRtBBzE8xAeY46qDmyDlRkzqYFXXkVNwFPI3S LvfZj6ThQnKOIxVgEzOHxYWwOi+6RRat8v3ILhI7OqXzSuVxda7g8hhD1BKC wpBBYNxpGViYx6L83cW0b66wactcnD9e3A2lvh+vxXQ5B3cR55F5l+QxodAk 6ItgN7GoFGsx5dvPcsQNLeZlPyJj2wAKT5ErYzbeB4ZD99e0a2Mu2J/Pp+xt unCFHFezCsrrcIgnziDtnCqmj8hths9Q2C8VOFkHlqhmMnQXCVNko8iD9Qi2 I169+Hyn6VZ1fex4eWhnPximXCpRTF1khrKNqyG6ONCOElzk8iNfjifzlZyK 80LGOTKJAknwL+l23sggk+Q9KrVo3pSqBMvtXaSQd/C1S93iqtbYSK6qserT unXaoEgMv7MqKBh1f1Vp1M7t0XtCo80tVth5lOes13FEhzg43yTpIkCL8AqC ulZ5mKw2pn74Ii/oci1YqWh15W25drN9hFTxlpTIb/98MBc2eV5qW9NdjJ2r l3mKW4WelGcOl9P3Ru63hTUS2Q/hJ5o1zuO1iMvpGuXGkzIxU7dswRIbrZha bGUG8fcWHWrnkDjr2b6932A6gVfmflnAiB1Ufddb6ZL/39ZplA7fb/4K3S/u 3HRK0PY9cP/FD4fNLz+quRC30dJ1H5qRijf/M2i8Iy0GHJb10kjnopjX6ycq hhF9tfH5Bx3m5+L+Q4tQsgdbyQsNwzpL3qK4mLdpgzp81atyXXzpIXWFt6iY iSHDRzlK+X/nllGhl5l6D+wKSg77KpFkP4a/t4arhIwE1IJrlzL8sSKml1DT 5KZAzf3+FUoXYTsE2OhX0saKLX31O2yr5EIuekUrd5dYyY0UXtxFfdC4eTFm LMZMrFr2+qZ6p6/vVMAJLq5eK8gl+mHbm25aogesCN5Zc/+M+wjXph6u3XtJ eXWRANSzPyKXGW6zAtSk/L3FCkWjK2pWd8vcdOlV4LbbrJj1kBpuzQxOFVht zN6Zm413/63s/mchXcQTuO9Y/O9AdygQRP/PwR689+kJcvzv0Lv3P98l9z9j qT5LcYm+4iFfzKGYFYz1RSJ9gd6VXfGYFbnf8lTV6+JtmTzll/PiiM7CQ1fU q9AzMdcvLTJxyab8gAkuugk8tJ8vsLtlfBnj5qD4Ld3kvHuV8+5VzrtXOe9e 5dBVjhJ3zSje3tRtjnQAWfNSp+o2ZgU+dEFIWej37nC+QlQm8gij0JIwHjXp VxB714p8uc+kk7I2V5mfSRf76YkuPhJnjhrMqv51gdBFhRSao5IH0XIWFh1s GGNx7KepxPWV6P4d3ykKl3iH0VKzIrz1bVZP8Jub7xzdg74vm5vbQGJ3W71R cmTf3aZziKeSIlcbiXW5ulzc2yXuiHMvOZIpFbIJGZyHVxtBPO2pkCf22745 lINF4Vxa3DxiCH8Y9+XaxPamzWDPYnoWBC8+IeJq+iwzJy686dwcvjFKuecY pkWX98m46vahISqgYXevwYPVaRkjZyljqjmKc0CxDrLCitlY1mfTCdhniNeu 5EgCVBtLMEKqfWQbReWsNuNG1xRt6nmerczE7qmdQyO776pRUH6uUdrllW6N ilxyLlGnw+/rEnU6ci5R59Dw8O69E9PoHXhFNbvmN+qvNVwgwNANJzWdEYI8 afBFBYWfY+Di8US2MJeogQx/rdG1eDxfmo3Ha5alrzXKJjKHapSDLzXKzJRS mRqF8FONUqVKrkYh+FKrzOFStFYh+FSjVCWXOYTivEZJ+blG6V3xvRNjd9co Kz4aJd1yyehEtuBQ7+r/31H9v2uz0BVSXfl3Yv+P/+z7/1AwEuiGNMgQCcFm JEr7/1CwO/rO7v/RnPE/4P7/Q6Pj2+u8dTqhzuOl/1W/rxJ/I/S/7Z5L4VtX aQ42AqBue7rKoF96uopoTJnwdIn/nSmVIAt9xv+FrAAcnucEUa6YziZkYQRF SQJFSZiluBPBRj/91edPvr5hceQfNizuvBx+n/Yv7jzu3ec7A79Pewc9p9ss TBs56v3Q+WOtnqbTkBfznYR0/Hus1ao7zfCV+HvNosft91HIJ38PMhEgzeuS Vu+S5nNJa3BJa3RJa3JJu8wlbY0z7QpMX7PP40w/BfQ48hnLs+aIx4e/W494 jnM60Az+tgx6Pr7RuuZjffuugXybvJzPKL8T6XYG8h71DracbgG6bz7xW046 41gchbHg3ztPXXbit455t/7cJzbug7oXse6rrzniydfROHiaPrZxn6LnKa+n +Qd+22S2i/fPSQ/ZT8lPZ4CPzrjwkbN/QMfBure3vs6l6nsJ8jvH+Hir9Xcv eU+qPCto4wqJG84J+H2Z2Qb8XiW/y7kCaY2OPCQlWk+c/4CZjjgD7zQI/tx6 XqYv970m3244cfKU/8RJpsUldTxHZf6rKf9ZzxmvOS90vVj29Bqr5XTPiedx 7mJ/gF62+XKqbZ8YJ68F+O3zXHXE02zi5FbvUf+JlwG3F6D+F6BOHINWo01M 854OCRho7MO/p68+8fzpkOUlumJ5r6PchhPnIN857OtKcDgF9X1io9X68dBi 69FWT/Og57KjmA7zuPVjoX2tx7xWHacfpPz/Dmlg4gz8cb1NZm048RTU9RTX 9WZ4h8r6FL9apuy1oP6nIc/TkMe7VsvVq/W8h++E22CT15hTjvQGbutpPX9P PK3n74mnYY79tUmHY63tdUYfn4SyTyIOXqYX/kbaG/140o1ekP9WTLvZpNn6 RScfXDDdzPI+7jfxmHefTS4egzIsW5qXywO89iLyGvBMO/I089sRtzYbj3iu NNN+PrSvAcq0wrzwHvefeB3XL6BtK6xJ3k/C72PeI6uwfy9Bf463nL3xkzA/ PrHxZMtp74dix9cMtpxp2xpbqv5fEPVf7qj/8gupX/TLsnBewnfPYwavQb/X wxiuP/KZreeBx1c7+usz1vSfY95M16DL7WYayIgGuQYfI7w9zTgGZ2AMjrUs 3gi41H1845HmM96tsaMtgy0su3u5jVbA6zWs6zEYm0/5T7yGPC3lN/z1fdLe BzWvgSfey3z+Aoy3b9Bz6d34+wnAhWTEGssLOIFcs1iuXfp+/G7IujXIg8eB B1+COo02nrlC8Pszpw0+amWaGXKlyYWG9Zh2EvD8HqHZqmVodsk7STOQUdch /ANfOtv0A+dQRz/Rijr6Yqvn2jc2LI7/84bFybM9J74ONIjJNli+PcSy+03I 58VxwP9VwPHV6v5f8gfmWgj5zqJOBX8POWTgWu7nIfhWhjEti/IaR6z/JdB3 Ye6eR/jlFqvuk6us89ciPldYnpf9J84asvYh1L9OtzF89Ymvw3rnE+knXj3T sq/uzEarUf8GvXCj5Qf4IdDRms5A2jHvos+xlkKatfY08cPiJOjTr4EeNwl0 fwT++zCm4RgZa9A/yLFDHYDKAf7HWqzzAL9SI/1lSH8Z6qlby2vSSWgDxvVv uK6Xod1vc75XIN91MGYb68Q6TjSDPpwDvH0G3mUYh4TQ+9b9yhrmYW7fJ/pD 9X5L1Et9+xb2bZk6x5l3X1lJXYivwe9n4PcZ1icvdVkT/eZae9ooC3T9mKQF lP8GzMlWl/LNzvIwpi/DvH7dqOdDgpfXrXfMhSNvfi6cOAJtnXH+Brlkwb7D Mn6vh9+4nhw52bbOwjSQJ+tZTrVIHR3k3ijD9cAP2xjvdbJuoHlAjg/2z9Hu yygXT260AgYdjhh5HmH6N8oyMC6PtGpd6MOY/zTgx98+DN9CzGuP1uCLRwc9 q3+XZeQR0Gc738a2r6g1ztD3M0Y7QN/F9SYtnPsl5FdJH5TvICsmQdf7NqW1 YRrNudValpx4BPSf9tcBlnUYMvaoPAdB2Xa6xfIfbdl3HvrnA/wsHj/fWuZp nNsSb6hrPaf5vaw3Q9qNLv1skvtR3Eca/Wmskd5aI72lRrrPpM/TrZanup/P H5L9PGpfH18F+XdW4gvz57WTQg685jjreJTp+Rrk6zzymQ+hHrXJSAuA7G1A eXzkM57ma454bjHXPsi7xtDdX4M5FBF7eVy/97Ub4/2aU+9CnDRNaOxl+chS 5SmvF/KI8u9XuOIa5sW6Bz2IK+DWwTz/GtIW1pdG0EPOn2mxGo/CX9xjrGFe WPQ/f1aUH1Q0PE7rG/FO4yeBd1BPxnXt2BWazsegnLkmijpMvBdHJMzj9xNM 904Hjd9r0PgG55h4ee8k005veP4V2bbUkc74n3+lFl5YjvcLnacgH+5zzW+s T70m6Qq4nAWc6lj2noV5V+S8Z2HcU1Lnegfpps6SYL8cwb+6PzhvQM9pswIG X/qNM6YR3ks1aF6jtIieL8+/gnRhfW7t29k3We8atQe1z3PbvKVvz7+C/XKf 7yeOsKx/Ddc4kPODpk7sdu4paWLoQLcac/ac3G+v0Xv5lMtcJV3SITskT76K PCnaoXpWK92Mx8jsI44VrEGBVh4jLo9896rcz8PfFx1yrskmz71WO/Kpizy7 1JgnFsjpOuObX3+D9R3lx4nzr8s0rudGHvs5t7HH8Zb6hjHec8vxMu/JY278 3Xqk7qtSTsGcC+DZz3FDX2H945al8EL8Pyn0Djd+nLPzo8DnjMGDbwLn31T8 KsbinDH3nPxxjsfCa+gW53CNatXnMjLP5bI85zkrvtF4nZP8IXlRr8Ekl7Dt LnPNfOfoZdPzzlwAHVOyPOvsr9Tg51cMGjr5+RWmzysGP7/C9Glm3noFeet7 lEbXyz5J3dop47hfnd8b/fH8tbM/hgyfOwq68Rn6thiAv3PGmTLuH+ZQP+a9 cMDcC8P3kyA7jrwEeY57z5rpBch/1pkf9MEs4JAF2l3m0zx1JeOWFWc4g03Q Zva4OKvDdrN4bnfce7LldMuHjpxpOXHq2HWDLac3bkXcsobOkJX7Y27/FWf7 zJ/fK2P2oByD5ccG6vIuNl3A2Lz6nRobKRegvoLZfq19P9LPPAsjvVLvd18+ U71ura01NkdpzE+8dhzaX25NrbWnehvH16Fnfe5uqW+c3PDs0/DfU/Dfk/Df otzTntrw7OMG/JiGv/CEARv5P/fMxdRdvFrves0pV7iddXa5/9zJles4z518 azpOfQPrrS8KXtHfGPd1S+G0tBx4q7h5/9yhf509bpxt2fWvt47f26N/eX9N riHAV8+e8n/uWQcv8b76c88yL/ml7oW2G8CvT2uewjzIU597Fnjq63a9Ttet da1nn3a0Jf8eWEGbM44818gzPUzTsuTZxx286zPqecoob63hMyizvGPsVgl5 84UnT0MeN3nD9T5p1It6VkiU+/zTZ6hup4x+/gXY273gLqOff0HL6Odf0DL6 +Re0jH7wJMjol4WM7juJ+bSMfv4FKaNPbv78yVp9U/cMmz//NIzLU9xfh8yw je9HeQyfNPfJx4A2TPfHNL+p+n7NMe6/wmvUWfjvFZCJT5y67PNPGzYyql5D Pi4yjZ84BvTke8qtjr5cInAR32voeM2mDHPU7zXrdyvvXVkbfrONk6Lu+uXq 1nsbkPOijA/LAN2eMPeWyE81ZAztlz4D8mIR8jjlzCdZzjwm+OBybePiaa0t a77wBOICOCxyG5cLHD538pMw5vrs6NlFXcfnTtJ5GczBl+znkTzPqD/19vOM Lyyesec1zkZPvIJ3ty+9BXkn93eGTYB5r/SK45txL1G3n3n1ZRjHZ7Ecn3W9 zGPS5DjPbLTZ8Bypu8WxP71yDZ8Pi7OTfZ1ad38W1vdnnzHtM/CMBtp72eDT Z1v5zFTmlXYAx/zPnrSf5z37jNaVnj15SuBv7oX/0LEHdzujucE4X331FPQB 9DeLz0d99nG17dObjbMZTKt30UVeZVzw3OYr5r5cy33Rf/j+hEsbP+/SRox1 wxehv58FGn1W3MfB31YrIHTlwRZxN6juywKYzzzvcspKkGufRVks6kT93GrC MqY8XwTd5DPYrkv5417rclzb0XbB0N1fZN096LKv8dn6f8STkv1y1/ff6lry /S/rtWTLy7XXkudfBt36xSVk2DWSp+R3fTf+VvQVzw87x6ZG+5fZdbHnX6xl H3eK53Qry3ScjxdQ5lZjDrvd8d3IMNov3cB9uMxsR47jMuN+uWP+dcL868T5 55K30fFb34upOf/t08Y9q8drk8HPPuuQwWsd63aLXOtryHebzIbvz75VmW3K 6Np7rRM75V4L7SG0rBT3NsbdnX+NsQ+CtptPb/SY5/qYVn96o74PwjufMxtB fgh+8rnuzVuttWjrgXa8TNON0q7XOJeR9mwor9ukXRreda/Vd/evsS0CyJgT LLdOoNxawziptNOXnfgN0EO9LMM+S3awhp2bSENbN7oLRfgZwN9rpD2DdimD noYd6o4rtM/Lsu0ax5nSs8Y97DPGGcU10Oaz5hkFfn8J0o57B1edNu7cJP1A Dp00aSfrhXqeOeb1tEj7M0e9L0vbAhdbyDPSFlLrOw2ruM0zp9r2+YgH1lg+ uw1LQ7PKw/1GW22g7VOOs4urFU+3WI2LwEdou4i2gdCXJ006fQZlpYvOpW0L Pa3HDfn/mJ9sKcbp3hL6j/ZJnzL6Vou/0d7HzuPEt6v+4/Dt4jjje7O0VXLI 0Bud6dwPE7drVoDb+JubU77iv7855etefk75It8lc2pyBXNqUs4pl7nU9Gbm 0qCn/o2VjLtMv5LaXfS4jDeeMay9kLF+6+Nb//zy41v/bI3xfWYF4/sMzhnA /7Nvw/jupHNfoPkS4xtbgcz0Xug4G31eXEGfF6Gtx6HPj7+VPpOc7jnxNUPO npIy29hTfdxuG2fIcD/k33Diy/iXZd2LDHsBfuEkvQPBt0pWO/flJi73ZaDR dUijo63rfgXGPyrtWo/5Sda94LATe4HtBV/A9kHXs6BM+0rL4HsS3FcBfFKf 15/4Mq0RLftuQrnM9brp2+OGvj3GNOlQ76uq78lwL/ws2xrKs8FvcDrNQZbp +EbmRVgb/rteG0R9iLs556DMSV4PTom9ItD96hO/jXSGv1+DcW2mOmEsW/Va epL7X9UO97Vz0OP906VoeIHt+uw2czjuuDdY3Al7vANy3WT6truso+rNkI9t n/j3N9bqswLJZ6cMHUCl2WkJv8U6e9LkV9Enon/NvuBv+xsd7/EVyN8nsJy0 XZZ7SMf6+4QhR588Te3so3ZgHX5iiXX4SZusMNq5gvbAMLft6/ETb15ee/cs L6+9kzZ5zfh8AvAx18klZOgR02bGoKF599QgbKy2nm9luwC+f0KefpXt8Hw1 9uqtVXs+Ya9x1qVuaQtyVtbN68CrTpt+M83cv3M9DbVtIZ8dVLaQ/ufPIc6m bTDey3zSfn98zu0cwkGfS6W98Schv5TP8o7HtDlm/B6VZ8ay/mOt65BXXnO7 z5C2pqcvg7xij3uT+sb3e9iX4/7nnoT2n3TeLfHbJpn/VT4DftI+Z/D8F2kN f70eaetlv7s5cf5PnHaWGn/k53W2965mXV7uwyK0e8o8R+a7RLVu+p99EvMI uWhfO2ufZz9r6wvg9KTxxmnQQftNZh6j/08gDTHduHsGPoN0ITd2OvUE7Due cx/3Wq0mf/N70WvMumrRqTaurnZ9R23vtrVe0urQC0bstoJaT3DLY9Z/ITbz ht0dyZDv4Hy6uspGcsPzr0Jbr9rOZ/luROL3kv0c6rVlaP+I8x2lA+dGx5tg 9TbiDMnKxUHg4eZPbDxbd9x7pPmnNi76Ptl2suXjG8/6jrUNroK1x4820e9E GzX6d8hcB1xk8x7JT6dq24m3OmwTrjS+NVfbESsbha877CtvrfG+47W38L7j NRebV9wfXHlavO8Q54Jt1nrgo4BY7/ENhsh3kmyI8S+9ayA7dHzjcBRtpuz2 JGQXLeTFYMsSNrpEb8f7W3Pd2sQ6w7lj9jNSskvGs+Em+/isc7HJuda0bz4D 6UfbACe2wW1S5850lntOvJ8Q9oVA1+ljaxJHDD58RdgRnHj5dT+dOzcsJ6cc 71j95htVPJeVddcaR3N+Vr9h1rbpznbd8AE5cM3TwEO1vkkdE/I0u+VZhDy4 Tn3o/Pm/E/12r8vI9zXz/Zxbfvy3omBw0qUMOwuV3kKjm4PdVijcF+7ui0Qd 3kKlnwaqJJGaxzoSyaRyybI5XU5iWmpG/J7KF4uHu6yJvDWXzhasxEIik8VQ PS2XiO83d20sISxQ8XgqqYJIL/VhoVIlOWeVhKedPg7pthnyKM/EiUoZMlCo JP17JpNLye9J9HNnfMffxndbeOjZfPEA17w5lV7YnMznSvlsWubL5dkjfAvh W0wnF9Dv+AOVdKksor2Qs/GbS+T2aODmVKeVSdGfbDq3vzwHoMJ7TzqZzixg YOfcgVz+YE67lLcol/nTKufz5MK8E39sGbCMetBbEDTYvpermT5cwCIdMsNI MV8okMvISiGLfoyAjIQqFNpkjY30cWV3ZLJZzFbJFdOlAvQbkLOSc5lsyipk UrpFVV+R+92OyM0ncoc7XCveDiS1ZmHQ2Udg0SSXAwf8N5kolYR7Q7M64ATy uUS+PKXD9pba+cdyIkgKFkL/di018u1CV5jQGfx6MF9Miby165X5x3E+uZTy eNC9Vu3y7FitwAXZkSN5H+VQhrKuWv2SMWudbZv5KzkKhoUOXoUjSNUejoDI v3dqzyZ0PLdpeOfQ+PjoxI5Rgf/E6DQ6tkoXt1j0W1KylM6myWkiT9wd+Xxq 5nB6nZzH66VXrj4hSda3XLJ+hLjNTaasl8U8hoct1xGfwMBfS+SbSicrRfQl uq2YTiTn1FDUyl/NGVIObLH5oUFphX/RBxr+faAi/rLbMs+udK5iTRbzFLse x282X8nRaFgTQ1P019bEzaWbS5IvaCh2JkooUTPFdOqSFiP9LpiI/AGdvsKE H0kcLl0i8YQxzqI0SfPve/IV62AiVwbJhAOuPqMzzq1bL2nZfSBx2BqzDkKt lD/I5abQ/Rtw8p70B5Cd8rMWzXKsA8XJzSWWIDLfsKrYPavMN3mXNZQ8sHx9 S2aCf4fUuGwmwiVhxufKJU/RkNtJKbfzhXQOa4B6ZkG0W5wZK2N5k9ZRt+Yz pflEWbAKRh0QA4RyFOtV87iUwKkEWe61NiUwEmk5nsoUrfutezfNA7Fh9GlB m4cqIef9mK1k0Z9D4k/KSs2IIlhnNr8fWcWT0PgPO9HH2Qn59qNDY0mHmzeF Il2hSAlRMflnE7EIuaXz2NLvShTRLbEs78hGdCO/fvmcVcrsRz977cZyof6h T1ylHjQHu4I9K3eKqzyUeRpBFt5xF8CrUrrqDQYcvk3D245oOGXACwb8aQP+ TQM+o+G6awz4PgN+0IAfN+DPGfCfGPBfG/D/07D3CgMeNOB7DfigAf+0Af/i LR7y24bwrwP8EMMvGnm+AfA6AdfX6fT6doBvYjgC8AaGtwLMwqt+DOARhqcB ZqleHwd4guEDAO9mGPGcZPiHAGb2rP9JgFmDq0daMffUPwkwOyCs/28AH2T4 dwB+mOGXAP5+hpGGH2H4XwB+RMC+VQD/KMPvOSK91nl8kwDHGP5h3S/fxwDe yjDywCDD/wngIYZ/HeBhhp/XdPD9f5oOvtMA72D4zwDeyTDiOcbwPwB8O8P/ BvBdAm5o1PRpuEzTp+F6gJnnGzoAZvZu6NFj1zAFcIXhBMA/wjD268cY/m2A P8rwHwL8Ewz/OcA/yfA5gI8y/H8BflLAjd0AP8swjukJhpGGLzL8UYD/iOGf Afglhn8J4D9l+NcAfoXhzwP8Nwz/LsBfY/iPAP5bhl8B+DWGkYZ/x/AbAH+d 4fMAf0PA/haA/4lhnEf/zDDywP9j+BaA/43hzQB/m+E+gM8zPHxEeaPzjwPs Z/gegJsY/oCmf9PxI8pBYtOTOr05CunvZXinkQ6you5mhj9qpAOf121i+M90 egv0pS7K8EYjfR+ks4hrKQHM/NnyMMDMey2PAMxzs+UYwFMMA5/X3c3wLwN8 P8Mw7+qY31pOAsz81vJ7ALNa0AJ8XjfL8P8G+BjDMEZ1P8Mw8Hnd4wwDn9d9 WsCrgM/rfpbhVt2XVdCvup9jOGykJwz4ZwzYkMmr6wH+TYbXAPwFhtuMPCir zzI8D/BfMWzI7UtQtrcxfBPAvB+9ZLOR5/u0HLgkY6Q/BvBGhp8w0r96RKlF l/y9Tr/0xwDuZ/i4kY7rxXaGf1enX/bTWj5f9qcAhxn+K52n9UoD3mvAr2r4 coN/Lt+n+3h5wUhfBPhahn/FSP+qXjsu/yedvmYC4A6G32+kf07jvOYFI89f Anwrw/+o81/RZcDPaXjtHVqGr73fSP8RLXvXftxIP6fxXPt/dfqVOL63MGzw xpW7Ae5k2Kj/yh8y8htjdOVn9Vhf+UUj/atGfqNfV12l+3vVLUb6K7pfV53T 6VfjWPO8vvoXAWY/slf/VyPPWQ1f+x4Djhuwoc9ca8iT6wb0GnTd7Tr9+t/S 68v1L+j0G3DN+gWGz+v096wzYEO+vWfOgH8W4FcZRtn4fxj+nJ6D7/kSwH/N sKEjvXcXwP/IsDEubYYOdtMeLd9umjHSUVaw7L3pPwNsMfwbOs/NSM/7GH5W p9+yU6+htxjz6JYTAH+G4f+h0zfs1nD7kAEba0H76xruCGiadNym0zf+BfTF x/Df6vRbPwXpVzD8Szq9E2Ra3Q8wfECnb7ragP9Qw10G3bre0Dy/uU7LqM2X 6jybf13DgesN+F5dNpDRczBQ0rpB4Pd0/mDMgB814D/ScOhmA0aZ8wmGP2+k /zPA/4NVe59ODxtjGsG14BqGDV06sl3D0fUa7jmg9YceYy3onQXasg7ca+jb vSBL6zYz/IZO79ut52mfwat9sOZ6djH8szq9v17Ptf41Rjr2l3WA/v+u0287 ZMCvATzNsLF3GKgAbqy4DHzYSAd5W8d7sAFjDdqCfMW02vLLOn1rVvd964Ow QPwawz+4KGDQfbf+GMC/7mEdFxJ+Q5YG+LO4sDL8ggH/jofXG4C/JL1Jjwgd 8jaG/z+jzt+DP3cz/Ad4bMIw8sBDDP+hh3VWgE+hazyGURd9huHT8OfLDP+x h/UAgM/AnzcY/hMP63YA/2+Ab2D4LwCWeH4F4HGGYf7WZRkGmVZXZvivDfgc wI8y/Dce1odGSL+te4ph0GO9Iwx/w4D/HuBphv8B4PsY/kcDBty9EgfQe72S JqD3emW7/wLwcYb/FWBJn28BLHH4NwMGfdj7LMOgD3uZbshW3lcYBhnlfZXh RoCZhqgne7/F8GoDvgT2ZxbDlwIcYPgygAcZBvlWz+NetxbgSYavBph5AHm1 fh/D1wPM/IBjVc80r7sRYKZDHbRZ/2GGQR+oZ5rUtRkwrNf1TJ+6dtyDMgzy rf6zDHcB/CLDICfrzzAcAvh1hoFHfMz/dd0Ay/7CftPXyXAfwDGGQffz8fjW DQAs+wJ7Ut8hhmHv6ZP4bwNY4gz6p2+RYRgmH49dHchhn8QZ9qG+kwwDXX1y 7GDd973G8B0AyzGCfWgD8z/uCxp4PtbdA7Ck/70AM7/VAQ82SDrHAX6EYRif Bp6PdbCfbWB+q4P9bMPTDMP+ooHnJu4pGl5gGPYUDTw364AeDZK2GdjnSdrm AWZ5UvcAwJLORYAlnYEXGiX+CwDzfKkDujZKOj8IsKQzrKGNks4/BLDE+YcB PmPkkbjBPrrxmwzDPtrfyjD02y/x+RjAks9/GmCJD+yP/JK3QR74JT/Dnsgv eRjG1i95EvQNvxxrwMsvx/cXAZZ0+yWATzH8nwF+meFfBvgcwyC3/XKewl7J L8f9t2DPupbhzwHczjDsoZokPs8BLMcXeKpJ0uSLAMs6/zvsWX0MA17N1zAM Mr9Z0gRkfrMcI5DzzZLmIOebJW+DbG+WvAF9apbzDtpsYZlcB7K6RdL2JYDl nIJ+t8ix/t+4P2b4zwCWdf457msZBnneIucCyLMWSROg2So5Rn8jjxcB/hrA kv+h3CrJ57D2rZLjBTy76nE7vBX3Jp89f/48lNmKeul/Axja2Ir7xN8EGPDe irrobwEM/d36BYCfARjouBXP7j4HMOC8FXXjzwP8PMCoz38BYOjX1q8D/BzA MJZbcb/zPMAw17b+K+pjAIN8GEQd7yTAIN8GmwD+IsAw1oOoI/02wLQun+RN sYbFGic2zmJdE+linWJ4WucRaxOnP2GkP2Wkv2Gkf0vDQiaLPGLcRboYa5He YuQX48Iw0HnwhvWeOj7PGexYFDDgORgEGLp4HtbawYFFcUQK6/jgrkVxtc1j 7fVqHcZb72E9EuCrDfg6D58hAny91k+8uNdgPvHeiEfyDOM+lHnDi2cLzBte nGcsQ7ywL67jueOFfWUdyxMv7BnreO54Yd7UMc97g1oP8cIaVCdxCHv4vAZg WI/qWNZ5u7Wu4u0FmOedt0/rJF5Yj+pYtnhhPapj2eKF9aiO5yC6Fq9jOePd AzCvKTj+dTyPvHcaMKwpXtkvWEe8PH+97/eI/iMMa4qX9SvvPg+1QTCsHV7Z L1g7vLIvsHZ4WS55oa/eIwzPap3HmzHgA1q3QV3Jy7LLm9P6jLcAsMQZ1pF6 iSesHfWsr3oPA8y6mfeDAEs6PwxwgeHvB1ji8yGAWT4gjvUsw70/qHUML6wv 9RKHHzHgjwAseQPkro/XZe+PAixx+3GtV2BffZKGPwkwrzVeWIN8rFN5j+H5 N8M/BbCk7WMAS/x/Wusb3k8B/BjDwCM+ifOnAeZ13At98rFc9cI65ZM88wsA s97ohbXJJ2n+n2BNl/wA9TVIPoc1q0HOr6cM+FcAlnzyq1on8f5XgOVYAC4N sl+wxjXcZ4cH7zoCc1nI28E4wD6AQdYPzgPcADCIj0HYW3kbAQb6D8K+yesX MnnwJwBuAhjwH3wc4BaAYUwHYV/sXQUw0H0QZLX3EoBhnAZhz+u9FGCg4eAf A3wZwHid8ArArQCDvjR4DuDLAT5kyFvo7yDsJb3TkG7IWDGPWE4aslHwiUgX tGIY+/ut9R7vC3z73bIoYKDV0NUA/47eW3l/15B1X9J7NK+x5/L+vgH/gSHT jP2XF/dZkmdOG7Lujw34JUPu4V2AnI//yyP2igjDeu2R/PPner/m/QuP2Kch fNaA/1Lv4zRcvX4J/Bk21jKBP6d/2Eg/bsBnDBj+DN0EtP0Hpm33ooCRtsMA /6NB2zcM2v6TQdt/M2Bcm+RcxnsHlvP1dJjDMK5NLPPr63X99X55hQ1ws4fv vQDGPT7P2fpVHr6/AXi1pnP9JbLbAOP8Y9lej2ZvrDfWr/HQ3pXgK/QeuX6t jNID8JUGfJXeO9fD+lgn8YT+1bE8rH+Ph/RjgmGtrGN5WH+j3gvjHrGO5Un9 TR7SNQne4CFdimCQB3Wsp9XD+uhlWVHfqdeU+k16Tanv0nvq+s0GDHT18hpa H9RrTX1YrzX1sG56WTbWx/RaUw/rplfi2Y/3qwyDfPJKGg7oPXI9rKFeif+Q AcOezstyvh72dPUsG+thH1fPsrF+h9474/64XvLGHXhPy/BuvY/GfXO97Bes 0fUsD+un9T63fi/AvMepv9OA79F73npYo+t5PtbDGl3P63799xlwXK9ZuC+v P2eHh3aDTPsnofcOvR/gfxZyeGgW4P8r5PBQAeBvCjk8dATgfzl//tsIHwf4 XwF+pca8fsSYmyeNdENvrPMYsnSnkf6Mkf66IWNNnfaIkf66IXvvM/TVJ4z0 zxrppwwY+7u4nvUFpo8J452aHPeMAR/Ay0SGs4Z8mNfnZvU5D99Dj4jzDznu C1oXrUc5IXn4sJbb9R/U8rn+YS2T679fn5vVf0jL4fof0LK3/ge17CWc5bij HH3dDg89fQT6yDzwOYBnmQdOALxf8IAaO58xplj299azDgXwny0KGOXt1wD+ mCEPjxn0/LiWsfW/YMBPaB2+/pcMufqkQcNfNmj4X/TaV4+04b1k/a8a9Pw1 va7V/7pBQzwL5TM04gs5X/6bh++/Acb7SikfvmDAzxmyFMhSxzpP/Re1zl+P 0dIkPrDvrpP4vKB1+/rfMeQtrPV1cl04Y8B45innPqzLdRLn/6n1/HpYo+uk TMNzUTnusKeuk+vCXxgyGb57Jf5fBVjKsb8GmPdN9V/T55b1f6vPLeuBR7wS 57/zkH5J8Ne1Dl//DUP2vq7PJ+v/3pC9eF4q8fwnA8ZzUcmrIHfrJc/8Pw+t bQR/S+v/9f/mofWG4G/rc0t8GiDlqs+n9Xxfg9bzfY1alvr8WpaiLi/lp69Z y09fiz5L9MHaXc/09AH/+lgm+C4x4Fat//tgjfYxP/jWan0en7ZJfd4Ha7SP 57vvan1+6LtGnx/6rtVnhr7rtA7vu17r8L73GvCN+iwRzzulbu+DPW8D75t8 bVpv98Ga3sBnnr6bAS4Y6cyHPtgLNzAf+m7V54E+WMcbeYx8sI43yvphTBqZ r3ywjjeyTPDBvrhRtgVreqOkD8jORt4/+qIefJ0rYFjrG1mP8vUaMKz1jZJW sNY3SvpAnxqZ33yw1jfKsdvq8fhX63Q/r8s+WN/9LE982wGWfQd8/XKMxgDm uekbN+AJgGW7sNb7Jf1hfffLdqd5uUAY9t1NPAdxn9fEcs93jwG/X5/1+WB9 b+I1xQd83SRxvh9gSUNY95skDWHdb5qzw0P/DPL840LOb4NNcP1xIee3oRu/ Twg5v60N4E+KtX5bCOCfEnuubVsAfkzsubbtAvinxZ5r230Af0qcfW2rAPwz Yj+17ccBfhxgoOG2zwD8aYBBnmz7JYB/FmDAZxvs0ep/DvSHuRr6Q8FYa4w1 SMhe1hMeM/SBmKEPnHXXB8TcFOlibnL6GZ0u+FmkCx4T6X5jD+I32hXjLtKb DH2mycCzydgD4lhsM+xGhgPrPb4PMDyyKGBY74bfB/ABvYb6snoN9c3rddP3 IwaMtnYsz32Iu5yPP6bXVt+P630N3VdIHvsJrbf40N5M8tjH9Zrr+5Rec30/ o3UY36e13uL7OX3f5/t5vd/xfUbf/fme0Gux75f02opnGPJszfef9dma75f1 2ZoP1v061gdQLtbx2YLvV/Q5m+/XDRjW9Drei/l+S+9l8FxErqe+zwEsZenn 9Rrq+4I+K/M9q9dT3xcN+L/rPY7vd/Sexfe7+h7Q9yW9T/G9qPcpvv9P3/35 fk+vpz7Y13t5b+j7MwOGfbeXz3Z8Z/W+xvcVfVbm+6re1/j+jz438/2V3sv4 zum11fc3HrH/RBjW+nq5Fryu7/h8f6/v+Hxv6Ds+3z/rez3fvwLMY91Qr9fZ hma9zjas0ndzDav1etpwkz5Pw/MkH+PTAGuNj9eRBlhrfINGOrfbsEnfuzXA muJj3muI6HOwhj5974ZrnTwHa9iq19AGqNvH60UDyH8f80AD3s1JPCf1Gtqw V6+hDXfqc7AGvKfjdb8B7+aYbxvwbo7nMp4DyXW2Ia7PxBrwDo7HugHv4CTO s3rNbcjo+7UGkBWNPF8aQCY0Mh825PX9Gq7hjTxfGkoAM382HNL3bg2wp2jk +duA92isvzXAPqKReawB791YL2r4sAH/mAE/qu/gGvAOjnWkBryDY1nUgPdu LH8aQLb4Ja2O67W44acAlrR6TN/BNfysAf+cXqMbFvUa3QAyxy954Bf03VwD 3sfx3G/4TwBLeuIdnOzjf9H3dA2/ZsC/rtf0ht/Q93c4Pn7ZX7ybk2MBdTdJ 3sC7OdZ/Gk4ALPuF93Q8vxrwnk6OBfBmE8vVht/Vd3wNIEOaZL9AbjTJuQay oonlagPwcpPs4x8Z8GmA5ZhCP5pkv14CmOVDw8v6rrAB9hHNcoxA5jTLvsA+ olnyM/S7WfbrK2g/yzDIn2bZL6i7meVGA+wRmnlP0QDypJllYAPsBZpZl2v4 R4Al/wMuzXKMYI/QzPKtAWROs8QT9gUtEjfYC7RIHM4DzDg0gixqYRwaYe62 MM80gv7f8qiRzvpbI6zbLTy+jaDzt3C7OOdWscxsvAxgXptw/q1imjReDjDP tcY1+o6yEfT/VRKHtQYMOv8qpgPO3VXMq42g569iOjSCbr+Kx7ERxmQVy4TG 96KNLcOg56+SeII+v4p5shF0+FW8n2oEmbmax7QRZOlqnmuNID9XM90aQT9f LXEGnXw1j1cj6OGrmQ9Rl1/NsqIR9PDVPO9Q3qyW9AS9ejXzZ+MWgGW/oM3V LJMbhwBmOdwIevVqlsONdwAs+wKyajWPdSPgtZrlSSPo1ZewPME9hIJBJl/C /NAIMvkS5s9GkMmXyHEB2l8i+wjy+RKed42gb1+SssPD9x8BXUvozMMfADgn dObhwwDnhc48/BGAC0JnHv4kwA8InXn4FwEuCp15+FcBLom74+EvAVwGvRfh Pwe4AjDQYfgrAC+cP/9vwIfDoKv7Dp4//y2AR4BBfIcAhrkwcjXADwIMc3nE AviDAAM/jGwA+EcABtqODAH8EYCBZ0YmAX4EYOClEdDVfT8KMMiKkQMA/xjA MC4jHwT4xwF+HOCfAPhRgGHsRn4B4I+eP/+vWBZ0dd9PAIxlfw/gnwQYy/4Z wEfPn/9/2O7XAf7Y+fP/gjj/C8DHAAacRxsAhn3HvzxTQ89/1dDnjbsAobNx +huGnm/o0kIvYr3duB9vNO64xbrG+vwpJ8x5DJ1frFOs2xt7BLE2cbpxVinW I4aNOoX8Z53fuFtvNs4thYwS6as8xl25QYdVRv5VRj1iHol0MY843bh7Wm3Q bbVxLy/mC8PA56Nr13sa+b3A6E2LAob5MhoAeL/Yg4zGFoVtDusPjRm9H2n8 gN53NFYM+JDeazQ+qPcXjR/U+4vG79d7HNrrs17U+AN6f9GI55lSTv6wvk9p /IjeX9BeTcrMH9P3Jo0/rs9FGx/VZ6GNH9X3I42gn9RJGQJ7nzopQ0AnqZMy 5Kf0+V7jY/oev/GnAZb4fEqf1zX+jN5fNH5a7ykaQYepkzj8nD6XwzMMeS7X CDqMV64vv6DvRNDuyStl13/W52yN/0WfrUl4dOQIjIuQXaOwZ288IGTR6D0A Z8X+fTQBcE7s30cPAowyDefsDwFcELYro8cARpkGcmb0UwAXhe3K6CLAJWG7 ouZyqzE3sa2ngK9+i/nq+UUBI1/9/qLQMZGv/hjgzwm+Gv0zgD+v7T0av2Dw 2LN6P9v4JQP+PX323vj7+m6u8cvaZrXxD/S+leY965CNp/VZceMfGzz2J/BH rlkv6b1q45/quzk6W5I0/58efgcFMN6ZyjH9C72fbfxLg5e+ou/gGr/qIVs9 gl/VtqmN/8fgq7/SZ8KNX9N72Ma/03dwjV/X58CN3zD46nW9P23EM1ipq/yj tl9tfEPvVRv/Se9VG/9Zn/02/l+9V238F4P3QAfzynX8vL7/Qrcc8p5LwqN/ AzzzLPPkPwD8HPPkeYCfFzy53Q/wScGT298D8BcFT27vAPi3BU9ujwH83wVP bh8E+AXBk9u3A/w7Dp40ZB3isH3Peo+fn59v37coYODJ7fMAX6plkf8yzXtk P8h7Lv81Bny9PlehPQ3LDf97tKzzv1fzs3+dlmn+Nn1m4r9JyzE/1sE6kv9m Lcf8G/Sdjr9dyzF/h+Y3/0Z9N+E3bJP8m/SZib9Ln5n4w/o+1x/V/CPh7aDn +FvFeG3/QYAvF+O1HfQE/xoeL9B5/Gt5vJ4C+Eoer2cAvkqMl33d5zUd63kB xoLfb24HOUAwjsVZgLeJsdj+twAPC/mw/R8BHjHoOWqM0XYtE/x7DHivlg/+ O7V88N+l5YP/Hi0f/O83xuj79P2aP6HXEf+MMRYpbSfmhzWxTvLGB/Sa4j9g jAXo1HUSh7w+1/JXjDE6aIzRIX2X5D+s5YP/g/ru3g98VMdz0/8wwLwO+j+k bcZgWilZgXtlaTPm/4gx7rBueiX+sG56JT9/VN/X+2F99Eq6HdXnXf6PaRni P6ZtwPywx/eyHEObWXnGhWeo8lzLD2uoV+L5KS1P/D+j1zX/4/osy/9pfX7l h/W0Xs7Bn9d38f4n9N2Q/xf1Xbz/SX3G5f9lQ0b9F31n5P8VbaPu/1V9f+T/ r9o2zA9ztJ7Xd/+vASz55L8BzOdv/mf0fZD/c9o2zP95bfflhzXOx/ssPJOQ 90H+5/X5lf+EtuPC82Z5ZuX/oj6z8v+2Pqfy/w7ow5L3vqTvdyS8HeStf7uY 1zuaAN4BMKwrO2B/4d8p5viOmwAeE3N8x60A3w4wrJ07wgwDDjsGGQZe2jHO MIzdDtAx/HcImbAjzjD0bUcW4HEhE3ZUAN4l7F13HAF4AmAYsx2PAjwJ8KJT hjP8TUOeRwzbKujXjsdAnvyxyLbjFxcFDHNqx68uivMbSfM/MeTGS4Y8f9WA /8qQFX+jbUr9r+n7aP/X9ZsXuueRfP5P+u7e/69al/B/W9v5kJjmc5gmr753 bqrXsl3COz4HNHmJx+t3AX5Z7EN3/CHA/0vsQ3f8JcB/IfahbvKW6vnGej6j AvjbiwKGvuxsAfhyTZ+mNZo+5FqYadL0XgO+Ud/RN+G6xnOn6SatRzXh+sVn Ak236HsButfiudO00aBDp9apmrq0ft4U0OtaU1C//WkK67c/TVF9F9/UrWVp U4+WpU0D2ua2aauWn3ifJu2dmmCtqWM53wR11PFcbhrVOlXTdq2rN40Z8O3a hrbpDg/ZBBM8ruVk0y4P2cUSPAEw30007dZ363guKGVj0/u0bJTwTpinTVcI ftgJelETrL/fhvHdCXv/Jlh/vw1ld94NMKy//4ZwHuCrxTnATtDtm64V5wA7 fxLg68Q5gKttuWljY9xnEQ4w15r4bebOX1oUMPISzLWm+w1e+j6Dl+IG/yT0 utw0o/WlpqSeX3QOyutyU9oNdjlPsAyev9sO73wGcC4Y+JhwUdv2NB3WulzT g4LPd34RyvKb051fXhSwxPMjRj2PaLugpkcN+KNanjT9pNGXj2k9sOnjWoY0 Hdc6YdMntO1l0yeN+fJThtxgeOcZGNNHmDf+HOAfZd74J4B/DGDTnscYUyp7 fj2fVXCdJvwrBn2eNuBf13eITb9hyITf1DKTzp7lvPu8IRO+oOVk0/PaVqfp pNa7mr5oyASGxy6FvvyK6KOrbRLmuQH68gfi51jXooBhvMa2APw/DP78Q6OP pwz+/BMD/lN9jtH0v43+vmL0988MHv4LfU7S9Jd6v9n0VYMOr+q9Z9P/MXjg r7S9btPfGPR5zVg7/k7rok2va1206e+1LWjTPxjy8x+1Xopn/Ep+/pM+62j6 ptZLm76l96pN/6b3qk3f1nvVpvOGLGV4DHSAplNiXMZQ/vyRWKfGEgCfFmvT 2H6A/1joGK77Aqwnt97TzHu0sYcWBcxzrflSPV7Nl+n51bzWgK/S49V8rR6v ZuNtCN1v8Bg1v1fPR3oLxfpYc5vm1eabNH/SfQiPRfPNei1rbtf7teYOPUYS HvvIEcCZafJRgFuZJscBvlycG4/9PMBrHPRpsts8j/060IffII+dXBSwpE+X QZ/NBk2CBk1Cmm+bIwYc1edvzd16H9Tco3lVwyZuDN9g4BkwYMg/9iXAmf1p jMFej2CJ820GzgMGzlvEmdLY/wKCs+uvsa/CYv2AyDP22oc9+t+IykNwSdfj Kev9oIRvj0GdD4rctw9BnYeN/A8a9XzQSH9I01DCt9++nucrwFNQzw/p80/P h416ftio50f02ifh2+9bz7wGcBrq+XGjnkeNej5q1PMTmrclfHsOKvsprudR i9cQgD8N8E8z/MsAf4rhzwLMPmFuf95iHgf4ywCzT5jb/xfA7BPm9r8CmP3A 3P5PFuu2Hs8dDQD/PMPXW8oPwx1d7Wz3AfAQwP+J4TuVka1yNObZnD5UyBfL m+fy8+nN0vOocFbq6dL+Sj37k8lQPJmfL6BjyS5PJlfuKwcHisH+TaFgpCcS C3dHYv0K7OlHv3nFvnJooBjqD/QHQ5CCDjUtKhheqmAlh27S0imRNYJZA/2b glze/jXq+Kqb6KYvwYDbv/5Aj9s/sw57Mz1Umb2KYI06SnNATlEsRt0Mh3q6 Y/34v+qrvfZe0YnuaDQchRziiyBfMEBVBEMxQUJVkD8HRdFQFArOZvMJHJQQ pkUg1ZPKV2ayaUgiescwiTqn0om4wW78gEObTR8SGAWjA6VYMZ3I9gU7A53h UH9mPrEf4HAIf+jMskkkdrdoU35SbSDtekTj8psdCaRSjLFYyGdSkNQ7EOz1 7Bmegh9TocDAxpCnlEyW6FdwICGoBb32xAtzh0uJVDFe7psOhQZKkWJfKMwZ gOkE7v0enascikBtUDCbmElnqRh2dQF6GurmgkEq2B2BgjJXORQFyiUPIBgM IvPHKBWhYDeCMQTDIcrgqcgMQQGLLL0EizwRzD6fOKTz8w/6UCgX9Qf+QR/i 2XSiZLQtfhsYiAQTD6NI0EwxcTJLRYhF8D9qpWegEoun+oJhQZI40Cmm6BSW dKrEbYV6qwqFA6pQVBVCHpZ40bwwMCJMKrLGqCeJziSp8oAnJeGwJymyxjwF mRaFutJca+kw8IykTSp9SID52VlROJPLixIz2QNcUdgzW9K/ovBrNpNVv6y+ 6XBwIL0tvn1ofGq0L9C5LT69Z+8oTIx+z0w+D1TMUSVBRKc7QnComhbhakar 6AKR6gJRVSAiC0AnSumyGCIgv/Gz15NN5xhKZUoHFOF6PNms7Hs3NjLbF+rh Rgp94R6YB/FKX1hMGmxWTnc1G7Ka8rHqCnqXreBAfDZbZjyjHjE0YRyvZD6X Kokxn098IM8DOQ8DxGChmOHBi8/nU2nBKPl4Kr0gkyuiOkzdr8FcNpM7ILMU JDPk4zz0vZ4D6cNirshqgX8kYvsloGqJerhFwEh+LJTnQFKmBPbyB1cbAQnF KfOVcvpQ33QkMFAKReL2ZCBLYn+pLxJECrp86ouEmAPC/UGWas585cOFdF/E TnFnHhRhfZEwDp3Ll+5IXyTiggGwZl9EsmCPQACH072N/MFcughVhSWrwv+4 5UslygnMBEubYA5Hd4B4AU09ZBAgXvdACeSWLVXSrseGufoCpHPSi74tTS7K IjEU+GsERXnAr1vjh87DAb8YLEFxW2KhL9I7sDHYq5Yi4xtVEnOwiKgpGrDV pL5gdc6q1EdiTAfRuLqgrTr5wa02+Y0qC3ri+VwyDRXA4grrg6oBU4kxomHF mTTioWi3URllw4pgAc88mBZToiTBoKecmU+zIJfLK4NidokccjHMSaWHlwu5 WKilAuclOoRXkiWuS8R1kbgsE5eF4g9UoC/T0YjUBWJSZNGHcjRCiOCn6Sgq DOWFOEgtKevgV0X8lAoS5n4wn0PKdWP2B+MgzGCcSgfTpbJUqiA1VSpjVkO1 ylCPRUs9yO6ZMuIrkqK8eEIa/KykMUGyJ5YrFQCL6WjMDcNcNYaYnYYnJn6W ixX5W6DB9fVW4RFz4hFTeOiSVFWvZ64ohxmWoPJ833Q3MHe4uzxPCEpazCOF FB3g51y+UoTf3RH5OZU4DL97u+XvPGZH8SF+H04nMH+wW9Z3UBQI9soaD4uE UEhWmSmlaDSAaQVRZmE2JUoHSA+ABUnDgCroit0wjaBB/DSTKZf6upVYFrpQ MBCKiFowe7kbNMX8AlKwOwwjAnB8JlFK94UCrFRDAqzV5uBjdqRUNzBvJg/V 7IfCkYH03rHd8b1To3umJoeGUfHA31P3TImfwU75eUwkhEAf4eJUWQR/QUXA uZEAfoB2+rq7BzZ2M3twGig6Cpk4pgm1oi/czaPLlc5m9/d1RyTtMXEWl8++ GFEfNHkqnM3MZ6BsjEaACxfTqMUbFMdERDFKUPEgYNkjurtndGiEe3rXnrFp oWWJTFSix5NLl0FazWaQRsDy3ZFcMg5p0ICkMCSU0vMJ9Epf6otyzyCRVoYo 8xb8LhTz5fzsfPYwlhQcJlMxhTsKSbD8Y1wMTOuWLeSy+fyBSgEbYF6DRJnW DdIfcjPPwYdKDkRFqq8noBbUKFFDCM6J4d0T2+M7hyZGxkdh24kKAZSZA1na 1xMa2NgThjGLqb4lK8UipCv2KSXis4n5TPaw0G0wvEQapH8PirUsCGMYTjnf snH+qpkPY3agfgcFojjhVW19uEjAqEICrYk9aqcU7g/Bh85gEMvPl/bPUeke VHHgVxyDR6ixkAkmx2Ma8mJPjHhRjAcninxiMDApkUySL/SSMSK2dFGAxwU2 mwofFF8h/EmzLSLQ4d8L6azChpJIMZBiB/RsWMqwklgAKxH5edJQ76RAxZrD qhTo3YW4sWEE3NKFB6AWXIdLD8RnM0UQPDEY0Vh44FApfkCsl31yMRb5SVmF JZh/ERdMx3AwoYoHKmmQuzEeTkgg5S5IfYnpKuZYNY2BbpopoiyK0eAWMvHZ PEy3GEiBWFRUAmkzCagk1s2dwoR0Lj0LmHLXICWNuvhcBujYy3OYKqZGaIsU gwn8vt3bbo/vnRjp2xTsJHhkdDtMZgJxYo/ukb9obu/p42zDd8r0XXunR++W P6ZGdw0BDMtxfuYD1BKsJJViDpb6LK0ssRiQUaX0GR/lXqAsflZygCDsT4Pd 5ZKgQG8AKMBzCtKgd/lMbqGPiILnLv26MigaQz2oXIJqYr2cAQrx+PYG1UYt FpSaLXwGidRLsgEmETZLGisMVSgQ66TyB+XghWA2iRqxo4DLgphyoKexCOlH EveGBtJEoPjQyNDk9NiduCaIhKnJsQmgpv1rfGp6aBqWBZ1FpIQ5ZWQPZNoT n9hNqRF7KqVFnTXigHbDiBzQ2w8idMjDO51eXPPi+UICOLWvN6K3sL1qO6hU /d4w9So6kN5zV3xqfHR0EvojQYFAEH/b8QwZSdwdTBjdPrR3HHsBLeBaITEj 5uztpjaY66gR5segzA9ZQbMHkAZluhe1sJDqiDz9CImO9KLU5rxUtIda6R1I I88qZAKd4ichK5rChUkj1wstYkrfdDAQsBFOUUsUwDNB0PEPoJ6+ABoP5Aeh ovETohqycwZRIohYgXoykB6+00AKfxgoJRcUQpDXM0ssHwyEUW2YjZeJHr18 LjErFtFeFAzQ4CztBno7YwHxayGHCkEwEIHNTyAKk1MksMyYlZpFqEdOk9l4 sgjrYjDQjSV6oAT9lkvqbDxRSYG6SbNBL6hQKl/J2XU4FgmAt4eqmMbqQOFM FkH9mFXyv4hHBkp+w8/99FPIOcwrPguE8bf4zisPJJREBl5wMIFz9Moac/uL eaEYMLrYikgKBmLqnDKskUeEBfI9niIoUOKsoShUKegInrFQOiz9fSy26fd8 4pBScPo9xQoFU5kOBoGXekLFSrxC2wy5f4CEkkwQmh2kQBXFUkl3EZIyMkX0 EVNSnCI6iSklkcJdxIoyudlsuU91i+r+ACfFZN250sFEgeiv6s7NEItBWlTW jofEnBZT9Zf2l3JI6UiwWycVkwuYFNH1U7AVRC0Sk03kFpKlg5ASDcoGchmZ FGH5OpuoZMtCDwACBgfS2+NjE3cOjcN82R6f3LMbZdH2+NTu7dPju4fvACkk fuydoJ/hzn4+KuYKYM6NxyeHdozS50Cn+MG5g/xzz+jw+NDYLtLcUWtHRTgY DIMUie+e3kmSakpoxEEAhD4cAmj07tFhaHIqPgwfIQ2F3oJsGfYNd07snoCy d+4Z3QEl7xwZ2wPF7tw2jnjeObxzDxS4c3ziDmCdO7ePbd8NEv3Okd279/T1 dN4JPR0Gjf7OKcSzFwph4wFZv1BsIh4xradxjpe6Awtxm4xYsMuIBZ6sUZ5U C/GF2dI8JqVTc+kiiItgFCZ/sBvFxWypTzLiAgg3+NaD32JSlOQLmEHwJVWE WZQGDpvfMmhU85CGxy+hABQrlUl4SEZdAIm1Pw0zMRTEHCHIgQl9kmsXWBUM RiTTLsSLoP/TNONmpTRifoX+ZpAAWGkYK41ApSKpT/IvYDZXlJmwuyHsLqdl M6AWSrYGci0AxYPE0yTTqeNCPEQ9C+JoJxgC4dbbvZAQu1XWTRcSGnshFDAD DpXc9cBvU8DBT5t8g9+zuFWLKhon4tg6bq565Y4O0/BotC+qiJaI4+kO5kEi iTwJIWpiRAKRNC+TsG8iKSmTcG6KJCZ3tEfWPZM9QNVDJwISTSE0Sthkd0Q2 uZAUfe0J8KRekGdaQC9PcR7pFgNNYNf2sXHUnfbsgqkxOjy9e889tBSWDs/P 5jE+HGaExXxid3z77vHx3XehEBAAZltIpg8ls5AnHMA8E6N3D6OYoD/4HcQ5 RkOD7yBGhvfQJMVld8+uOyZ241xGSExK+Lp7zyiJj+K8QDSm0RAJvdwg/QoH uHrxK+hZKKWTzBPhEKgEgYUSMwUvFPg7kcyau3xOSufKdBbIrIEbvVmVkxlE Jsq8zCj9ql2BR8ijpuc0TtdSsCe0kC/EMeRWXzCM0yIcGZjlfQt+SWbzJeDU ME6GcDd+YtzgG+2KgmGc+uEYfmIM4dPBYqaMxXokgpCWySfLsJ8L45yPBDC/ ZGf4CPrGLHyM4HSPhOhjt0Jif7pMtAtGEMMIYShliSgrPyv5Acmw90zD4gd1 qgmQL/DeH1KxRxHqkZQg2F3BE8EIdioSE/0N6A7P5xfwK3YhSl2QwgVrxskW jGIPotQDKVSoJG1Ig1HsQJQ6IAUJfJ0/kMoA+lFEKUoo8UpJRefFR8QoShjx iimHQHxGlLoJJV4+iTKH5wVW3YhVN2HFS6kszd8Rr27CS05o+D5bOpxLwkfE q5vwkjMbhzOXAKmA5OhG1LoRNTHLZWk8TMIjlmAP4dXdozmH91Q9iFZPiEqy NBCfKzmZobMn3K0HOo1piGsP4drTrUduHga1BzHtIUxjAY1IkStDPHuIhDHN xbCwJNP4sTPWbVImu4AVIvoxQj+mORn4kVajYAzxjxFZezUvFyryM2IaI0x7 NTfPg2YVjCGmMcK0V3MyDKb4ipjGCFM8tsTP93kwQyqdFRno3kJMooBm7gLI o75gL2LVKyZRQPN2qoIk6kWcesUUCmrWLiTKc3heBxkQs95ukUFzN/Yok4fP iFqvQC2oGRwrp+ndS2dqPL01i+OhS56OV4P4XQw5rMGmAJAiMgSbGsgTYRFh igEjSyeIVT2IYomG9CgWFdiHpdIohZ7Qi2IeJNMs7D1CuPeIzabkuVt6AeMk 9iFOuKYX1W+5xouC4qa7x5ObFfeiUY8474H6QKT2hh6IPwBKNh5OIi2CqN5A AuwRRCvyhCkURFIEUbcBDXmmjyXrA/FsQnxlefpAPJc+hAlElRhL1AeEvIFU KUYfiBeAMij8u7kdodFFpKx8gC/dpJB8ADcDhdKDeoP2AO4zOCXGlc5lDibK dBvHtcKKJxKiXOtMIpcqACZovRHE7eQDmKKUqgeU3okiD1SABwz9TwozSANZ 8wDU0o214BZTJEhxBlSgWoNCgsUg4WACaIo6WFQcbIs6RAoIMUrJzZaKC0Ql Fl1Yj0qKcNupYiKDYSJRG+4JcV1l2GTmyzD63bGYrv4B3OBA75XyQmMvWCLm ET2fRjKUQrEHZuTQ8b4WEuSY8GDPaGaQwz2jGYCHekYNghzqGTUKcrBn5ODy YPcLXAixIHDobCadTZUQNVCt3rdz7C5Sdt4HyhKd37xv19Ddk1PvB13nfbvG JhAKd75vePfeCTyred/2sT1TeMz0vvEh+NsNCeNDO2Af8r6p6T17x2DTFet8 H25BevEUULQkGo7h1X0FT/pwQkDjvXT8nIGtaq4yLw9ExG8+j+bD54xmTj55 zmjm5IPnjJMukOKgC+BDU28a52EpEnggQ+K5L0SWS7C7kMoOfAC2oA9ybDLx B0gxCpGyLJOERhRSdxGYlkjh/VhIn30/QOijDIC9C/CznpTwoQTqCnzA6Uyb ECYRJau5moFVUGAjZ2uGiMhpUdm2ZFM1Y0E/ptlVTsyg3ZW4LSiDuk50AJnE h9JlVNJkkugxpM1XDulU0WmRelClypNllD+g82Mj3XT+Hn+gTOj1CDnFVxkP zOSxtz3yLD5O1j7GKf5sMZ2OF8s5rAgvR+n3bAVmciiEAjQcoMWCqqNvieJ+ zShYvixMakAnxz0fdhtU+lK0OwWTAj4CTmEchRDjBMniqo8UXqnRQmo2M4+J jBkk4JGUmIYx/Mm7NlhVIyJBHRbDUipSxHDQVMRkQJOSk4nkXNpQzCFpHmmH k5w5g5BNI1YoR0HhphWyV+EGMkF+lywByWT/0Sv5QSEg+yeZQn2QXWRprtJx 6aD0aMiWXgG2JoOkNPBeMQnEz2b25+bTuPnggwSxz4ZtgNMIpRLspgM9XDrl 9rLfk4J+03DBrojWvWlcA0vhkBKWPCOhc7AC028xQig8c6aohAGSeAumnIkf lAlM6Bk6BkAOiCFVFbVn4nI1QRLH+mfkaQhyLiA8w3c4yLjqcH9eoh4MeWA3 I5gfTasiAfgJKqjSJOgnIAL7HDww5Q5gKijFEUafMvFyIPDHlHSxmC/qy3NM omt9hTqmzGay2aC+P6ck29ouM6UBCbq/FMQf2z08iXaWqHmEez1JjGGcfgB6 EUEDzUjyAbMT+Iv6II9hHzCxh190IakEISTQ/l9J46RSOOQx7AN0a4I7rBBu 5YCO6kD2AYVuJKLtqag74qJH4FoqILJRQrZgQ7bgQLZgQ7YgiKiRRY02FTSQ pYSQgWzBRFbhWXAQGhMk4t3q+kFoVHT/gNtekBu49MKushKJMOcA/QnzQL8c hZAwh4qG+lVfoaucRGIdpmkmn6Oq8K6ru5SXFlYs1PO0p4NsSomFpINFvFvu ZS0WEhwrK6bYV1ZIcayskOJYWSHFPoUgAXkX2lazSNSMvVWWHZCEveNs0W6h WGdy8YKyMYUf0pQxIn9gl3GiTeElYQj23hUC4zPwg+5t4zPBPpIcgEh8JoRw TMBhQrFb/IjQRR6K735BMqrlINQSoloOBtWFevxgCG8GBYYyM+HC1O5XN8J8 OQ9LG9osh2nJBcQdN/TcSVVpSfYNuiZXYEh6MF0EvSEaUfI0pM13YPco5isZ OmXmi7A0Z8sZVQvbgxeFNdAs7mx15f2eeHwhEadzzHKk1zMLOzJhi0UHbeVQ VJjwiZMlYZin1gVhd6LWFcE5cbnQ0QoZpzsptT72k7kXrhSALpodBObsRgdz uJhAhWiIwQ3MEUFs1/xzaBiwvzynmFPkEd3oNo66cmnZGB5sdefsjeWqG8tV N5ZDGxXz9hytTLhWslQo2GstVNdaYNMUreCU0sUFUQcaVwFr2OsoVddREoyi Jqi2dpGIzYr7zxBaPYW7s0I1iQlGy8YPzqXRMjDGjJZF3bJY1vYQcdMiAr6i KbY6bc6iLa4+bM6SjhHS5lT94spJSOVZebcKmHhmS3OJIu6DyaRqVp7AMVqz 8VQ6d1ghNRs3bvj6uayoKewpJEqlg7iR6o5g/woHHWQ/GOccSg+EpIpxRwg/ 9xt9gp94IqMVdEhI5udJj9H2QlgoncwLI5ZeWS2er2k1HBJKc+ksLSX6ZpCr AnxJ30ZbpEJZoZuM2zc3SaQMfebVKT6D2wc9uqXM/niinJ/PJIV1Jfwmo8NQ N6hikRKsSlmyk5QGJpTAu/+AqiItuY5sfighnsuXM7OH1fQWiShSu2NQM//G y7m8I48oSHo5rkFQAHXzHkM371cyDPML00NAWIoKkUyLrpzJ9qrxYCczg3aY hqKsi4VM+yFI5R1ljzD7K2XsWMNvumUIKqRwccrpaRnn+6Ge0EAlSHbLyOU9 0mIW3/SgBQH8jePsg80IWmpRRuIrabfMtUShllA8fiCDnNHTTfbOFTOjpofD rDmZxXaFHQPfBKtCuCWslLTZH18MK1smtnHAz71ikQoSwnRLCrXGRK1i0eqV tZaLiQJRQtZaSGpe5DrjQpiHeujhQFyfkcXFqh+uss4GJaMvRJZYSKRZqRvK NqEr8wW6ZwqJAiB0kgmgFh1ooVliPAdJtLfj7ZTqB++jqAxliAXV4ijkFBro xcXOGpCOSVkF1Yq76WhE2MTjePZjgwRINhLmr0HPgbjmq1gYT3DeNFvFImjG JFlHmHW5s06s22SdWM+Fsk4sdjFYJ9b7llmnN3BBrNMbFDS6GJwju0dDLxYu NdY0+LEw8oI8xu1FXTBQkgeveGQOacqYTxzsxKgfsCpgkjiu6MWde6/YufPa UHqAzPZYNusjGm5MPAWC3WRK2AWE0ARqMj45hta18BeBIAI7AAgBMAV/w/B3 GP5G4O9e+BuFv/i9G/4OjY/39cDf8buwaKyzn6sWDXXDrzzuoHp7oJndk/GR se1o+ofg0AQ1BdBuvPJE4G6AwlRFviAq6EGNKEn21qHeGOp0eHkIPe+R+lCW uxLqVYaKmKYX5njRyMGrM6ZpjaNfNiLajHlKBdIFentpz0MqWEGrT6BwHUwV 9OqK1p2lcnJuv2oTUvB8TioD+DNxSLcHvw8mijltSlPi2y1tSgMp6UNoSqlt aUoFaams1IC9YxPTEXocBewp5Eg4QMeOCbwAlPMgX8QzED03S/P8kxVe/sXa LvyaS+nzgIrKzcjO6gSBa0XXLw2xjBSB64F0ugCKju3YEHWkSnkuTia1YTJc CwlhJ7ZVmZTcVLFCLvcxC+lkOV/sCweU2I32i0MbnGripU7AeFcXlJbo/Z6h vdM74ztH9sAmJBD0pDLJMr/WCQdgtY3EhBlvIKpN+UP8jkUIRdUh1uK5M3un 9tyZzqXyxalCOpmZzST71D0uTekwGrKFA+oOo98zMjY8HR+aniZMIgIT0QSg 0oN2WoiXRIdxUD+ljbhEiu8suK0YttWjbZiorTuHxveOYmM9HioF+keG+o0n 5L0hR0tKN3oTPc7yKxDZ2VK5KFLCQWnnHgr3AmFxoQQeCjDeeD0F6HSGwvKq g3COTw6NEZV6PcQutB8N4xFetDtDLz2lSUMlVZAbXnEWITgogiwkGSuKG0fN QJ3i5UJ/KZ0s4tuGgDggwiRop4Lvc8J4DxYO9MruJecy2RStrOo2XryXoVVD XkJxl0BA460h370z/+0ZfR++Cw3BtAUpsT3ogaUk2Vegvwt9he5eTylB9uue YrqEy0oQE/KwBvX1RAFEswAYGYRRyqCdVCgKC8pCAX7gdVZ3wJMVhCCSIcXC aDGFbWIbeDDlwWqpF7CbyJWosURqNgW7QmiOF3N0DVBMJxf6tkN52l73FaIe RedCr2emMjubLvYVwsEYnm17eKpCZ3AJglTCAIBeJGLQU86XQVZR5wweI1in 9oXxtgTnBfAOXpOF9UvvcH/IIznMQ3dZgpNhmDx0fkuATDG67xnLxYf43MIz PY6PvcKif6UCPijEceDcBcwurA1AmygQGfDe/mAuTqO/ZF58h8EtIj4ShmRh 0+RhxpLGqngoDR2Usgxf74c8BpPR5iyJz4krBWi4Vw8OaXdme4gm7lOTc4kc 7D4xc000ccIrMiXn0rCrzpTT8/Qzlz6I1ajP+WzK9huaxN8EV0rpYpzK65/F dCF7WAwEbmf30zRSb/GD2EE1sBFzYLFW4ChIjpqZM0gFmqGCRwTFum0Uw+fY IdAydo1O7IUZNjl+T3z35PQYWTwaaaO7JqfRqstI2jk6Ponm8Eamu8fIHF6n 3Dm6ZwrrQpNKpDKSNY0viVD/X4obliIziTP1a2lCKklgUjTmStFeG10ykl7q 1b1Ir4jEoD0RG8UPoQC0WKZrAJrI8Ht7EbqSmsSDoWQ+u0cwMRppe3alc5U9 NIvQdMszMQRK4xTd2HiGQWakc7vpGBl+7sH+7EqXSuJwhEpO4R5qSiAPSSNp UqXxC7Q1T6caHuMXLCL0cywH2GVSU+lsmg8IRProoUzZaGEv9EjhhmW3CYGF 4J2J7KQcmj3DU3vSC5kS1wRIp4D6H4C6q4YX6VOAPOYwSyHnJp09crzCIdt4 GQxNUlGdOyrRKT6acovwgumNInR/uiZqYl+6PJK0bDixDL89WBYO4vOhpebG yogWqYVOVYt4/FeoHi8xiQo4yksOna177kjJLtMOx+i/glH5jNsJI+aleNup Vy7ZvUDtPlVymUMkzrFHpJ8h6nwOSSD8DaOlZKg74knnkoWDyLoAFA8XYGaK ssgNIiNqBr29HlAjklKEbA9KRApyqVZkS2YzMIdnsSResEe75VofDscMoRGU ohnSe7Ush2RUF3Ig2yJ2wUNyJ2KXOyYJpE7nSaVnKvvF4g544mABJmJpLwgJ mRBTIJvfj6ciCMoBhr8Cc4V0xL7AyhfcYY94NRoncwOkB6VGSOfr8eCmkDZi CZIx24OmmCYsjK+gGsGvam2kDHph1FN+EP50o/wWOzvSIgAkrQCK2nJBOlp/ on4YNX6IQ1jSCGaB07JCH8jsRz7GxDmpIoikuXI+l+2bjXriZMMwGfVsrpSK m0mV3JzNzGzen0xuwr+wtBeTm0qV3KZSPpsoZkqhru7Noa6erlBXeHMml8xW UunNpcOlzTOHy2nY3KWLXXNUe6lvtlfWHvHkyvk5e3uYYs+D6mScB2VHWN29 RgK9ghFgHhtfcWe+n3h/BzJyPnkAhnUHTNpksiwgwSW0M4ZfQkmTvzAXKVE7 guzkig7XsSr4SV/lbz2McfZA0rcj6sFtOk5eI0monHJzMIUzBZednelsQS47 U7i4GAF2yTni+b93+b1K/qwT/hMvZ99iA/z7GuN7A/y9xePZhv4Gb/B6PF7h z3IYm2rn3yH4jb781vPvGPxGv3oB/q3+1Xs8fsfvesdvbG8L+3V8nds3v/sc vxsdv7G9Cfmbnd6+3/F7v+N32fH7QcfvDzl+/yTj57vccx5jjX/G8f0px+9f c+T/vOP7Fx2/v+T4/WWgP/qSPLRG9O8lx/ezjt9fd7T3T47v37L/rvM6fjc7 frc6fl/t+P1ex++bHb87Hb+BXy5Hfjsn+lM3YMdX+J008u92/N7r+H2v43fa 4+lDfnyd688DSyFPx/h3xZH/IcfvH3Tg81Fg8XMYy4PLP+bI/wswddDX6T7+ /qsez1UYV6vAv59z5P+y4/dpx+//BVP0CWD9FJf/iuP7ax7P5uPA7dP8/V89 nkGMAc/teVvs+Hsvt5f3XuP4bTnyw3j1AY94n+X6Yo78W8WvVU/w9xHH9zuA X9GP5TX8fcrx3TEfvQnH7znH77yQYa0exu+Djt8f8XgiLwK9Rri9j4OI+izG A+XfP+fo3y8D/2GcQ+YP7+cd33/P0f4fezxX4hz7Juf/C0f+c478IGO3oO/p Vzn/vzi+f9v+u77e8bvJ8dsxfvXXOX7f5Ph9q+N32PG71+MZQh+Vrwj86mH8 tqI/UKaXiP9o5L/b8Xuf4/e84/dhj+dGmMOXZLm+H3N8/0nbb+3fkbztsZs9 +4ondAqx0gsNQKzxzkVQ6EkVvHNKq9PN2UwupQ9d96fLnlm0sSeLTM9soYi+ 3ujxEOR1WZE989BGXFRSKYSUbkDH3/mkhyxloVymrDUk0Rwqdx4y5y8uzBym MkKD8MyKQrNoeEvaRzkPzcwn5wueAlnGQSLuMDERlEH6VjgMyFYAb316ZKgX ntnZbKU056F7Og/p4p5MDvRIoFNCK/VCffWId6keeu9m6DLGFgrxjgul2FCJ HWc94lAiSUdKoLB4uiqpzIIHDdZB/ZGneGJMiH72faRDzWU9i/5AlxfSRdwW myqTuYnw0LjN0mGmB/BJ5GalLop7nyzStVxEguKfuSL9ARIaqp6pFJpbOXMb bqh2zuM4p5pGewTiKePoTCmDnvlUNI74y32DZwYpQgOAd6LEJwXgEQQKBxFA 9GaL+XnmUegf/43HM/kZQ6U3NxPYzxx3O4cdhuqwkfxsKnEYLatof4Ss6DxQ Am4sHvAQRwrfzNdKPQDWh2tXMwxyIiLTYV2IyPTbPJ73NWt3te+T6SAHhmX6 uMfT0sx+sUHGtKxmeJr1R/bXfqvMfx/nPyTyUf5Dwj/xrTJ/FpqQ+QsAy3TQ 6UJS1zzi8bxH5gG59x6Z5xEjz3Ejz2NGnseNPE8aeZ4y8jxt5HnWyHPSyPOC keeUkeeMkedlI8+rRp5zRp7XjDzfNPJ8S+dBdV/mQf/fezkP6nF7ZZ61Rp4b YLhlHhjr1TLPeqY/0Kmunen/iNDn9smyQP+ghKFflzWL2AkYS+Gy1QzDf5fV Cz0BY6AhjHFWUI9R8Ouc57iI+6fSv2nA39IwqqwK9hlwkwGvNuBWA17Lbb0q dCGVfoMBWwa83oDbDbiT4Z0ivpZKjxhwjOG7RfwclT7I8JyIxyVpiLF05HxB PUjOC+8TRp6n9BzBeFxyLnjf0HlQpZBjWu/TY4q6BY3pkyL+M43pkyKWjhxT 7I+cyxgnR85l7MM2mWdOy4H6gpYD2DeFA4zleyUMON8gYdDNkhL+spF+hnHD GDsvM24Iv8Lp0Nf6s5z+jIi3c6NfhwGQ8gpj7ySahdzyQX8TqxlezfVgLJ1W rgfhtVq++YAOcVnneo2bD3h3SMJAk0HZFsixQVl22ki/20if43bPiZg/1C7C QLebZZ0PGW2B/Nkg4ZNGnS8adcJcu0fmeY3r/6aIBUT1I/yGrh+30bJ+jEct +4KxrS2uH2NTW1x/w91G+n1Gela0hXFZMMY0tkVw2WjriNHW47ovGONY1fll o84zui8Nr3P9MA4YC5jqR/ibun6M2yvrx/i8kg8xJq/kw0YY74zMc5vmDYxF K3kD42NL3mjcye22i1jZ1C7Ck5o3MOas5I3GfQYOxthhrEY5Xo1P6fHCOIay 740v6L5jPMHrZdlvMg6DIoY24QCwH/r7Ac6DMeCukXBEl/Ub6y/GLJVz1g/4 3ynTpzVN/DCmd8o8+4w8KSO9rOmG8cgk3TDumKQbxheTdMP4YpJu/kc03fyP arph/C9JK4zRrdp9wmj3s5pWGEtL0grjZKn+GrzkN3gJY3RL+vtf0fTHeN2q 7Dkjz+s6T9NqzatNa3WepmuMPO1GeqeRbsz9JmPuYxxviWfTIY0nxotR6Y8a 6Ubfm4y+NwHOtzBuzcAPmzhPM8y9TZwH41O8R+bp1Phg7G6JT/OgkT5ipN9n pO8z0h810h8z0mFeT8h0GMcJmQ48/32MQ4tP52lp0nlaYJ7eJvPcoOvHmN6y /hag80aZZ6fub8u47m/LPk2rlpSmVYtB8xaD5i1HjfTjRvpJI93gpZZTBv5n DPzP6j6uiuk8q27TeTAeuOzjKkPGYoxfWf+q+3QfVz2k+4ixf2UfVwFu18k8 r+j5iLG+5Xxc9aqejxj3m+YjtLnqNZ6PCL+u5+OqN/R8XG2sCxgbXMrS1SNa lq4G2m6WeR7h+veJuN9UP8JAz1GZB3BoZ/iSRQN+Q8OXguxaI+FJ3e6l07rd S1PcFtRx6Ry3hXBBt3XpUaPscaPsE1wW6Hfpk1wW4WeMsl/WtL30nKbtpa9p 2l76uqbtpW9o2l76TU3bS7+laYuhaSRtUf+VtL0M+Hxcwsc1HS57ittC/fRp bgthwLOH87Su1vlb23X+1k6dvzVi5D+kadL6kKZJ61HGH/raepzxR3hR06QV 8FnL8OX79JpyeUqvKZdDnXtkHqhnTsJQtlfCIJ9jDGNYufdLGHD1cZ1r1gqd jOBDRvqHjXTAeVqWfVzjtuYJI/+TRv5TRv5XdP4rgJ/3S3ifoAPuFa5ICToQ PKd14CsAn7sl/Iiu84rjRp3MD6j7X8H8gDCGnJH1rG3V9ayF8bpXwg9pfNY+ xvWAbFj7ONeD8KJRz9NGPSc1Pmu/rPG50qDtlddomlwZ0Ov+lXfrdq8sc7vQ vysPcbsIP6TbvfJR3e6VT+mxvvIZzdtXAh36Gb7Kp/ebVzXp/eZVq/V+86pO ve5fFdHr/lU79fp11aTuy1XTui9XPa556epp3ZerWVbgfuhqlhUEZ3Vfrn5I 9+XqRzUNr17U6/7VBv9fDbQdkPBruq1rfNwWzJ1rmrgthFfrtq65Qbd1DdB/ UsKDut1rpnW71+zT7V57g27r2ohoqx7G9tqYaIvg23Rb147rtq7dp9u6tqDb uvYhAzb4+VpDP7/2SY3DdYMah+vuZhwg7br7GAeE92kcritoHK77sMbhuuO6 resWDfgpAz6pcbjO4OfreC2rB968jtcygkEm3855rm/VeF7fzvlh/by+k/Mj HNB4Xj+o8bx+WuN5fUrjc71Bt+sNul1/VON5vSGLrgc+G5PwGS2rrzfWuxsA l7skvN5IBzmWkvALui838J63HmhzA+95CX5V9+WGN3Rf3tOk+/KeazTO71lv wAEDHtF9ec+k7st7Chq39xw14Cc1/u85qdPfC/RMSxjm71U8Z987LuY8wfcZ 6SkjHebpVlkWeKZVwk/ovrz3GaYDjPl7n2U6IHxS0+G9pzQd3gs8E5XwN3V/ b/QZcKsBr9d0uDGg6XAjyxMfrPs3sjwhuMDpMBdvLHM6wg9xOtDgxiOcjjDr Sz6YKzeyvkTwcU6H+m58jNMBtlo1L1kxzQ8W7099MA4W708JntR0sPZpOlgG D1sf1n20juo+WjAHRyT8ZaOtV7ktoKt1jttC+DWjrW/pttat1m2ts3Rb6zp1 W+vGtSxdl9VtrfuwaAvPJ9Y9Itoi+FHd1rrHjbae1ryxzlgH150x2j2r2237 spYVNzVp2t7EsqIBxvwmlhUEG7LippTm85te1WXXj2hdbj3rVA0wVutZpyIY 8LxD5vky54G5sv4U50H4jMZt/ev6vG79G/q87mY+s8Izm5v5zIrgtbrszQHO A7xwc4TzIBwz8vAZFJ7r3MxnUAQXjDyA89USPqPH6GY+X2oA/rqZz5cI/qam 1S1NeoxukfgAbW6R+CBsrFm3gOzdIuEjekxvgTVit4Sf1uN7ywt6fG85pcf3 ltd0ng1NBgxzc0bCrF814Lka61cEv8Dp0M6GFzkd4VMaz/Zv6bHuMOZmR0Tz RsekkZ7ScrIDZMJ6CT+t82/s5HZfBjjA7SIc0WOxke9KGmD+beS7EoKnRXoj yPiNd4t0gvdpem405v5GY+5vNOb+xqf02rrxab22bvysgQPwQIDhW5t0+q1l DXf69Nh1RjQOndN6HDuNtbXzkMan88Man05Dz+983IBhjHbxvOiEMdrF82JT p6bnJoP+m4y1qWu1Tu+6RtfTdYOup8sYx65JPXZdc0Z6wShbNso+qvvS9aSG N/v0/mtzk95/bY7offTmnXp+bZZjCrJzsxxThFN6X7YZaHWThJ/U+Gx+SuOz +VWNc8CQdYFDRrqhqwROaTi4VucJ7jPSs7qtYEG3FXzEyP+EplvwWSPdGLug MXbBs5pWwW9pOHS3plvoPk230COabqHHNd1CTzLdgJahp5huCBt7/NDLmm6h NzQ+oW9qfMIBjXP4bt33sOw70CYs+46wQc/wUd338JNG+tNG2c8aZQ1dN/yK hiMx3ffIbbrvkTnd94ixZ4ywXtGIdy+sVxD8mO575Bnd98gruu+Rs7rv0Ws0 ztFOjUM0oHGI3qdxiBY0DlHWeRqhzSjrPAQ/qnGIntTnFdEX9HlF9Mv6vKLb mIPdxrzrPqvHosfI0/OUhmPX6Dyxh4z0l43013XfY2/ovvc26fy9nXoce0eM 9Lt12d77jLIFPXa9hhzo/ZameR/ImfslzHuoRqBHH++hCN6nZWkf8NV9Egae 6ZLwizpP/2p999ffynXC9/61XCfC1+g7wf4bOA/M9X6L8yC8Xq9x/bzHxLuI ft5jEgx82Cbz3K3Px/r36fOx/pQ+H+tnHaMRxq2fdQyCC/p8rL+sz8f6YS5f IeGzWmfof1XrDP2w5u3gPLdBWreEYYzWSfg+Tf/bPqz587bjeu2+7Skj/VnR lh/G/7aToi2CX9Q0ue1lrc/c9rquf8BYUwYsXf/AoOaZgbs1Lw1kjTzGWjxg 7LsHXtDzbuBFPe8GXmY8YS4OvMJ4Igz06ZBlgZ+vlPC3OH9MmNBSfoSbdP4t N+hx3GLpcdyyXo/jFtaN8R5pC+vGBAf0OG6J6HHcMqjPgrbcp/lzyz7Nn1tS mj+3zGn+3ML3iX4Y6y18n0hwWY/FFt4j4N3RFt4jEPyo5s8tTxr9etro12eN fvFeEu+dtvBekuCTRr9eMPr1ij5r2gI8EGYYzR+pHujLVh/Xg/BqXXbrNZo/ t8Y4P4zn1ts4P8JAt8tlHmOPvHWf3iNvzRrpjxnpj3OdgNfWRa4T4SeMOqFf U7Is9GtKlj1lpH9Lpw8+pc/DB1/U9Bz8sqbn4ClNz8Ez+jx88GV9Hj74iqbn 4FlNk8HXNJ8M8l1nE/DmIN91Ijzk0fNlCPSiWQk/qukwdFTTYeizRp5XdL+G zup+Db1upH9Tp29DO1cuu21On0luy+ozyW0PGelHjPRH9FnutqOaVtuOa1pt e0zTahuPF94lbuPxIvgJTattT2labfusUc8zRj3At50yz4uannQvJe1I2b5F 2m5JGO18LpFwO8NA80tg3m3n9Ksgz20MYzjvjQzfgGf+DFuA216G18GYxhju APkwx3AU8kwyHAPctzDcB32PMnwb0H83w4NQf4DhIaDVCMPDIP97GB6B9KCE UT4zPAo0STK8HcZlK8M7YY2YYXgM5M97GL4d6L5TwtOCPvi+4fasAT8pYLS/ uZ1tk/DNwx1sz4PvG8bxvJ3rGUcbKgmzjdDwI55Eqc+6K188MDWXL1jDInJ5 sWRFuu62UukFKxizptIFK9jb293i2TE83Ge175jY22HxGxjPBfyr89jfUqA9 77zju4fffiAs3008QXjqf/J9xeWcj98GjEDfm4JGPmmjfK297XG03R51yXcj wzIfyGjPGy7trjffq4h84/h+wG/kw7mw0d7fx2Du33GXS3/D3Afux6tAl0Zs m3VSqg//9nN9nO9rrwr7par6hrkM5/v6IXFuQn3zGvhN2PLVrW3n9CZpO86/ 73HkA/zqHuV8jUa+lI0udVeexEnjgt+79n//juz/ujajHXlX3nMR/wWCgUB3 JOIJiH/0N6h+h3siQYAhQyQU7e6OhiE9GIx0Rz0Bzzvwr4Ie/aDJYj5ffkud xH8R0blAsMfzPfLvQ6Pj2+u8tqnttc/1215R0h42IJ5L4VtXaa5ULpYTM56u cvpQ2dNVzOP7YE+X+N+ZUgmy0Gf8X8gKwOF5ThDliulsQhZGUJQkUJRkT4DY 6Ke/euIRXCxOw5Q5veHEa6f8J1478hnLs+YIvR/0tB7xrMG/ZyD9JfjvZfjv Cvh9dM0+z2mAz3gXrZe8Z9e/XG+1D3LnsA6orxPraz1x/jVMk2VknqdbLayb qPMDXzrb9APnEJfn2k9ueO7Ro/7nHrsSb23hv2NrznqgDVqoPnmFpcofgzxH Wz3NV1KeRZV+yt6HSzEN83wS8kscsK5jUBfWq/HZer71SN1xhE9ueP4JWf+x 1nXUd5nPTpu6H8S/p/3PP3HUu6/uWKun6TSUPXXZc499fKN1zcf69l0D+W/y HvG0Em72dA+kt7ikt3g17cXfE+f/zK3Px1utFgdejQgfbbXqTgEdoXy96M9z j7qUbTbLQptNYuyeexR+1xk4PEd1Qvnj/hNPftJ/Yu4x/4n2T/mffxJveo61 ahpCOZ/XoLmktzmOLwGtHDTvEX07MYf4GXXd2HThda0X9DzRLukp+3uqBcay xfIdbdl33skbK6z7EpM+a3jsjgItjvufOy7LyjJANz/3q93sF4zL8WNAOzfe ZbwaeMyOQh1RUceS+c0xxzLtF1DGy2Wuv4Ay9VzmAunHfNRqBdQcFvNl8chn 9mH9lyxVn6OuX5Y8c8r//KKWO88vnoaxON1mWQwfBXg9w48C3I4w1n/Gu89z ps3qvFzM30X4hmP2aI151uCgxQ/a58Tz52BOzH0KxvrtmROeIo/Hubc+Jzzx t29+ecYv3vySvF49X4Bndjp45vE3wTPvkTQFHnhcfoOxfxxkt4X0Mfjoceaj QYQNfhlhfnmc+OXEtw/K9W7pde3EI69vWBxZZp1tNdZO4N/FkSOfGWyS8uB1 SG+V64V9ff36W2z3clUntOkmi5Zo++/eYttXyDqPQZ9x3C8AhxHG4W+Xw+Ef NizuXAaPqw0a7HS0v8poc3AF4yLx+utaeK3fmU6k0sU+y3CskVwooZZMKeli sSS2DsnOBSvYFcUjhp7NgeDmcNAKBfvCvX2RoLVwoJgpzeUS1uihgrWebvpL zc13kqsYK3Do5kPN0+h8z7o51Vztdw9SWyD/5ptLuDnNkDOkRPGw0EqLrJ3e XOqzhvOVbCq3oWzhy0JL54QaSi0eedI3vWdsW3xi17D5e+/0qKpH/J/HqJc9 MVnKn5uVz1nZTC4NmFn5WaOlFlt+fPtoCXc7S5Sobodc6CxT4uZDopxwvuPx oHv6/ekiO5fxeOhZsqNedOqzHCKYP18p47f59HxepZOnQlc8QTkvHr6g/mk6 rpA4eADRflOHYLNmZLJhjOeQ2T9XRnYLWeOZBaBCqQwVjaKf/gKwW7oEDSb1 QQX6cliLh75NKV3tegPedJux2Tmi4e8z4IIB/5QBP23A/0PDqHop+E4DLhvw Jw34Nwz4Dw34Lw34DQ17LzHgPgPea8APGPDHDfjnblFnS96nbhHnVwj/9hHy u0LwGYDbGP7zI+q8zXsO4BP8lm5Q11m/H+B1DB820hcBvkm+zwN4A8O/dURc ICH8xSP0nle81dNt1f/pEeVnpf6rALOPjvpvHKG3vQT/K8Ds28GHD4VmGF4L cI5hC2A+3/BtAvggwwMAP8zwBMDfz3Ac4I8wjDTks0vfDwH8owx/4ojcEXt8 Lx6hd8oE/5vuV0PzEXGRg/CVR9RZWgMa7w0xvPGIOO9DuFvToWFI06HhdoB3 MIzjy75LGhDPMYY/APDtDFcA5nPKhu/X9Gn4iKZPA/IDz5GGnz8izv4Q/q96 7Bp+H2D2Y9LwPwH+EX5Dhv1ifwuNyHsfZXgHwD/BMPL8T8p3bAAfZTh/hN6C EvyrR+gtM8Hf0HzViDR8kd9O4UO/P2L4iiPKL43/vQD/KcMdAL/CcAjgv2F4 C8BfY3gM4L+Vb9SO0BtngpGGf8dw9ojwa4PwQYC/wfAPHlH+bfw/DvA/M4w8 8P8Y/lmA/43h/wQw+9/w/zrA5xn+whF1rOJ/AWD5VuyPjtD7RoK/ounfvBrS r2LYMtJ/5Yjyh9N80kj/+hHlF6elTqe39EL6JobfZ6QDP9RFGf5ZIx3mfh2L xJa/PqJ85bT8A8A8H1u+BTD7XFkF866O/XesgnlXdz/DwOd1zGOrgM/rmMdW RY6Q/xzxngngWYZHAT7GMOBZ9zPyDRPAjzMMcqbu0wyDTK77WYYf1PivOg7p P8fwp43039fw6gYD3mLA8wD/JsMPAfwFhh818vzuEeUPaTXKqL9i+FWd55If 1PLzko8eEXcOCP+0kedFPfcv+WOdfukPGPApfKjF8P/U6Zd91IC/fYT8G9Db mlU6vRVwqKuT73KMdJDhdbzCtv5fnX75zxyhd7AE/7JOX5OGdJbba4rrlfwh YWXCY/KOBeA7DHic7z8QnqAzRAG/z8N4A7zHI/w0IIx8Nccwfj/EMPpk+rAd XoO0Gjt//jzN55PGPQ8PEOb56Hol36isCacNPIsGXJH3SgAveHhdHBG43M0w +vB6iOGHPbxOjIh15FGGkYzPMPxDHpZrAP+wh2k9QmsK3okQ/OPSN9UI1VE3 yTDI0jrZLsyRuvsY/pSH5wbAn5Z+nwBeFPcdBP+SuNcg+Enpmwng/yLuCwj+ VYBlu08DXGb4NwB+jOHPCx8BBIPc9n6W4ecAlu1+EXUHhn9b+i0aId8UCv5d 4ReA4C+JtyYEvyh8BBD8ewBL3H5f+A8i+MvCXwDB/0P4BSD4D4VtKcGnxJsM gk8DLHH+Y+EjgOCXhI8Agv+n8AVA8J+JN/8EnxXv/An+inirTzB89wUY/j8A DzL8V+LdPsHnxPt8goE3fSmGYa3xSdrCWuOTeMJa45P8848AP80wrDW+swz/ C6zDEh9YUxqYbjjHG5g/63zCLptgv3hXTzDaPTF98L6ugXmm7jKAn2T4cvFO nuC14j08wVeJ9/AEXytsgQm+AeAYw7AeNXJ/kZcbub91oBM2cn/rQB42ch9x nWo8zvAt4k07wRv47hThdgPuAJjnUV2XeN9O8GZha2bCaz4FRE0LmbDmSYBn AYY+rjkB8H6AQbas+ROA5wCGNtZ8DeDM+fPfPocnNAB/AGDIf8VVAB8AGHC7 AtffLMAwr65oB3geYLQti6Ceef78v8EcuQL1tDzA0K8r9gBcABj0nivuAbgI 8KNOGXWSdW0tr8QcEemCB0R6owlDH68AOSzX6Ct+aFHAPEfI1x3Lt7otWo7h O38FDwkbDoKHtXyrGzXqQZ1T8hLKBslLY3xXjDDqnAU7fAWsNXVbHDK5yZDJ mOcxwJ911Ct+eVHAst27DfzvMXC+14DvM/D/PgN/XENYjtXN6PWF9BBeX0gP 4fWF9JCyHb4C9iZ19yyBP+Y5AfjzEcQVpxYFLPEvGfiXDZwXDPiggf9hA/8P GjR/2KD59xs4f8ig+RG9Bkn4ilcA//IS+GOer64nn4OE/z8uChjwv+JbAP+E QcOfNPpylO0EED5mwB/3sD9PgD+BN6EMP2bwyacMnH/GwPlxvaaTXnfUDq+F vUbdUUdfVht9wTz4YJn3U2s3AryN4UG10IsDBM/m9CH07r95Lj+f3iyPpsRJ lofvwZOe/clkCCOaoR1NqgvPV/rKwYFisH9TKBjpicTC3ZFYvwJ7+j3JuUSx rxwaKIbQl3MIUrL53H6LCoaXKljJoY+0dEpkjQyQu9hNQS5v/xp1fNVNdNOX YMDtX3+gx+2fWYe9mR6qzF5FsEYdpTmgpSgWo26GQz3dsX78X/XVXnuv6ER3 NBqOUuQe/CLIFwxQFRiegkioCvLn4IBycYyR8hI4KCFMi0CqJ5WvzGTTkET0 jmESdU6lE3GD3fgBhzabPiQwwujisWKagsJyxEcMw6hi6cnMskkkdrdoU35S bSDtekTj8psdCaRSjLFYyGdSkNQ7EOwVPgn7piiONrsmhF/Sj3S0uz9khpvE MNjkCPnBtIjrWRV8MuweezJihGjm8JORlUWfjBfmDpcSFEd0GsNgRzAULqMX 6A/KQHk6V5kiV0c98WxiJp2lYhiPmsJz9OrwNSJsFYwV5yqHYh4ZBTEYxKkX o1SEoEfIaAiGQyKWX0VmCApYZOklWOTBoKfl+cQhnZ9/0Aegiv7AP+hDPJtO lIy2xW8DA5Fg4mEUCZopJk5mqQgxKP5HQxcYqMTiKRUIOp7tU/ELgv1hSadK 3FYoVF1IxwaKqkI4gyReNCsNjAiTiqwx6knKcLGhgCcl4bAnKbLGPAWZFkWX i1wrBb2UtEmlDwkwPzsrCmdyeVFiJnuAKwp7Zkv6VxR+AcupXxjwIjKQ3hbf PjQ+NdoX6NwWn96zdxS4ud8zk8+j10OqJILodEcIjlbTorua0Sq6QE91ARV0 oj8iC0AnOHpWOADkN36GyDu+gFKZ0gFFrIAnm5V978VGZvvCAW6k0BehUG4V FV0u6wziBrMhqygfCVZXEFq2ggMwncuMZ9QjhobCbpAPSTHm84kP5Hkg52GA GCwUMzx48fl8Ki0YJR9PpRdkckVUh6n7NZjDCPYyS0EyQz7OQ9/rOZA+LOaK rBb4RyK2XwKqFvSQv8AYyY8FdOCfSAns5Q+uNgISilPmK+X0ob7pCMYcjMTt yTLCc4Si6VV/6otEdbxsFWnPno9iRUWq4u7Z8lBA2QiGenf70h3pi/S4YEDx 52NVod9rtJE/mEsXoapwj8wmIhs784mYYT0U84yYw9EdIF5YUw8ZBIjXyzEW jVSmXTRgw1x96YtEnfSib0uTi7JIDGVkZnt5Cq+sCoiIZhSmOm5LLPSFQmoZ MtKJiYIO9uBaQrZa1Be3qtRHqi9kJxhXF7ZVJz+41Sa/UWVA/TxGGJ6OYnze kK4BU4kpoporabQxipmujLJhRRFPSeoEQfL5yqJbLqgMivkkcsjlLyeVLF4g 5PKgFgeciejUVcmSuC4R10XiskxcFoo/UIEeTGM4bFr9w0oU04dytFvFq5jG yNax8gL6upXSDX5VxE+pkGHuB/M5pBdqFOUHMR4hRro9mC4pfQdSUyVySWuo chnqsWiJGDxTFrG9MSnK0ygjY9VFNUNSDLQCYDGNQaerMcxVY4jZkVLdAfGz XKzI3wINri/oxKM74MCjO6BDlquSVFXQM1dUwwztzEN9IQzrWJ4nBCUt5ili o6QD/JzLV4oqRCJ+TiUOqyCJ+BsDGskgifD7cDpR1EESIeGgKMBBEjGHSOAY iZCQKaVEREQZz3EW5lCidIBWfliCNBynCJgY5RoaxE8zmXKprzuiwxQioYOB UETUgtnLRlhrjBL9PRTVurv77Qhq7RIdEyNTfw8Gx+yOXWhszO7emqExewLL RMbsjpmBMTHeNcfF7Am9zWExe8IDG3uCrkExe4K2mJgYC9sIidkTMiNiwq+l AmL2RKGViHs4zJ6ILRomBtKWwTBVGxclFmZPzxKhMHtigHF3jUCYPd1GHEwM l/1Ww2B29zqiYEKCMwhmLEAYXXgIzFgQCva6BcDs6ZXu7NGXOkXtQoaLhZAn tNt+EaOKov3EMC5y2JOqzM8fLmFWW+xAHDRKjZqpQG1K7DYTsSFK7TFTcVAp NWaLNZnJpeMYglqiJyJExXqRqWR0qV57iCvmQo9gE89YCThE8saQEfXSDIXQ tz0WMkJiFoz2ZC703K+yqYBgtmwcZAFy9SIWKpNAWeUR7fUyooWovUYjszA0 iiu8Sn1T3BR/oRowtbfq/VONmEfyHZqMeXQpp/XWVccUcotRdKV8t8UxiTYY 9TljFL2ZmEUDwm+s58Mc4+d24YtXxfxRb9s4GM/9jt8zjt8HHL+L4t6z8WWu zxHzhu4/zd8/6vh93PH7Z4R/Xc9DXN9/dnz/NcfvZxy/Tzh+/67j9x84fp/h n49ye2eBXtj+Y/z7NUf+Nxy/l455xMfLtgAkVezmzprLhhlJlPOZqqAhOj6I LRRIdTwP2zT0xONJnN0y+IWMe1EV76Jw2JRy5gSsEUxCRo2Q91/+Zv1+02/E fmho5jv2GMCrGR73eK6Vc2bO42mTbyuzALO/D7xfuErmeQymk6z/ca4T7x4X uc5HxLvUK2W7T3IevH94ivMg/LR+Y4/XD5QH6sD7bMqzKO701xoxFVplu68x nni3/zrjaQm+aWD/+OhDvYH94yP/tBrxFSy/fkd9qYQ/y2VPAfwMlz0l/M5K nyB47095zop3jpTnrLABkHnw3p/yvC7eCVKe18X7Sfk+H/2Dyr7gm0HZF+8+ 3RdvStRDz3jnRD0EZ3Vf0JZA9sV7VPvIRlsCVf+TRv1PGfU/zfUHhL0B1R8Q fjdV/SeN+qGf1zQLAuLbS/SXiTCK11YjVoFsC2MVyLbQJoHamhM2CdQWwmt1 W/U36LbwTSblf0zYJFD+x0Rso+uMGAaXSfghzr8o7BMa2Ndw/YeN+ARPcR6M l/A053lS2CqoPGc5z9PCVoHyIHzO8O+/lvM8I+INUB6EbzDyDGqaYOwBSRP0 KShpgvYMDezjGOMQNLCPY4xDIGniu0/TBG0bpG8I31Gj/uNG/Y8Z9fPcRJ71 8dwk+Amj/ieN+l/Q/lsx9oCUIb5vahmCS6NMbzBkS8MNoi18v9tgibYIbtfz Am0n5LzAWAVyXqAfOzmmGJ9A9gvjE8h+YXwC2S+0taC2kI8e4rZaRdwC2a+G R3S/Gp7Q86LhGaP+Z436Txr1v8D1Iw++yPXvFDEPWo2YB5YR8+B6I7aBrL+x SdePcQ5k/RjnQM67xrV63qHtR6sR/0DWjzEP5LzDmAdy3mEMA9VWymhrzmgr q+cd+peS8w7tRlRbDxltPabnVOOTmt/QJkS19aLR1peNtk5pfms8o/kNfRGp tl4x2vqm5jfkIwWvRztYhtsF7QgOGOkxI32n9kPkz2r+9Bc0f/pfNdLP6fSm Vj1nm/bp+tGcXdbfdNzIc87I85rO07zW7sujwfDlscrw5bHK8OXRbPjyaGZf Hn6YC+/ldIxnsIbh1We17w/0yX41w5fu034rLoP6b5Qw4OaXMNC5keFWn8Ch ufy94duiuby8b4sWmDfeDy3v22I12kwMLe/bYvUrxrclfFtgvtam5X1boM/f tUPL+7YItgt9gXxbrK7t2yIM87euZXnfFpGyiO+xjG8LT/8bK/Jt4bmN9b1l fFt4bnvczbfFf8T7/67NGDuvdFEdQCzt/6EnHI2a/h+6yf9DTzD8rv+H7wr/ D5WUzf/DJcv7f3i7XD98+qvPPSnfRr6xYXH8mP/5bzrfXx6FtFMbTpw75T9x 7jRInE9s3HfNx/oWr6nxfpTyfAzyfLzPusZ8w3savp3aOEh/tZ+EE+daT5z/ GrfT9EloS74lRsF93Obr4fkmxm3nGf/iuOEL4hrp84HfYTrffx41+4hvN13q 8It3mqAMVPujKJjl/3nD4uTJDc+9gvWc2vDcq6f8z726BF1uYH8BzjyWV70p rfrWbPhdaJR5Tm7Uv0/Db03D514FGv6FyKfHDXA7C+XOIj5rL+yN9Fkej3NO /xsv+RcnjfE4d2G+N54/t7zvDc8X2e/By/DfGdnG0v43PD/PNHqF05MmfsjL Z4AOjrJXcZmzx/wnXj/qHWw63bLlm47xuXaZPM3Sp4fkGSdNjrdafke7fReY 3y/H4pjX8tNYSx8MkAZ8cPao19OMfHjM/9zLyCdQvmj487iBfRS4jeWI4UeF vh81xhHTbG/woX7Tt4tj3KYM/xOvtHI/T132/DnDp4mlfZ3Y0k1+t1R//c+d gTa2Gn25emlfAgbv23ClemrhfTO3e6nzO8ylnUDfl0+3ETwO8BmE+S331eyT 5e7qcs+dYXxXraCeBgMXh9x5/nUpd07SnAK5ZZcTLUYbIy4yqNHktdYjda01 8uK4rKnxrXmJNjqNcWsScmlxRMulxRGgzx9L+rA/mfU8nnVrmbeZVs1cz1c4 zQtpmziN/d6cIL8kx8Q4f8VMM2RPCtpKmT4DmLZnNH/SGvH7Nfo0oHy6kF8U 4Q/B1id7vc8zjr9l+tdgHD8n6lm33u634sR9F+K34ii0Y/DvfbB+ppy/z3j3 WWfI34n63X6G/Jyo3+vh93qA7zsFMI/FtTXGYjX36W5jLGIM1wM8wN8neV2/ D+gTMH1nwLfd7CNkbjkfIVImOH2TEK5t+zrlXHN+h7HZB/3bx2MtfS/c55jf d9rXUaLHPqDHIPp9kfN/ibbfw7xgrm+TkH/Sgcu0rAPKThvjM+1SZ1MNXG+V 6Sfb1lkkN7xI831qHRCyBPrQRn1aq9IgH/DV3VD27tPedRaX8Zk+iOQ3zAfz 8p9VGtW3zjop5gX7HdJ6VOuJb39lJb41DDxo/XfMqzbAp5/p8Jqh/7nm1fKo 6pshV6u+tVTLPMHLOM9h/azD+YvtH4f2z+DcbgF9dCPJcaU/oZ5VA/9Gd/xp TF7jMRmqgRvK2A01vqGMtZbo77W1+rsEnQaWoFPnW6DT79npZOu7U28+YurN bvqk05+bm55SnYd0g3MOv2UXqmf+qanjXID/uCXrNmX1Evox7aUuVD826z5J ur1N1391hbryUanTcnrWRVd+1VH2PrkHWUJXvmSZPKaOt1PuFSVtzth0t8Wd DpyvVHtLwy+PkDdC1nm1jDtXRW/OBzy9E/j3b5bIN75Eu+NmvhW2O87tji/V LvtfO6t9xcmxOHHOWE8tY9y8a6Svomr9+rIa+nVzrbrZl9vS7Z84n6nWc/X3 GmvD3Yb++izkfxZwWeXT9L2O63kWZenHNu7zKh3BK3gR9kP1bvshljvPnm6z WgH/S2BOPYu/Dbn8LOD8qiHTfPb1Hdartn2r+Zvf+e2oN3Ycvq+VfaGD35X4 axJHfXaHTeHNgagVCPRFQn3BSLXDpptLm8gp0t7/n71zD46rOg/47pWsgCCY h82rAVyP7QIW9t67u3fvXY+TCD2wQC9LsmwC6WYl7cqLV7vapzCQYGhCSltI pwMttGmq8EhIMoHAlDJhSIcSSttpoWmGTh7TlLbQaZsQEsqkA00o/V7nnk+2 5eC2f6Qt+kff/e65537n9Z3vnL33dycnLhkZGN1zydDUwAhujhcqLd4+gyyF 83NdoV41aB/UEwepUm1uWCzUF0rNZkHxnBS/aSW+aXNjQ7Fa34APN5cq89Ee cv/AYO+e4Sm6z3i+3ihsgBJBOkyL9zKoJzxfqVqG0f5qec7YeAQvCh+XBBPx 0iM5Ukc3ZGlV7pSkX6qXmir95gb/FNOzQX4JMF8aEsGk6y8wKmO02qb/Y7O8 GzlZ4Ccmelvz9P/yVln+M95mJM9ArN7Fuhzz/8ECP65zeb6yYr8PeUrSDU50 t7necROVju8vznziEH9vOFExlzYrebviLykWR+xDSq4rWTE0Yo8o+WuKlbRO yfuU3FbyXUp+VMl/peQXlfxviqG0VsmKGeXsVXJDyXcq+dOKv/QgyLJX7Dyt 0nzP8pScNxVPaZPiKSUUT2mH4ikNKJ7SuOIpXaV4SvOKp9RQPKUbLS+o41ct L6jjLstT6rjP8pQ6HrY8JeI4CU+p4+uWp0TsJuEpdfxI8ZTepXhK5yie0rDi Kd1ky9V5m+Updd5teUqd91qeUueDlqnS+bith84/tvXQ+ZzlKXV+y/KUOl+0 PKXOVyxPqfMNxVNyFE/pJMVTOkvxlDYrnlJS8ZTGFE/pg5antOY2y1Na84eW p0T8JeEprfm25SmtecnylNa8pnhKnuIpNRRP6SbLU+q61fKUun7L8pS67rE8 pa4vWp5S1x9YnlLXU5an1PWs5Sl1fdPylLpetDylrh9anlLXjxVPqUvxlNYq ntI5iqe0UfGUtiqekq94Su9TPKVdiqe0R/GUirb+T/h1y1M64T7FTXIVT6lf 6duWp3TirUr/R5andKJi8nSvVTylLUp/teIpVQ8xbwHlg4qt9FHFVrrdspW6 77Zspe7PWLZS98OWrdT9hGUrdT9j2Urdz1m2Uvc3LFup+0XLVup+xbKVut9Q bCVHsZVOVgylLYqttF3pP6hkxcc7Sfnkk95SbKVTFFvpfMVW2qfYSiXFVlJ+ +93rFFvpAsVW2qrSfECxlQpKf8ch/u2bnlFQ+hdAlm9PvPv7ir90yyH+bRtl xVA6BeeLQZGfUiymO61/XotMJ3kIYa3iep16mpIVj+vUv1MsJtV/TrvalvG0 stJ/8hA/P4Dy55T+BTt3nPaq4jghn+QikRWT8PRHrc2nP6nSfAfkrSL/wKY/ 42Ilf9nK6y6zPnzdlUp/s/W96z6h9C9ZO9e9ZvXrsX23iKz6xvorDkV8wvUq //U3qvSqjdZ/ybb1+q8o/QsqvSrXmafb8p65UemxHWX8nonXynx95r/YNGed a+WzVQxwtopVzv6Glc85S8lLdq4556NWf+6rdh459z+s/j09IN8rcqj0Vyn5 ZiXfo2T01S+JjH3yH0V+zY618xAk8k8iqzjnPOQHviayGuM/P2Hljb9m/djG Tyo98nbEx27EOUKi4Y1qrG3C+rxaZBVrbb7ZzpWbVf/ZjPPyPSxvOcHqtyhf /QvXK1mNwQtVH77wGlsnFyo/czHMR3F5rubizUqPfLwzRFZjdutvgv4mke+3 +h41xi85Ucmq3rZts3172w7ri7btUmletvJ2xfncfqe9dvu9dqxt/6KNARKd Nn1CxdKJZ6zsKnacm7Oyd4qSkYkqc583b/XJ9ygZx6Dw6JKKK5g6x/LoUhcq /ccsjy6l4uT0ey2PLj1q9f6plkfnn7+JGW4ob11muR+/9whykTk2/uUgz/Mz 5HRyv2XaxEoxy6arK7khz1Kh3LR8HmLBGSbbkmUHERfOsOkOxiz/7Xp+npzk G/hZ7YgX9zcrZf8q5lAh68afYw7VW7C69yvCoXod5A8Lh+oExcM5VfFwMJ9f 3hTFk/6dyyxjnXxqmfhyVCcPLbONpk5uU3Vyu6qHT/Bz+P6TkKfM+/7XllnG PL+1zM/AY57fBeHTnKf/42Uem6au7lX532fZR7FHlfyY5QjRuxwbRH7cspUo vjX1/BVVz0+a90eYOxczzLenVf3j+x9PiIzxsGHW/Zl5t4PZcTHhnsX+WjH6 vgmyseHb/Hyq4cXFTR/4W5ANY+08kA3j6AJ+hpvkTfwctuGbOYbvBPOUYzhI W/k5ecM6M/y9eJKfkyc5jetFkTP8rDvJ0FaO4baF/Hw7yVl+jp1kiGc6pG4x Lu0w7KmdSoZ1VkdK5Estiw+ZYB2GlwVrpQ5j57Dl6cVHQH5S5FFk+oo8Zjl7 yDU0nL34biXvAVnaIj4NsinLXsviw3i407DvruJn2g0TzDD6kANmGH3IATOM PoyZDaMPY2bD6MM42TD64uArOhdXyhnkLd/HYzNzHsj3My8ug/y3z7z11pso o6/+LMhQlgyu9R4AGYZlBmOVz4EMYzODexqfBxnqIYNM6S+A/Lway+uszO3L 45rbhfVc56J/ycpk56FN0gdBvm2ZZeiambuWmTNmuF7XKa7X9YrldauSf8X6 AeKDmbpCn/D7ign2tOKA/YVlf8XNtXfzd74M78vwLXF9ETd8tt+zTMs4+Iq4 aYv7Y8w1Qxk5loYf+Fl+14Lkz/N7FCTDWI/LeMd3IuLGzkdAFvZm/FH+RhjJ j/E7ACR/mb/bRfLj/E0ukp/k722R/BS/I0Py0/xdLZKfUWPzT5QM93TE58T/ XI3ZZ0EWPmf8OTVO/9LyMONfV2MQ2ZWmDz9vGZhxWLN3GBuQY2nqDfpaR1nk 7/A7JiRDV+kQnxn/e5ANB/If+H0TkiEO7DB2/rMas9/jd09IflmN0++rcfqK kn9gHksG+VV+J4Xkf0Umt8g/All4sHFkXZryvs7vm5D8Br9jQvK/q3H6EzVO 37RcTXqMWHwvbvl3Sv9xOixjE7/n1im+y1nD76FoOfMAxBjXy3h/COQbmCGZ wfX1h5khmUHO3kdABnsy3wX5EMjgdzKvg3wzyGBzAJ03/ksgw9gJukG+BWRo r2A9yB8HeVyN/ZPV2H9AyT9U411x/LieZeyDzcEFm2LO6ZxV0LPMMvTVIAPy GXbscx8Xeb0d785ZSj7bzsXOuebpT5B/zs7Fznny3hrK58citq1zgY1z8Bt3 Mek/zkbzzmQ/ja24+HNns/UVzkV2znW28vf+SO6xPFvnEv5mH8nbzFYqyNv5 e3wkJ+xYNnLw/kNQ3tVZgpTmMqhD4WcG08ssYx3mQH4v12FQBfl9NnZy3q/q s9f6TOLpGnlI1eGw9aXOqI0hnXF+b5HkKRvDONOqPvepOrzaPKYL8i/yNxNJ /pDlBjuz1q/iu3rEx0QZ5rW4jB2nZBnCzgHrP51F/kYhyTXexycZYmPH5N/k 9wFJXrLcYAfmGseMtev4m4skw1zjmHvdwO/3kfwRkE3/uRFk02duBln8DMZH Haa8H7MMYecWG9s4HwdZ/Anev0NiAAfi3g5j/23Wfzq3W/+JMZfxn85vmG9z ggzzWofp53daP4lxWYfEcs5v2zjH+R2QhaOLZTU+0/ld6zOdT1k/aeTgRuif vdw/A1jDOpdy/B/cAXIfxxvBF0Du53gj+CrIAxxvBM+CPMjxxsp1gfiQcdXP 71D6P1X+5OSVviV4fov4IZBfhnHxoMg/WWYZxkX4LpAfUr7lS2osPKz8yaNK fiwWMcAdmHMN49TBOH+/Sm/6J65hTV9Ssb3zVRt7GDlcC/XwMNQbFC+ENbvz CMhPHH28U/qL5ux7APSj2E+BhJpU71BC36GE/ky9JRTgW0Ka0+kxpzN5bE5n CnLzNKczbTid/rE4nen/n5xO70hqpBf8NE6nFx6Jmkz8X+F0um+D0+kqTucx maVH43SmjrwgfSxOp5dZwen0QsPp9MIVnE5IZzmdPmM2vUyE2UxmjofTmQyO zCB8h9P5NjidiWNwOt1VOZ3e/yCnM3kMTmdqNU5n+rg5nam3w+lMHYvTmTiC 0+mvyuk8jDCqOJ3ef4/TmVqd0+kfzulMBUfhdKZCfH11NVZnKjg6qzOxGqsz FR6b1Zk4KqvTXYXVeWRuK1idbsTq9FZjdSYtqzO1OqvTU6/v/gxTO1MmFggO o3amFLUzfXzUTv+/Tu3MHEHtTB9O7UwfhdrJoNDjoHamg5XUTjjW1M6j0EOD w+0IVqF2pkNF7YQpiKidif+t1E73MGqnd2xqJ0SK1TZxT5PQIiDLW+iCwUQF zNW68TF5joGfrVIVspmHi1M7C3uGxnJ7JgcmJsd7+zDwwOPJKyf50O0xp4dY 4UE8IpdTZik8YnRoKoEn4D5Z3995sS/dQ3T8Br28MI86DiuySV9aVzItluez zBk0Fxdx+swGhkFJF5dLCyW4NqAWkIvrhQahBqMaRyWamCapvkRgTyruxEBv v5R078TQFEdZnIiuyMQqhSZ4q2JpnrGafqoymwNdaS6qYVA0Cgv5SrM020Ca oSdKmhnS0rfgeLFebVaLC+WDFjpqtAqRWkGMabs0W1CEVLxluVo90FrEG0hf A6XR+eD9LSsVTrQq4CrmLLozAwGxQV7uiI32jY0O5nb1jvYj2ACBnQFcsx98 KSI7L0bKph9EZZtt1esItzTdp5HPFfMLpfJBjm0gapkv1Jm4GZTBGUNzmvFW zslZ2/ka4HYJPjmVSeOAj3LL4iQBrQoKxo5GK6XkDo9gpS5ev9CYJ8RpJoMh DhytRNQahe7xqMO+iJRM35BqRcnpuDFQlZ+dpad2G6pFVuj5AmkXWGxG9qD7 8vCQRltKGLR83C6UI2tIJTxQX3CdVZjKMJMggZlwehk0VDrjUDHnZHQVxN2L ObVgBNsKizXIBefhRi1XLNWRxAktGiR3XtvIHeD5MmsmY05PwSpMwXJEvWAq wMaELGqtAvjdQJoTFBTcMe8isFnsl9A0gNi0VEdfFFDjLpZyxSoMtwC8QCC0 UdDN5CGTwDcIYVAUKoUiWGoowqVcAWPx/SWoR0PnpYzpJrRECmAA7x679PLc ntH+7CVuD8n9A4MwmEnEgT0wYY5obE9kJVnftNGP7Jka2GcOJgdGekGG6bg6 cw3dCWaSVr0CU32ZZpYggGqMNFl10qwFmnzYqoCBsD51/WaDayBMQA3ImAId lK5aqrSzVCm477LDZgaXBhgHNRuQTRBKArhI2je0n7AIXBPZwmnwSMJh9fGQ I1ZoKi+BIFfQLJnG81yfNQ0sKNjS5iEHcZq4kB1YxaG3s0AVlOvt7x2fGprG OYEVk+NDo1CbK8/mJqd6p2BasElYkxRN/wQkmsiNjpE2tVJLuvThOWKD+tAi B+zygyrai8lKJ8Q5L1ddzENPzYYpu4QNo+VgFOqHSSpVemdhYm9ucnhgYBzK Y0Q2wMXjlXZ6SiXFQQW/NwGlgDvgXGEso84Z+nQP6XV0E+mPrkkPSSGyB5Ea ZSrEKMyLCmJ2PzwuSIheW9LSpRm6S7izgH02MibRw4dkLN8KJyZrXAh3RE12 yk0kVlRcVFt8Ae4JQox/AOP0NkQ8kB6cirWvRyDQJgFf4aJVEJ7sLPRNK6Pw QJk0244MgrSx2TpMVHBVEsO12TpM3sXIe9YFLi6esy5wceF3Q9qWgo3jMZ8X vw2KBicQd40KSRGaHCvz9SpPq9L18S6schOpaJcvqajjYDAbn4zVIfzglXqd AxEoCO1qoh4mToNYpuOF/LVReLAjVm81kI0OF/iIqq63ci0K0k30DYqGUXBc BBrIot5o2CKCqmQ0XEbUzImGC4maBmukiJhRqVIsN7NRsSjva0QVmLwrjaX8 ItV/lHdlhjps0nCcQYdbrKILovwb840K1rSAnFlVn22jKmXzL81X8mU0LRWY W1Tas40l0AiSGzUlozJI7mK+VW7yLAoVCFPBYG5odLp3GHrbYG58YgxH8mBu cmxwanis7woYw3ywZ5QOkz07ZKNVMgh2FoZz472XDdDpRA8fSGpXDicG+oZ7 h0Yo7sWYF8NIN4FjMDc2tYvG+STHky4IHE16IA3sG+iDW07m+uAk6NBltOXO bmJnYXp0bBSunZ4YuAyunO4fmoDLpi8dRjun+3ZNwAXTw6NXQNeZHhwaHAN/ ON0/NjaRzfRMQ0n7IB6enkQ7Q7gIb54w+XNYkIi1Kxg2w81gCPuJNs/hoez8 tTlMZaS3D4ez1RYE6GkZVO1cu9hYQFVhbn+hjixwBGW5GFDAmazpiG1wDXCO YFhpPIf3rC5iAu6XlBEm8Uy/hKVjE+KRBdD5eFkGLms0aSIyHbUNq//5As5i AaYIIQUqsqbXtiWQgjJLp23n6hA90zCT21KGeJCWuxZLWAGQKe75u54LmbIq a/ovWLa/bhJhcT0srugIF2a6NVRXG2rcpT5NHpEKzjXvxtq8MeJ6EE6FfjvP az2J7Np5az07BUyATWXWDHCsHRwcrvBvcFzEhU46quN8Du+OS5PQrIdQhxuL 2XRUafkc7o1gmqSXkDR5djUBVQGrFowKy8aqWaPCsckqqe50xuSNnyrA7KEQ CWMmO40G3tJPmVu2Z7msGQOtb5sdIaivWH0B6w3n6hHir8EkOgJDY6Bvamzi SppIGgcXitVyuYrD0IMJd3QsNzg2PDy2F50AC5isPVu4draMaTKYZnRgXx+6 CfqH58Gd55s4PDzwAn0TNEhx0poYuWJ0DMcySjwo4ezYxAC5j/oCG5q2ZrDC lxvyUUay56Mg1m4UZk2fgAWDl2g3pFPIRIHH+dmyXiOLqlBp0k6adA1cJhWj lNJBjNKklY6yI7ov2xHGouE5hcO14Wa8dnUxh+9bZt0kDouku7MoUT+eIdI1 nMLBkEziKbENztGawk3i0E+m8ZRYCKfwpU28zETxqCtVZ5uwGkrimE9mML3p znCyUWgW8SQO92RIJ/3IiPlCk+rOTaGFKbLQ+BK+1pyO/AeoYeVWgMkP8owG QHVRVs6QFkuUohIZD4LF5T7hprBQqTSXN2ELvFBt41ksQoqKYJwL5oyDzU1h CVJUAuNU6EpazrlpLECaCmAcCZxdOIDfPHHTaFKaTJKZki5d4JNoUZoskhnT NAGfRpPSZJJMn1QzBxfYqjRalSarZCo1V/N5H+3yyS4zoOF8sXGwMgsn0S6f 7DIjG5uzkgevgNXho2k+msaj3FyNWzG4DeT6ZJefsT1HViQ+muWHdKV4Az7d qpgEPZmkbxu6ALoM2pohWzO+bbkFaFTcxHAzZGmQsIbUObMM2pmhKgxsL4aJ ZbaAJ3sCX9dMuY0ZovkZMj+wPRn6I81GLm4suBmq1tD25cWWnMZvYbgBWRra 3rwAkZWLi3M3IEtD25OhMfksWhqQpbjph6evjmGCuUKZE6BdAQ+ihO3ci+CP 4CRaFfAgSti+PdfCKsL1qBvyEHJt117MN/fjbhckIB5mkhPY3o0lKlXhNJoW smmu7eCYOQ3vEC0LZXjbLo5bFuRJQjQu5CYHd68dgHGRXgJ/k0+44iK0G1BJ esBV2UbkKRr0Hl7K1idN0GicHs/O6RhWUxHWHl4CdzuKc2bXqtAG/9nIBvI1 lHp0bOZ4vpB/J07FKkX+VTEd490SyA9caujVcjX6iJAHAT4Yg+FNjT5Qwncx +zOwPMfTGNtAhDyTFc9ay5XzfFb8aS1H30fxXKoVE5/V2N+A1rjRGmFJ0fn7 ch+O6FLGV9bkJyvjJGu4GFhsXGc3TGu4zhBNIJnuLy3lm/RbluQKMx4r0pLr TL4ytwiWuGAfBIlQWtREQVUtijvR5UEIUFPxn3FmoANfU4Nc8NMtEE5C2EUK 486gFihXlz1YAIqlPNQpxmBp3hbmPFiT8VlTKTbqbaolcV2YT6RKyb3n6nlo oApFwxlP8mrCIrPahNb3g8BmX8MFDpQ+Cl6o7blLQEcgG6ewGhpeUJsxTScd DBSmTaSxZ2xnMM09YzuANPVM1AimqWeiVjCNPWMaVxp7B9tChrlerFYsFcpz DTQNQqvdu4b2UrCzG4Il2v3YPdK7b3zyAxDr7B4ZGkUp2bO7b2zPKO507B4c mpjETZrdw73w3wfFcO9lsA7ZPTk1sWcIFl1Bz25cgoS4h8Z34hun8YfvFu6T 0Ve1wCHQ5m0JlqqV1oLZTuDjFd/sAlXUOWXftmQ7p2zblg6vF9AcVi9gDw29 KRyHjVSiViL3DE2CX9SF1YUJduAEdAs6YdqmlKtRYIQqaRtQcUSEOmkd0OXn 8Ncl1JkGIvPRB7i4Q09f3DK3WWhAuJL16MEjWoRIFZE6GqslmAXZGjNaS1SJ okube5tuqr4IxqOrmZ/Bp5Y82mtvQrhO9QA+SbZ0mxikGZV80ayZW2hda7Vc aNYuRVqzL4v+B2J+vAl9bq6cqzXRPHoGKpE2PwTUZqpYWtPjyzl6VkbtgRfr hUKu3qxgRriFQsfFFoxkz0MH6mVosuCvpuG5fH3edhS8vskPpEBMjms+Knbw n+ydC3hUV7X4z0wm5A2TkECg9DZNA6UUyMyZRyZBJJSAoBQopBS1OuQxeZRk Ms0kPLytjtXe1lp7KY1tr1I79eIVLbZ4ReWvKFzt/4p+WJEbuWipTTVV9OK1 aq+vqty19l777DUnk0dH/bd+/+lXvqyzzz57r73288zeZ/2QdtUOnQJuok5Y CybpBMFyo0wseNWKFkJ7unsxkDSDAPxJSlGc4ZLe2ojj3N6qf2rFt1sRIqtD 4Z9xghXBbS1tXRG2MIcgxL+JTk4tQygbQa1wHIUFt5gh6y3dYExQ91WTgGBx eqJetQdLAVU+1SisG6qINJpb4cKjtc96WbbCB6FZ+/BIRwTaXn8bGL+nuzMq 4HvqCJF8z/b5xxzhGPQGxQ96OHWq18tlBiLtZHWFDDHvNeMcGPeZarD00K/l UDiYgcW1rCEcPKN8qIQKUnrLRtka3qUCyNCt4mcAaAHwhgItwLJ2a1jNJmji 0LJW9WuIrBG4lnM6Wtr6abxXqe6pN+BtRjZ+eJ+BcQUuYQlqrSTEJSoCo4zX o37HxFBYFCtKuIhE04HUH0OEGx699YxBYlPceiPCkI7unh6v3n0WQSlzu4oU QbS4aB7C+Os2rtqEHs1x5eELGm3oqwbpcCYer/L7227lhcArUQb1M+ytXHu4 Ett51pYmBIj3f2s0brMWHOpn2FvFngO+YZl+sZqxWjjGJXX9Xn0aSRRHbpNI XeMxUBaZzaBsLEXZmE3ZWIqyMWlErSyuaNu9TFkRYDJlY1xZS8+YzdAYoBT3 WT/eyxWV+PUeX3uRF4d6+5cP+v3UcsD+QnPPMlULUAmLRQ9cZpXVlOeLAjSs Qzft7ouKpASnM96nzifRoN4n3ukgmrWIhaBd/bgzW0+rWAiwzawYkjqzQoht ZoUQ28wKIaldCAKw7cYGdC+SKWNprTELgrB0FC0QlAvr7qgAEcq9NLiwgN3q AouMHW0LbrGZ8O49KMRwK1zgsah4uNWrkJcgmwp6CbJPqBiUF36xDYbD9zJp MpHKLkilXqSyy2ttR4d3mRYs04osdCFrL7P2U2lrG6Y2PPHrEVMuKG7b36ZC WonGVdmgaGoGhiD0+tVgBrzWeGrqwy/w9ij7K56YCnX39sPU3DPQbaVCp6n7 5VmaDnyz1Ykv49gDf/1Y0EFgHNKBz5OKObCmyLCa6MQMiR2BzY/LxGEpgWk1 8eiT6elK3bLvwskEEsRjDJRBlzBIyiZ5V5jApRZaVbYOUYwg+6krGlGZiS3o aGpm0bGZRcdmFsUTHnzvGc9oUKp4OtCM2cC4Y1ON0cEOvcCJR/p3UhriyFU8 NY342DTisqFYHVSfFbEUI16viaex/oaAvaY87fVXIPaaeO7rbxDZa+Kxr1fG 7DWtk2Fjob1m0DcJtRcy5NheM+i3uL1mMPAXBvea+AOgGfSnRfdCeAq710Tq MoP3gjqc3ouXE+F7Tfw5EdJID/CFGykEXzNYrxG+Oqe/CsPXtM5jpYP4mnW4 4ofOnx7jC3cYx9esM/98kC80IBvJF0PsKF8Tz4OZwfoMYL4m/tYKqqbD+UKw 8HYZlvxZr2HhZOEdqW2HqJ44XCONGVQw+iOxnj0sFAIGxIIYV0T4ow08uQGS uE4SdsHWBhPxA7PJcxqbCT4Sxjkc57SOV/SoeAmFAV0+i8+gEh0wFuPPyTDL KhiwqdnOggYMr0MQFkoJExOwx7COtokvCeCPVIN+PLKspK8xyxj69UTlKT9U RcSQXUAoS8kp0LFZV58GimyGPHYqMoSJVuuXlGMTf9DGLiZSRgXkz5MgDMAb JwKZgx7rlLPPED8StcX2gHb1qh6FpbC8MWjxVG5RfYOxdlyG8woU4cIGWAxZ 3LCwgbzu62mXBme2t8xu4aCliWWwF8IDKeFjbN4Lr59d8YYtpgWJXgLDJCnT GZFnrdd4ldVQTyh8DEqvs1Y17od1ndHd4LXxvMZjIRdInw+u3U75gfYsdZtY yPOI0bXMMTm7GD/6vcowcvcjF5LSW0LfoXvSPG+/trOSnfJb7MJGEOc5LTZy MfoPMYj1u87yyib/bLVd32y7brFd32q73kmXo5R+wnbfzkLea7v+oO16v+36 o7ZrOyv5Sdv1F0DCMpwifb5mu/8d2/Vztuuf2q5/abv+nSF9ajXK9B05qfc1 G46uS23Xc23X1bbrRbbrWtt1ne16he16dcq1+qqXD6KppGZreKJOZQ0IvMen cpolmhl/AyMgsvzKBW5LXrM1p4whN0d2j4E2i/1YSGcQkmQEZ96TbRxn4QJa hMP9sJx/Lbhz7w5xx5psON8ZyoSDolC8p68TX5KNgT54m470iwFxKnhn7N81 ijnYbhhXK3mI2JTbpK+DaYrvvJ/C0ZdAksK3y2+9F6lnj1GcmPycW8SJEY4R w3dLnxIiHOXhVCZyOXleRibytcQGRT8S1xIbFP2JiHQSskuIdFCGNMsVaxjG rGsUaxieuUzxixUP9CDIigeK8mKIo57167KgDxkR/7Dktor4KK83jEoVp0vr jL4YlM7oY0Hp7NxN6Rw1hD8FkQ7KCabze5nOhzU7Ff0qLFZM4W2UDvqHuZnS GZH+EKw4d7M497I4QyzORa1zzosUH33IvETxL0jfAko3HKqVTVzFuozo30mV Ef3GKP3Rv9MCJXsMY76SX2cYs5V8ROvgOsrSPMbSPKF1Q6aw0s11kul2muV7 nuV1gckv6Xxzy5m8XsvIorW4sVCnFUp+r9Yz726tZ969Ws+8vVJP9GebNyT1 FPLDWs+8/VrPvIOagZ53VPfB/E1M7oGkidWbD+2qili9yJAtU3GOaOZ4PvQj N8kFUC9XKBna9kIlw1z6d0repjmz6PJb8dPR9aFKpzim+07xgO47xbt13ym+ TfcddEGr+njxe3UfL75bt5/iIZbmwyzN/SzNJEvzANm2EuSDZFuUD7E0j2nu fPFpXV/F53R9IWNV1RcycEWaMAYUj1KaKF/Q9VV8UddXSb4eB0qK9ThQ4tbj QMlinW+JX+dbEtL5lryO8oV6KGmkfFFu0vmWrGX5Nut2UtJOz0LbLOmiZ1Hu YTrczXTYy3QYYjqQzdGvTAnZXMhJpsMBpsNhpsMJPVaXnNdj1PRKPbZMpzaA fr+mUxsQ8r06zelHNA96+jDFh/ynn6P4KJ9n8WnMR/98M2jMF7JLx5mxWKc5 Yz3Fx3F0E8VHuZnFp/aMfv5mUHsW8m0sTlLzxGf8QcvuKib79RjibmQy2L+g QK5/3WD/gmKSD2hbuV/Ufbm0WMtiPMrRrhhRFr6e1pLsln6NhJwv/TdOoyUz +vREWfhe2kbyi3ItLOQLcs4W8oic94V8Tvp1ETL6Meoh+aScv4V8wnjFHOpi SHOm4k2DbauVfFo+i+8fpbuljO8OFQNSxnX/rKOaVT3nKUoT7DEHnp1H4XMP yvilC19lDnWX7b5wpm2kcqj3Cz31f+NwqEvRH908Fm8cDvXMC8ovlS3eFals 2HKo+7mHmB6Ktzw/tRy1+cSAsJdjqZHCl+6C8jpPU34lhuZLB40UvvQOCEc/ k2PSe72RwoPuaZZzpeBfc770utR48Yv0TpVnpPKlm1PjDdzN4uWyeOFUuwyi 78BGu36vxfN/S2sHB7p7/qr450n4zwG/N+jR/GeUPV5vwGtm+c//D/6bnP+8 tdEaidBv1/TJ+c+t8fhfDgJtaI6fZIo53qQ4ZfuQ1SyYYlWuIXeVcMSXho8m OHOKXcbZ0Tg4Hi6r4vzFiy86jXE5gpxplsp11OHEaK4khlTJWO5xim65jE+l eXjOKvcwlOY0vMZBeWeNz36WeiEP8YTgto3lrE7AR61Kw9nzjBN3aRkxuux8 QcxXc6RTnxuPqany3euuyiXeabFicHP2NnHoclzE5FLx03Bcv8I4rjmKe0Ys vTwqW+4ELLDdjAV2HtI5z/NV9YnhxALLQQ7X/WZjPuhzDsLPQfkunZGyiuOU rDnBKjt3pnrFi/D3PCvfedD7R8pumjV3/OJZKPe5vOOj38s7bnGh07VFGw/O YiQSR/NiSruDdE9LW/3Sll6M2tA5+DcC8UZsZb9Fcg2hPq4+Pkr2GSW+4ph2 YjHe0rdFxRZV9rW3vyteYTvidbqK0h6VjMjjo4LRJhiRmJ5kRKapg29xncpT dbSYbkpHymuhygvtoMYh1seH4Z7gLE/T6eH1pXJtV657eTo+MbYbaEf58Hd4 bxlytKEdQf0w/UdA/yF89kWIm44tD3pVjjN27E3CPbjvftclyVtNF29qXDlc QkisnCmWwbVes9b0V5lmg6euweMZi5Uz5g8uVf+nzEeCTyaSK0BG3Sulkzmk L9O653ENyRhjNUxewnhjjN1lvJ3JMSYz1oVxmMlPMzZYGZMZW8UxwOQHmfwZ Jn+Lyc8z+SXGAythcgOTGQfCeSuTH2Dyo4w3dmiBxThxMm6N8yeaxeJ8WYfn VGs2TA4yKhRvrF5zuXJWac5WzgbNn8hBv+eKN4YMHsUbQz0Vb+x2zdPKeZ/m aeWgrRRvDPklijf2ZELzxo4nNG8MOUOKN4Y2VLwx5Joo3lhuQvPGZmtWjQu5 OIo39i5dLhfyzxRvDNsAreddjyU0b+yQ5gy5jmo7uL6q7eA6ldC8MWTAKN4Y 6ql4Yxc1A8b1m4TmjRnaPrkF2j65FQnNG7tKc2Jyvbrucq9PaN7YWzVDJRfL pXhjxxKaN/b1hOaNISdG8caQm6J4Y8ikUbwx5M8p3titmjUyDW2oeGPIjFG8 MWR7KN4YspcUb+zxhOaNHUlo3hiyiBRvDFloijd2NqF5Y2hDxRtDZpvijSEb RvHG0AG44o1hP1K8MWwDijdWldC8sWsSmjeG/v0Vb2w5442tYbyxLYw31q7t n38f440xBk9BLeONXcfCBxhv7C4WfpzxxhhDqLCE8cZqWPhbGG+sl/HGdjHe 2B2MN3Yv4409xHhjBxhv7EnGG/sC4409xXhjpxhv7DuMN/Y8441dZLyx3zDe mMF4Y4WMGVbDeGNLWDhjHRUxZkwRG5OLkJuoeGP4A7LijTFWTTGO1eQOuLhT M5CK2bhdgmO74o1drllcJdewONv0OFDSxsL3aQZVCWPhlDyrGT8l/6XDpyP/ SfHG7mPhOF8o3tgJHT7jAT0+z0BupeKNMS6RmzGc3BuZ/H0tl7L2U/oWXcbS W1j4hxKaN/ZxFv6snjtKGU+rDHkYiiXWzMI/o3Uu+zKL84zmb5UxLtRMxgqa +Xktl6/WY3g5Y26VJ/TYW/4BFv4DrWc546JVlDEeGGsbFes0V6mCpV9xO4vP 6qjiCV3XFV9k4c+y+Kxcs9y6vLOqWDjWo+KN4bOKN/ZjHWd2pZYr2Rqgkq1V Kr+j5TkVTB7Uc80cxgmb+3M9j8z9A2OGIStL8cbqWDhjsM1LMJlx9ead1Wyt edgmFW/sF7qvzUMuoOKNsXXO5XcmNG+M9fErN2m5+h7GG/sQC0dmm+KN4RxR RTLrazVoT8UbY2ut+Qk9V85n7Wc+zsuKNzZNhy9gY/XVe5jM+uBC1oYXdmmb LGTjzKLZjDd2FQs/w3hjrM9eO8R4Y/+swxezPr4kj8nMbksX67a9tF6PRUvX sDg/1XLtFiY/oJ+tfUz3tdrH9RrA49TxPWwt7XlKy17GQvMyfqTJeJMmsg8V b4xxHH2Mt+fDPqh4Y4w555/NeGOMp+h/D+ONsXVy4HWMN7ZehwenM97YvBpr HA4uTkpZcaHewBhXa9Vv5k2SE6Hk6xnjaoNmQoj1sErnBs2HMDZrn/jGFiY3 y/1PLgeRjbqW+GHXLbTWloIr9kbJErD84HN+WBPzid/FZEyzo8ZafwYHklJW eray8raxMnYyudvQHK9bDFpng7xD/T4Oci+d9UC5T+4PCTmmzkFpWfDP2qiM 711ojVep5RqxzlAF99ZIBhvq/2hSykr/25j+tzOdE0x+t+YWGHdonodgkKk6 +gfN8BDvHYpPdrfmFoj3DlWW9yt1myS/jLgXYr2t+HB7VTFAxnUUsU/EOTDF J3vQoHUnyA9phoqBvCVl8w9pLogBay2Ham+Pyv1hLgcP4vsU2RbX4e9M12ak bUX8r4BtHyfbIhPucZlc8JmkZK4RE8L4FLPzE8ye/8rkI5oJIZhwSrfPac6K iK/a/1F1ho74cAdS5eALcPMJ0B/UDeI74JMgIxsPx/DDIJ8bhwmBz16qkaw4 +K+uKCll1Wa+xspykrWTbzD5FGvz3zQ0O/Bp1v6/xcp4mtmK5Dqcr0/aWDW8 bWMcZB8+S3riWPQs0/P7TM/nmG4/YvKPmf1/wuyP71zETRHvXKrNoC7EgRPv WYq396LmcIhzgKoN/4q125c0qwbfxax2+xuQVV6/M+i9pUm8l1m8vZcNeidp Eu9oigeG72UOxbIyNMMGx3zHYV1GJTucjAGWI8+HcbkO1zbPyTZfh2u/EZCR 5Ybz5vOyLdXhOvYHsi3V4dz0Q9mW6nBuGgV5eJwxdiHrO4eZjPnGaiR7Eutx T6M8OwrP1t3xXva7WJMVx+JTKhsOGJqhSHLd0zU0DoH8n5Dme2xjl0rnTpbO P7B2S3LdiOajiB/lJsOjyEhZOkqWjvKaoqMEs3SULB0lS0fJ0lGydJQsHSVL R8nSUbJ0lCwdJUtHydJRsnSULB0lS0fJ0lGydJQsHSVLR8nSUbJ0lCwdJUtH ydJRsnSULB0lS0fJ0lGydJQsHSVLR8nSUbJ0lCwdJUtHydJRsnSULB0lS0fJ 0lGydJQsHSVLR8nSUbJ0lCwdJUtHydJRsnSULB3l/1s6CkxkODkI268xPQYV JxYwumDRI7goAb/RRTG2mtaZMOJWhFX5mav6hjXyeK6gUshkFJRiK9Sv0dnX 125F9RoyQ/zeo2+AluHYLzq79ZWMbCLpYk0KYkSrK6ai1j1ikegVtIvd4ipg ecTHRxWMxGeQdXyQBCRrihPCoDfYQ/E0IBuGTWGAFEw8VTPIpW2QsvcaXQN9 0Z6GjgDM8viGvClgMAdcPd2ttZ1tbUvwbzzW0t+2JD4YXRLv62np746bS4O1 5Hm2tjva1jPYHqmN74nXYsIwoEX6l3YZ0YG+rtTUp8j1yLdxPKZTWD1dVxhG Ln6PvpC4GpfBNX7zqjgbnMORl4bzcaXy/+sYy+3A62vJV7+R5v5kHBEn+ZHl nIpltutG2/WGNNwP/P70YeJmdNru90n/+Y7zdP8d8Ae/bT9E13fCffzmdhNd 32d7/kHpg9yxlu4rrkdCXNPnlSlkClGVsrlQo17q9anOttTrkQQKQZyA3oVd qnWPgElYV4IMkQYSoRs16zuaDaHwD6wn8pHA+u5V+c7Gz0oLyYc4fr9cSD7B 0feB8omP39RbcW5mce7VvsjxG+1yJT+lfcqjj+2Z5NfecQxk8mvvHIWmRswJ 5wWQiTnh/IP2qZ3zOu3vHpuRSsfl0um4Dmq/5MLXk/JvXK59SQs/6MxvdRHz W13E/FbPUb6qodoLlQw6lSn5JYiao32gV+Zo3+IVJLvXG8YsJUP8cpLLjkkd sN+VDWt5pptk6J8zt5F826vs27p3Cr6tDwg9J/VtPa3KYP4gxvdtPQ19Mqwc x7d1Pov3deVHwaZfTap/3GmnwJ43G3o8Uz6hF6WWd+5C8ktoT8+X6gN7M/mp R4aSGF+VD+xlqT6wt6CPhSfSpLcq1Wd1M+p2jsrGfWBvSI13o5/C820+sN9s i9dIn7XnUx2peO02v8FGOh/Y2fN/r63zf0tre9sDf13335P4//aZAZP7/zaF /28Tw7L+v18D/r99a1P8f5dM7v/7L+X6+5EfHg8pv8wvXZ1cvy/v+MPcz666 Rl/Mw3nJ9Tyc+z7mPm+V72T0tXuienv5ieoqt/C/POfba/eV/bPjTDX5Y172 q1vg+n1nqqtc4nrB0s/vK0v+Ca7zxbWr+INwvROui1n6Ca6v9MVc5b7f3J6z r7BqxRnloxv+nQV9P7hoJOeMc7t7yJko2Oc2CiEtN5bj/kXJnMRHG/PnWj63 tc7Dzu3l+5xJxxCUe7i6qjwlPXPkckivfMjZWIj39rqrGoVP7WrhO3gU4q6H 69HER42CQvJhTD63KyHfpn1Oo1Db8/hoo5FXpvwx73NWVZJN36p8H0tf3MIf +Ap4Zj2l67L5Pse0LmLa9PyblD9qSLMR/VS7j1/6OYaRL/Ecki8q3aRfZEsv eA7KB/mdBXmoOlHUaEy7YKtnqx7QbzXEXQs2cw+5q/IhbqvSy1Y3o6eFbarq KsnnM9gvhPZC+yl/zfvcVbuHRVhj4WnhLzu5lvnuHmFtEOt6rcxT+eAWdYVh btCjUekBaRoQtg3CztjK0ajKIdsS1BfYBfRyWTaRYRcgLN8WNgphxbawEdAr qeoY8myEPFtUfVQEvvcJKMdu8ll+Acu5r7CxEP2RD4WMIvg7MlSYKNpXhvY/ nsR6wLiqHdy/aHveA+b2OeSrWvi5l3VoXY9UNHh/Bv1qK+VxEdK5QHlcpDxG WR4HWB4j6Psa8iiGPMopD+GvXLZB63q0oiB/HpTjGcpjRLQZmccI5XGB5XGQ 5TGK9Q15lEIeMygP0S6k323r+kKFpy++r+yj/015jGLdUx6jlMdFlschlscF tAnkMQvyKKQ8hK970dac1vXFiuXhHLDVk1Osj8MZ1Ufp87+AciyaYn0cyag+ FhWXQh4zp1gfRzOqjxU3fGxf2WOOKdbHsYzqY+72BdCuzk2xPk5kVB/V317O 6nyy+ngqo/pYceks5PHpKdbHyYzqo/qmAOTx5SnWx6nM6mPUBXVePcX6OJ1R fazogLHksQemWB/DGdXHNR/ZBLa6b4r1cS6j+ijrdULbvXKK9XE+s/HqrveB rVpZfYzYyjHe2K7qIxfyuGzC+vC4F4OtGll9jNrKMd5YouqjAPKYPfH88dCD MF7dwOrjgq1djdd2VX1MhzzKJqyPht5PQzk+yerjoq1djTfXqvoohzyKJ6yP wPufgjp/2xTr40hG9WHcnwt5bJlifZzMqD6CC/dAfbx7ivVxPqP6qH/pT1Af J6dYH4czqo/83bBmeOxHU6yPpzLrH9/8NyjH2SnWx7mM6mN5YBWU464p1seh jOqjdOud0K5+NsX6OJFRfSza/XsoR+4U62M4o/pYsewC1Mdvp1gfBzOqjznP nID+8d0p1sexjOrjqjc+APVxzxTr43RG9bHiT/dBfVyXMp/PFemN0N90Y5QL 0p03YR1cef52Nn7IOVymp9I/kcbuRZBuxYR2v6xzG1t/yHlbpqfSTzc3uCFd 98Rr2T0bwNbFKXO1TE+lfy6NfWdDugUT2vea2i+AHZomsO+BjOxb9pvPQBv/ xAT2PZyRfZc/cQbS3T6BfY9lZN/aJ38O9o1NYN+TGdm3cMFzYN9/n8C+wxnZ t+HgOrDD7yewbzIj+waWnQI73DmBfQ9lZF9HdR4bV9PZ92hG9g0O+kHf+gns +1RG9q3/3I9A3xcmsO/pjOybd+FR0Pe3E9j3fEb29V5bAe0sMoF9D2Zk3+WF a9X4INIMGVLXsnHbmrLxNEh77oQ2dn/jOLThhyjtUUr7IqWdrj8rOxdC2rMm /n3hhXxI++OU9gVKe4TSTjdmKlvPgLRLJx6Lay6oNifSkmmPUtrp5iVl7wpI u2hCe8/ZCu/hj311EnufzsjeV33VB3rvm8TehzKy94qX/whp3z6JvU9mZO8r W2aDTb49ib0PZGTvy356BbTvjZPY+0RG9l7x/npIe2QSe5/PyN4LT+DvA+WT 2PtoRvaeeQf+hvLYJPYezsjey4dxPrxjEnsfzsjetRuOQdqBSex9KiN7F372 JUj7i5PY+2BG9m54/gjU5f2T2PupV25vtT/UKBituKc0XC32MKy9AuTkyn0e yEPGu8Di5bN4+bZ4oyxeMYtXbIs3ouKpfQba22hsNIwPp+OYqr0yzbDFco3Z Swrq/RPZDkQZIf0HFiWdcn8HdCjcnjMsuKQijaZx44GuD5jJ/DOLqhxTjOuG uM4pxq2EuDl2Ti4+u88JdYF7XMcvfe3PsMW11v4ZcWZt+2MXpC0ajX2FyUt4 fRb3epyJorOFScdQ4cilhxYlYb5sLLLdc9I9d5p7OXSvEu/hHukk5TszWflk nx5TNjer54tj9vygTMOLxuYN+f0sw/xKxuQ3I/mmM+nzePEVc1HxaAXDotbV ery1Hl+Vt67BF2rw16fBolr/Jf78rX1U9yXDyL1cgAl1+FVMvpaxUBlX1LiZ yVEmMw6X8QSTTzFuqZvJjPvm6GfyEJM/zeRvMvk5Jv+SsUqLmBxiMmNUOfuY fD+TH2Es1E8miMUE8hcS4qyqkL/KWKinGMN06QLNNm2okUwilNckpdwE8g1J ye9YC/Jbk5LZsZ4xOwzG6VA8jp1M3sUYHLsZL2YPY8SQnIOsyYFLly49zDgj 7lRGTE4f6Pku0vPvk1JuYpwjg3GO8hkfpJLxQRYyJkiIcY7WMs7RNkj//TUW JzTnn5JSRpt8DOT7SZ8nk5JnpGzyANNhiNnhISZ/iM7cobyfcZceYdylRxlf CVl1SZI/Zki2EMofp3NwKH/CIIYoyJ+E9lWuwy1e0iHGSPoU49E8CTJjEjk2 aW6RxaYhOQc5gEOS4yN4tUOSL5PzNZJH09edePbbNRZfNef7SSmjPX8C8peY /b/MbHicMX2+yuSvMRueZPX4dcbbOsXYVcgnepjk/zAkzwnlYcauIjnnf5D7 Jsvlygf5hCyXy03yyDisJQhyzQGlvkfHJhclpQxJu+pAfoaV8Twr47OsXMg2 aib5B6wsP2QcolHGvXoB5Ic1C8nxB80JcioGGZTD+ZTmIuUwLlLOvZqLlPOi 5iK5lA4/Qw6wZiTlziP55yAnNC8pd5TkXxjGtLWakTTtkGYk5an2/2uQBzQv KU+14d9Cl32dZiflJzU7qcCl2UkFipkFZS04pTlKhYq79CeQhzRTqfC3mqlU dLNmKhWd0Byl4hrNTiomxpljGsjUp5CNW0L9BVlPJYrNVCDPNgu50DCmUz9y FIFMDC8H1O10qhdHiWHMINs6poNM9nHMgO5CZUTumVvpWQoy9XdHmWGUUjtB fmJpO8nQ10uPkVxhGGXU9/HcfRm1H8cckBUraq5hzFTlhTliJtUjnu+eeZ5k mGPLqU8h27ec7Om4AmRqJ3iWuEKVF+aXioMkw2pqlirLVSBTO3RAnrOUnvOR +UkyTEOzqT0gl3A2tXPHNTBs09jlgBVMpbL/tSCrcsH9SqUb1H+lSt8L8nCq 7FoJBX1Wjl2u1SRjH19HMvbx60mGLu26geRk+v4u0mypMRyKtd2TlDL2910g 18v+7no3yA16jnAs031f8MGoXzhez+RGzSlzrKTvNFC+TjP4BAf5CHuW+HoO mNMdrlTZdTcylKns95J8YZyxGuPvraE5AeQPJ6WM5foXkK+nch1OSlapKtdG Vq5NrCybmbyFlWsz0/9GPZcp2fV50HMT6fxFksfRWcQ/DjoT/9T1dFLKqPN3 k5L7jDr/EOS3M53DTOftTM9WJrdpfpwIp/lRMKO7UmXXT0HP7TbOnTuVR+n6 b9DzFtLzj0kpg565MOA5dkg9c0tB7mF69jI9o0y3GJNvZXrG9LrI0c/aD8m5 laBndAI9Mc48a10t1v2ToNJknCwpLUtKexVJaZs2rtuAvq0HTC86zxFfYpvo tcH6JPv6pkB4VfM29PACyofQrVFEc9N8y5Tnc/kto+ln6C7yaU5fWprqY+Sg 4BLhVw0BgQLYtLKpad2GN4BKAew4YXiTbsPPLPsGB2KD+P0nMtS0hM7zY34D nceIry9NVHEdujNaA6VTwTHpbAjv3RhrR51td1PSBGm9TLa7wS/xX/A31tIv gv2YypruKNQbJtLe3RmJyyd5egLyYdYxvzksoXYrneb+lmi8o6+/t6ED0pLm jJmh5YuQLIafZGC6LQ1whd+Dwr92+Le7wazX34gHjNVR8R0wppDGSiGjRxfm FvjXFBkbPcQMYIuOVd4b6W2L7Rkvh5RHKDqyP2zR5efSsZTYU/zONE9+6lR5 nr4bLbd9dwprsnk4t42k+a50WvrvSi+DtZqjmOLDmv7vcO3RTtc+w7gc13sx un49vQ83OsZ+V+pK812q/TtT5EIfhvzupu84N9G/7XS9TX37SNct+FsGsoDF tZwbeGuhbz5lTVL9M8uzOlP9STd91UGs3mW1ZwLFs+8aPfo7SPx2S3276YS1 alGBtIkT1uBF9J2Y84iO7zzJnsVPw17J95Hb9PeRuDZwU7gT8pmh5N2QPsk5 kFcpya5DMk3x+H4pY10XDEgZ20nhQiljHReeljLWf9Fukve/yt9Bdk3hO8j9 Qs9Jv4O8ImRYPPSJvoO8Yq96v07zHST7/ucKWCsW3cb0UN/7zU8tx7XN9Fuj vRxLU79v9AzQd5X5tu8bg6nfN3rxPeWWNOm9PvV7RNOg8ubZvm9cZ4vXTOF5 tu8bm23xcF17kOLlsnhh23dR+em+b/xb2/9fWivgbvgp91/tK8CJv//z15k+ /v1fAL//MwN13uz3f6+J7//W730Vv//bpPZxcB/otHN7TeKjVQ5nQn5DhnI5 fasFsgHhxbSvcyeFOSHs7STngNxN929X+z76263kWvad1tp9zirPmauPH4F+ cuRMIfTrwu2XMI8yvXdUQ/tw1n2V1ulCo2BfYdVN7JliHncIwjHv2SL+iKHy ddP3fhhvGOLh/h19q2V9ywh99gjblzriPn7pHH2rVs3jQVrX07eDaLfFZ3j5 aD+M2wyvH3RWVY1nE0ivEP/inqA9zlnnyGIWr1bok3f86Bnxjd12696DEDZB +lfi36SMg/ZfzL/1fBDKC9fufe4qD05kQzOrjCmmW4R/h0lvZfNhZ7KGxXHy vT3xkf9U9vf00Cl3+fxifVDrNWu9vipvsMHna/B40+/yzY9XLa+qNoybPbvn e8zd8np+nP72WD8lzF/bMP/6hvlbqua3Vs2PVM1/c8rz8+PVdH1jdEe0b1e0 Cj13VM3XO3yNC6+6Bv8xVQu8S32wwontESg0VNmsWt+9szvaGR/oi1atRmdz EDUeiVeti7ZZc5sDJtog7hOVsP3Da5hcx/YS17C9wS4mv4PJjzH5C0w+x/b9 5jF5O5PfyeQkk7/E5O8y+b+Y/Ce2HzibyU1MDjP57/n+IZM/wfYSP7fAUNOV k+2FOn+l9xJzcnV4zmKQryIZ9zCvJnlVQq5vUMbfVptI3pbQe49tbE8S9zk3 qv29BP3WBvJdCfFOIeQHQG4lGW0VJflQQvirEfL/Sci9R5S/DvLtJH8P5HeS jDa8i+Q/Juh3VVgezQD5fSRfmVAzheHCvV/1W+/7dLlcuIe8gmRsA7SGcj2e sPxyuD6XkH4sUP6KtoPrm9oOrrMgv4Hk5xPWWtaFeq4j+dcgv1HKubipdhPJ hdo+uTO1fXKvAJmafO6ShOVPJHeZrrvcm0AeJDmSkPuiKGO57iH530H+AMn/ kbD8/OT+AOR/JPliwtovzX05IdecuMzGfXja95uGdXqcZLThSZJxT/vbJD8K 8lmScU/7P0n+bMLaN5v25YTYyxLyNxJiL0vI30mIvSwhjyRoTxRktOHPSP5t QuxlSZ83CbGXJeTpCbFPJWTsR78mGdvA70lelBB7TUL2JcRek5BfnxB7TUJ+ Q8JabuRtSoi9IyG/LSH2joTMziDkPwzhs0g+pMML6hNi70XI61k4jBW4fyJk dhagANq5YwnJz+vwQiiLgxxiFS5l4e0Juf+A8q6E3E9A+d0gU9srxL0C6puF Dybk7/coQzt30Dt/4RMJ+fs6ytDvHNTeCp9KyN/FUX4aZHKhVAjt3NFB8nMg 7yMZ6sjxYZKhnTvo3bAI2rnjEZKhnTs+QnK5LksRlMvxKMl1LDzC5EeZzMbk 4jyQP0fyLJC/SPICFgfHavppvPjWhNhrFTIbt0twbKfpq+TqBO1Pg+xjcVr1 OFDSy8L3J6R/HZQPsvAfg+wl+X90+PT7Epavr+kPs3CcL9aQ/A0dPuMRPT7P eCYhffSg/FMdxz2HyW9m8gUtl7L2U9quy1g6wMIPJOS7OcrsLEzpj/XcUfo7 HV62GeRrSH47C/+S1rnsJIvzQkL6TUP5Nzr+TJPJ/6bl8o16DC9vYeH36LG3 /CEWflHrWf6yDq/A+l1AMmsbFXhOZzHJLP2Ku1h8VkcVR3VdV/xfFv5jFp+V a9ZcXd5Zi1g41iP131n4LL2jzfqFjjO7WsuVbA1QydYqlexc0pwrmPwuPdfM uVeHz/2dnkcum6bD5/kT8qwKyitZeBuT72HyJ5mMY/UoydgmXyD5Zd3XLi9I iHMNQmbrnMv/EeRfkcz6+JVv0XL1kB7Hqg+w8GdBpjG2GucI8o9VzfpaDdqT 9hVr2Fpr/j16rpzP2s8CnJfJz90CdnZsARurr34Pk1kfXMja8MJ+bZOFbJxZ BPORg34rW7SEhZ9PiHMBQmZ99tqPQPi7Sf6UDl/M+viSUiYzuy0N6ra9dJUe i5ZuYnFe0nLt25j8iH629nHd12o/q9cAnmId38PW0p6nteydyeROLZuzmNwB Ms19Jjsr56thMvZB+h3R9y863I/2pAnb72HhH0iIMx1CZuvkALwLOOicXWCr Dg/iniqte4MLaqy+E6xPShnWfEE8W/cmdg5oPTsHdD07B7SFyeh4TJ3luYnJ OP/uJvkt7KwTtlU6e2K8nZ0bwt/71BkfXB/SuRjsy9Z5MZijHepcVQc7O9Zp 0FqhSfyGaZ0d22HQnnuT8H3nUOeVYE3uUGeLbsXzkfrMoOOIPifoOKbPCTpO 63OCDnWW7TaQ6XwNrtud6uzSu/D9huQ7QFbn194Dcpc+9+eM6XN/djmIbXiD 3AMP4ryzEeSjIONchmcNjtjPfZC8Xe+TyzS1HExY74/sBXWSnXMeM7t/nt0/ fxX3z6UPVrhS/v2D6OI3HOvaE28RzINm3Db39+sdc2h0CjSgYw0Iyg482NPS GukRj2FRBeMiqB2AK7qzijVgBgwGjgcbhUQoSt6gQJ2j6DNFBGNQRfBKWUap F7KMg3vfA70tu3V8uhA3YgSeFDfoQtwI90Ra4ixvec00kAFcD/aIl4dwnfhT ftFE8J/IpW75YCjcbkFrwmCnkGUnn7LTYDjlofoxD/k87LiCegjbsNJL9Aum kdBkUKUYMNoU2gI9TyvZZ7TJqCEjpsICkBbxZI34nrgEzYfkCQEp9nV0yIe7 o33yidaeHZSQz+iI66sAXHV091hXVQ3NPu/yyHXhNSvXb0HE6nXh5s03rhZY 1Na+PrCiICr50HN1e9AvZHOsLXxjG9qgfsA/9oGAxrSrB6AQ8ciArCIwP7us x0MAJLV3x3dYhqszenpU2YOYCTrMpkxiDb465JsPKtguZqu6u9UberTlQ2MT qJ80gR3hjp4B0jNgyKrxYX0hFT0u67y35ZY+qsheqCASYRaiyhPEX9lQ+sLt kZ0qeFAmh6GdWhQoXxUlphpDX5iqvt7YEdkj+4pKFtqPUqxTCVYqAYNyBI3U zdhAF8JjpPbqgpL1wwhFIb2DA5HdDc1+D5LcwqnBikbjRQumudXgNzXbRyFG bPGEt31/qsXtccSxFz9iqdLdCfob/P40GghWVmAMpmqcPPp2RSP9kJRPNVVy xmqPJ6gLPr86u7TMsBUHjOfR1sMGAsYLCtBKSqiyXV2K5tadBkkC4vYS9yY2 l4iiNFQUmdTnQb+g1k8yIQRSJ5wSiFhhJHdaUxG7JxIJ2ZqITAlhOPZWopKz J2XdFA3TZjRKzpuSnLqRLjV1TyTmNcJ90bYIJGAiakyngKGiYQT0ATVR48iC 0ImJaJgQTODd74jILhFXotdAf700kKvplUTZu2QMNRlG1aKHpgs1WVhTBfZL 9IpujSxh/URYPxJWz4TVQ+FbB6EszYjbkWuBkBqyxI2BgF8ogreaEZMTGtgZ hlFLjXVwNSgv1QIJY7+jL4qWC2L0d6ADYain+K5I3KIEQWh7fED4LNZLq25R YpmTwN50D0gqEQYpX8fdiv1h+TqWWcZjoEUzsm3GahgdqyFGF9UTkpcD/YPq WqpB6dWP0SNk1yOkYUvWkyKpeqOrX1UzTEEDvQ3NSJzxBQd6hYLKFr1oIcsO cNnVN9hvIWfwdnvLHgs6g9d9UQ2dges9kZZ+DZ2BgF3yAfLqjDFkADl1hoDu eLskzChX1R3tEi6O6wCYkLSMnF1Q3IssoxDeEocQLZ6MT66FEDosU8HoA0FY KfbtRAsGfYid6ttJICiPot3tREgTr3yMjpYKQuPt7oNkOuFh//LIjes2hm/c snrzlk0rV+HCA6+3vHmLvPQuVrfXyQAT1iP0uEjMj1eQUABJP3gD8mlAwkyQ mgeFcYp6GMPksqLBF6TapUQ7ejobghbjDAM7cPpsCClujnhYOvj2hUQN0MP9 kbjgoFgWx0BUMSCk/l2gZZ0s7ubVK5uopDdtXtcsV1kykniiDslVyF7uRhtB kw/6o23Ioepu1/SqNlC3tyU60N0Wt1yJRwn6F1DwqjbJiero7dmjYUkqlLGd oohf2tndFmFoJ8xSstExA2prEKjCgkjQtCBPcGMwCkNFe4NFtqlbpuk8y4wN qzZuWBNeu3JDE5LF6nBBAM90ITEeId1IlgmGrLK1Dfb3Nwg8OBGzWoidJtc2 sGrpjMDoX4fDWg8Mxsiz8yrAKN3VjU/h2OABQQKzUrNIbC1yTrSoMl7fMlMg lsTx4t54pyAz1dUJWG28M5WtpQJ4i8cwbIsIBA8qP/UUKOMRshaCWtraxDZ6 nNVISrh8wALYtln64PBl4qXobUSho+udkR5LGxGUwjWDdTZMZZhIyCNYrSI+ dRpROjWgYso+6ynEdofZCyPoFondCqngPBxXJGuEmYd8y3fHwzvkfNlgkfFE fLFYhSmYrkQraA5hZUISkrMZouqMEy1aUq1COokuWpqGYG3a3Y9jUUhUbqw7 3NEH3Q2J6CFyug9hrS2QSEiR7zAgEo10gKYKf9YdjuBavKub094wYZGJeEUK QQe+YeN1bwzfuKGpYYl3sZCbVq9BbjKK2LFXb1ZXom9vbqBoq7aq8OtvbF69 TV1sWX39SpBhOu5rvUXkBDPJYH8UpvoeMbOEQmBGK6SB3VTvAgPycjAKCsL7 qTc4EJcWQLJ7iPrUACLjuvu6ozsbQuq8/TKdGDyK2DhzIA7JhOopAjxE9Vvv tV7UQl61soXbMCJJYid0IsxW4W8R9yie36UqzxTARUwRC4ogTdnlkFWrcKpg 4npzeUQYKLyyaeWm5nVbcU6QAVs2rdsA1ky9G97SvLIZpgUdRYb4KKRpM0Ta HN6wUYT6U0NFWMCeIlZoEGpkh379EIY2DXrTqcc5L9wXa4GW2lCvP1cQS075 Omgt9et9olSB5ZHNN4W3rF+9ehOUR4lSAS9ep+ppsiAqDgasXrPyxvVYCsgB 5wqlmWic9UGRB7U6kQm1R6+KD1FhZQ+iqJTmelyFmVZBQhasVBREsEoprni0 TuRSvzyCbdZSxrNYXgplZVY4MWnl6iFHDEG+hSfFcJa15AP4myCs8XfgOn0n rHggPoLwrPgEDjZUBPmEF7WC5cnyyKqtTCm8YCq17bQUgrgC3IFP+XC5hrQQ GAnU6NlPVESf4oJkSSOvGdIIQeYgDH9ipbCQlX68Mx5FSxNjTgb1t+3EIL9O v7sz2tKDqvlDKovozrb4LggheuD/svctYHJVVbqnqjvvRPI0QRJoSMAQQ7rO o06d6g55kO6Qlk53J90J4aHV1fVIl6muqq6q7k4wSEYD4ogaIGBGcWyZOKKT T3EAjSMYdHQGR7zGDDp4xZngdS6MF0dH+a74uty19l77nFUnVd0JJArfdH+B WnufffZe+/1a5//RJ6O8FHdgOj6ULctZFAoQpoKNsbaO7evbobVtjHVt7cSe vDHW3bmxp71zwzXQh6VjW4dwmiub6aCVInCuTLXHutZf3Soeh1ZKB4XWybm1 dUP7+rbNYt2La15cRuoh7IOxzp5Nop93y/WkDoJcTRogte5o3QBJdsc2wEPw wyFjmFLWQ1emtnd0dsC727e2Xg1vbm9p2wqvbb+qHfXcvmHTVnhhe3vHNdB0 tm9s29gJ4+H2ls7OrU2RldshpxtgPby9G/WMwkuYeEjFL5cFIW04h8tmSAy6 sB0alnN4lE7+hhW3Ni61bXDKL7/C1KmGY8Pp0gB6pZL9qSKSFRr4aRkuKOBJ k2qIwzA0wDMLn4XxGaaZL2AA2S5FRBjEUO1yGFn1UvEB8LPxtQi8ViqLiUg1 1GHY/e9M4SzmYIgohECPJtVqhxXru8ulPhwrwupZdDNKVhJvuuTpw0iECwUA keKZv27oEKn0alLtFzTrL6pAmF0Ds0t+gtpWNWsormEocV20aTEiiozLkscv psTBiG7AcipqD8flXo9WdsNxT3s5KGAArCq1ZwA3H+DAWTG+gTuNG52wW8bx GKaOW5Oo2g+hHx4sNoXdQotLKnBDckfKMHE51DiKCh5VUV6YN+mVUF7YN6UX FXc4ouJGhlWMHjIRUmrKQaOESdqWSnI4IfMaUbyaw+pECMpLKw5gueFcvVkQ IMMkuhm6RuuGns6t14mJpLRnIJ3PZvPYDQ2YcDs6Yxs729s7r8VBQAoYbDiR 2p3IYpgIhulo3bEBhwnxg89hOMeP9uA5jAIbtopOipPW1s3XdHRiX0ZJdkp4 2rm1VQwfxQGpaNhTQ3rYlKB0RSh66XK04VIqodoEMpyGhkvUKGiiQHc8keV7 ZPJK5criJI2aBm6T0m5IaiDKU4V16ZdVulKPqOZ2zx7sriU9YgznC9CFcXNj Yrcw9SvTtOrHJ4lsvgQt1cTOYJr4iHSDZ2JPoZvY9c0wPiIN4dFIMYPsl6Za xaMfUq7DbsjEPm9GMLxqzvCwlCqn8SF2dzMqHtquEjtTZVF2OtLT65bQUI0l 8l312B0/wBt2bimY/CBOtwPkC7RzhrCYI0vkSI0gmF3ZJnQLM2WFZX5DXoYH 8sP4FLNgiSyowQVjxs6mW5gDS+RADSriTbGd08OYgbDIgBpI4OnALiRr1sOo UlioRDOleHVAPkSNwkIjmjFVFcjHqFJYqETTpyiZPQNSqzBqFRZa0VSq3pbP bdTLFnqpDg3P06U9uQQ8RL1soZfq2ViduTiMClgcNqpmo2qyl6u38SgGj4F0 W+hlR7yWQzsSpAbW7ah4k0YD+XgopwKsjJi2V9Ep8IugrhGha8T2am4AKhUP MfSI0NQJeYoUZWTIfqtHRBE6XiuGiSWRwocrHZuXTHYYI0T1I0J9x2vJ0B7F bKTjwYIeEcUa9dpyYYgeO6ipIzSNeq15AFZWOm7OdUdoGvVaMlSmfIqaOkJT PPTDxzdqGCCZysoAqJcjO1HIa9wFGI/gIWrlyE4U8tp2cgiLCPejelR2Id1r 2oV4uR9PuyAAahY1ZQCvdWOOMnl4jKpFpWq618AxctG9o6hZlLq318TxyEKM JFFULiqrHIZ7PgCoIdII4Z18SKchgg8DLMhKGKq8SpRTNPgb+KrU3lSLRjXo ydk5rGExpZGmPYSnHemkOrVKISF8qckhuuai61ZzvHxR3hNbWi4tbxXDmjwt gfhgSI0ag7FBQX5uhPDb9RAub8AD9ggyFXU+A9tzfIxrG1gh9zXRyDoYy8bl UxpPB2OSnlgXpaLWZ4NyvAFfNYwOxpCSGAd/m9KRKzpLjZWDdGWlBslB3AwU Sjd5B6aDuM8gH4ci7c+MxMviLotihRlPeoQp1r54LlkATZAvGxaJkFv0cRdV g+66E4c8WAIMsvWfGszAD8aaQYgF2a1hOQnLLuGhhjMoBRGrLkcwBzxG4lCm uAYLy2NhGYf0idjSJ5cuFYdFKdHQhfG4XhalnSzGoYJyYjUcMSiuMmwy82Wo fdtxvOgHcYMDuXcXL6LuZZOAhiB07MFiKBnOYJ+qOmpg4KHqhCq7z2sMqrr7 vAZAVd3nVoKq6j63FlRl96nKpcpulroIxXRDG0xnUtlkCVWDpdWWTW3XisXO FlgsidOPLZvX7+jqvh7WOls2t3WgZK7csqFzWweedGzZ2La1Gw9ptrSvh18b PNrXXw37kC3dPVu3tcGmy1m5BbcgUTxDkynJhMN48T2E52TYISBxWxzeZmCr mhsaUMcJ0k2nuXR0m/EaJ53bZrzGSce2GX+5gI+vXEAf0fV6sB+WrNBgRgzP UCURbGeOu9iBB9AsxANVN5nYoFgYoRfVDXjJFRH6Ue2AXzyJt0vopypIqI9j gI4n9HiIbatkBhAsoskQhkdiE0JFJLzdvpqBWVBqo3prRhQi+YVV2qqZuj0W 1seid5XjfWi1ZIiz9jIs10U5wJhER7plXKQpL5lj8BsY2u35ykxL3xHXV53L 4vgDa35MxBSn17HBMqonbKBCYXURMNiXx9yqFp+NSTQN7wwcSahjxXIOI8Ij FOFOD0FPNiT4R0RMFiI68QyZzt2Ggu+XpUEKrMlxzyey7VxZCttJ6BTwEHXC WjBIJ/CWF2ViwatWtOCbzQygJ2kGHngkpYvm5qCTdm0wq1rSwz1qxd2t8JHV IboieoOawjsRT/Sn2MIcvAaw7LCTU8sQyqZQKxxHYcEtZsioqxuMCeq5ahLg Lawnoqo9uAqo/KlG4T5QWaTR3PUXbPamu1l2/YegWZto0pGCtldMQOFnMztz +FWva0Ik99mmdYoJx5BuiwM9nDrV9rJZS0K+ZXU5mpj3enAOLJmGGixDdFoO mYMZWLhlDeHgmeNDJVSQ0ls2yr7YiPKggu4TxwDQAmCHAi3ALe2+mJpNsIid 5j51GiJrBNxyTseSdo/GB5TqoagGuxnZ+GE/A+MKOGEJ6q4khBMVgVFGD6lz TPSFRbFF6otANB1I/dEnVSzmi97VM3qJS3F3R4Q+6Uw2q3u3z8KrYm5XgRCw R9z+ycJv69zQBfrjNgsU1xL48WhqEHMBVWBZiUGeCXSJPKhj2EGuPbjEdZ57 pQkeYv/vjsYJd8GhjmEHxZ2DQB6yxGrGbeEYltS1dM8aSWRHXpNIXUsFUNYy hLKFCmULPmULFcoWZCF6yuKKNqkzZYWHwZQtcGVdPQu+gkYPpbjpHt7LFZU4 vcdtL4wbOPXCrnLIsqjlQPkLzUPNqhagElaKHtjs5tWQ9kVhGtahm2byORFV GE/NS3lln0SDel7s6SCYu4gFr5Ei3sxGaRULHr6ZFX0qZ1bw8c2s4OObWcGn sguBB7ZdSNvtRTJmzK07ZoEX5o6ChW25sM7kYgXXQhMcyhDQUg7MMna0brxi M2DvPSTEWB840CyqFOvTm8TAA4rE+gyUHSmbQkVbOixxDYbDd7MsMhHLCMQS FbGM6O51dGzEwHs1qaEKLHSh0m5271PpahumNrT4DYkpFxT33W9TJt1ISypv kDU1A4PXTakirBvCujueGp7xC+weZX9FiyknM1CEqTlbzrixkDV1UdrSpHFn 60XerMViw/GYOMcsW1EtDTsyackkDtrKRtgUBnDyZEmatbnzgrTacOcV2XJi aqITMyR2BDY/NgtjKZwpQF0Lz7z6K6/s+3EygQjRjIES6BcFUnFJ3o/X6jvL /W7jlGFkNmx21JVLqcTEFXSuMrHcqYnlTk0shxYe/O4ZbTQoVrQONAqVsRZO jbVAhh3eAqeUKg5THMLkqlQZR+nUOEqyobgd1LMVcRWLl0ojuNNAayzTLoz4 9BqJUQh3oQReQ+wSDZw72REzOPHIwrN9AA+C72DmKPhSKpGXNhJRFS0eQHlG KOBR6k9lxVjrXZ1RVKCvsPZCU5dC2VU3Eatc/Sfw8E48puE71ofray/7Lqzd QDybpb0F2n1ZoTgetanmmy/iaqPknqiWBshJTYtc1K7A1Z/0Zt4hNzTlPu15 yLwPefFT5tPMR+Z9VypVgBKrWKBjYQ+V+2PC9MNAsy/DEGfiNIBlkmr4oqav RozhVKKcxxnd8FDk5AIW50i5ELOZ/beuLKaatfXbejbFNrUgRKCta8lMokxW pYYNfdNyZAXYYc/kzCB7S2mC52aI+gtlZlv31u2pXDJf7C6kEpl0JtHknpjK 1RweABq2e1rQrLW0beiJre/pEZpYUhOZBKgSwRtR1EupQzq4TmXLpJSi0wFK C5c1dsS7LRRpbV/fvg1HNzsigeygZ2REvvEcPmr4UsLEM31D5VeS4yxZK6rM wowtfQzXHgvmeChYXAxDGwqR3hFc8UPnh4GVFBc6x7rWt4lSimqiuciRP2Lg 1iYjvkhQlwdDyYKaWuSsL1uQhU1INawwDtFeA1opLeyaS6lEMVUWPsKEBLwg nSG0IzXQHsywoyp7if5MNolm7k3uube064wPFDDT8riHsoSbwIihTrmp/W1t 3YJmmgZMPfjdlzRTHhZ4jFo62VQwIrhKD5uaqCJwmlpSLNsiohVFNIVBGVH4 jBZMj5qYpMRZrH66uISzfDiE8wjH7KoqOIHVcAjPFEfwTQr7jnACV7hfmdOH mT531Ofe4HNf43Nv97n7Ktz8SzsJQCg/ePLXA64x01in8GConNAEXI5wx2Ji FavJdmcgHpTquTtTZYqHwA2SUATT6HvBfpBnklwAbRSu4INQBdOoXh4GeSbJ J+ld/JbxJ/Quys977yKu+AwlW0zu8vAPA7spHkgzsJfiQXk/i+c+CoPfXY5S GJSPsDAMCzHwNIvzGRbnT7zwwXrEVSB5EYW/HeTFFB7lBk2brsKEKAykH7Qo DMqrWZw9FAbKLLiDwjwoce5nM5zGSQyncSrDaZzKcBoVlmNgOcnQ5mdC+U4j /zf0yvDB3a8PHMXg7vFxFOsWeZ+wjoWjWIc43G8dH0exfhmUU3J8HMW5txPO 0jg4im0zNYF9L9KbVhtH8a2LTw9H8a2QbqA8Po7iNb8/PRzF9qn03fY4OIrt XdVwFCfs//449n+rGnHJfM6gH08D/9GGiZvjP0YQ/1G3wvYE/uNrAv8x0fWn w398TFP4j6NTjvUjvuHx4DoX9+8uwgRU7gNTHutfIPEA+3GQvmteA+L8eeHh ueSku/hnZ/qOwhashqE4l3jLTjcuhjsYJexGFu9jvRCul4ejfArOOYZR2XIi 2LD8xJsfSx6f8ljSh025IECL0wNze7XK95AH7bGkclcP81jyRPDiBox79rGX /2OsuLg+xPUnMCI9vEqss97lVcI53K8WFuPH/texTZzL7f++ebRL6aLqAOKb dGKFyttoy1PTeyc/taIhQBxuxHk4OhXSnF1ZfqDfm489iBM/lKW27/5exMNc 6D6f3jB5VGB1HnsQ0jpy15RjR3i93I8YnL42iTiVSj+ot9kHZ2tz3LY2u2H+ 8cixnwqdgw3zIe3jiHXpq7ttleXNcUmRCxbyBe8JXrzpvUslH56LjYr6T1d4 qJP3ac0KB3X+Ps2h+C/iGKc8P5DHJyvSOO/Ydw4Ge4OSU1GGx+dcHyjjJwln +Pjxhcf+B4QJwu9PIe/ThD/kF9K8wK8/1NnkE57uiBH6GdLhCSjnJzAs1Fe9 L+/1J2Q6PwV58gkZdz1vN8cF5ii23dFN0HY/TX7tVDbLlduX5yfxef0+rYHS QvfPocwWV9F7LrW1GuUk6qYduUfPtJzQfc+KhtnIN0n1kiXM1xeOG71BKJej fjxYytcMFa5We4fyucLtf8GGRb56fxjTvhvSvtPona3GOslRKuJahBzH3ph5 7OgJoWuv0PX78OxgcN0MPjYoXVDnin7H0sE2fhD7SVCbrrhCfek8Dbo9dRz5 Z+WYwfqv8AueMNQYI/rg+ZT2U8cv6a0XfXhuQ73E1G5QZbrQDQNlqvS5B/SB 8F2o972Q1tPw/CMsPTYeHYB4Fj0I/bzKWCWeqTqEMNP8YU4PVxaXZBJSNkzE kfDPaQhFmqxQk1mNOPLSUuOlJfXbmEyV4xmBLUQgl9p6PBiF/dhQNpl7c7kB DRQa8Ny9gb8wXW4kBKIg/XancslMbmcDvI9XjlLc1ZBPN2SSDZcmG8p5iKFh +aWly6dXrCsE5qzIxjR9ld1QiTdrnRbe7Mc1be29uL9hGLPLmHwFw5tdzfBj GSaeVmAywxzTHmQyw84KzGUyw6oKMLy+wL1MfojJ32Eyw5MMMLyv4CwmM77N 4DYmDzL5biZ/nOHNHrnMxa8Lfo2F+Q8Piy/IsPjqLmF4s6sY3myU4c1uYHiz HQxv9jqGN5tieLODDG/2ZoY3+z6GN3svw5u9n+HNfo7hzR5jeLPHGd7sswxv 9lcMb3YSw5tdyPBm38rwZm9heLPvZ3izH2Z4s59geLNHGN7sUYY3+/cMb/ZJ hjf7Lwxv9lmGN/uChwFY/2uGN6sxvNlpDG92AcObXcrwZnWGN7uZ4c3ewPBm 38/wZh9leLPfZHizTzO82R8zvNn/YnizIYY3O8jwZm9heLPvZXiz9zC82VGG N/s3DG/2YYY3+zjDm/0Ww5v9PsObfZbhzf6nhzc7+TcMb7ae4c3OYnizCxne bAPDm72c4c1aDG/2SoY3u5HhzXYzvNkkw5v9IMObvZ/hxzYyvNmrmH+Z4c2+ l/kfY3iz/8JwZWcxvFmGvzf9eoY3O8DwZkcY3uy7Gd7sHQxv9sMMb/Yww5v9 HMOb/TuGN/t1hjf7JMOb/R7Dm32W4c2+4OHNTv81w5vVGN7sdIYfu4zhzTIM xhk3MJlxC89gY/KMPzC82ZkMb5Zhg8/czvBmdzK8WTZuz5rL8GaXMLzZy1mY HQxvluFwzrqL4c3+JfP/EcObZRjjb9jP8GY/yPwfYnizjzO82bsZ3ux3Gd7s SYYrex6TO5n8rwwzlrWfOdczvNl3MP+PMLzZTzH/HzG82Z8zXNlNDEuW8TnP fYjhzX6Fhfkhw5v9GcOYXc7kLzL82FaGN3st89/H8GY/wPx/zPBmGXbrgrkM D5a1jQVtDG+Wxb/gZhae1dGCzzK82S8z/x+x8Cxfb5zN8GYbmP/3vXy98ccM Y/ZuD4d24cc9HNqFn2Zh/ifDlWXYreczDNLz2XrmfDaevCnizUFvYpj2F3ye 4dB+hWHJvsBwaBnO8JILmMzGtyV9TD7kYa4uud/DoV3yEMOh/SrDoWVrpAuv 9nBoL2T1cglbgy1t98a3pYyTfOk9Hg7t0r/ycGiXMrzWSz/t4dBe+gWGK3uV N4dexvrRZV9iOLRPMLzZNoYxy3Dgl7O5YDnDpL18hVcml9sMb/YHDIf23xne 7EEPh/YtjMtg5XYPh3Zlqgb27DcZriwrt1X/yXBof+eNUY1TGd4sw04PLWDy Nu/dUMLrg6EBhkP7dYYxyzB49duY/C2GN8twkg02tpsX7nM52E2GlW0yXGhr LcOMvc1bD9hsvnD+zMOSde5i/i+DfyNdjbLxM/oOr99FdzN/bD+bSf6S5990 odd3mq7wsHObWP02sfG/OeZh5zYz3PLm5z3s3GaGWb26x8POXc3WHlfO8rBz r1zC/P/Ny++VP1sm8WxRRvLd6yVs65o5IN/AsHNvZNi5b2N4uUkmZzSXE1Xc GSlu87xG+W+RXPcKO7co7xSFPMSwc0c0l18XMWm150m+meHo7pN3i4p/PrDc w6R1edchnUCPh0MbUDrcJu9qFRd9QOlzO8PRfZ+8nxXy++X9rJBhnRxQ/N4f YjKsjQPEgYx89QGl810MU/duxhlO8hqsl7dJXNw1yOsRA7kfZBzfel9++Q8o 4540DjLovwbXJ30g99bAy33Qw8iVP+TPuHxl+cgwMu8kf53JqNsgtA1ad63Z PyplbBt3jor7Ymwba+4D4ROawFZec3hUjoGq3v+KtZnDGvEwtkgdlfyQRuNv i+QnVhjIj2g0z4H8RY04D0E+ytoSruUUJzny2KvyP8baz1dZm/mavMcX8tcZ 9vITGq13Jad9QGEX/xNyMJL8LY3WrJLr3m0P32ZtAPY4AaXPCZCVDv/M2gDo GJxK8vdAVuXwfXlHL+QfMOzlZ+R9veKuD6oyOckwmX8s7+sVd31QlQ/Mp0HV tmE+DSrueuSrV/3Ox1cfVGUI+6mgwoX+BeyhVbn9CvlnSIY81anxAcq4TtX7 b0BWuNCwt6pTeNS/A1nx2/8e9+skw56rTvWLlz0Zh7p6xa2NJjKKwzwo78MV h3w9lQlyyNcTXjfuxepvr5TX4LnNYepruIb5JMiwt1yDvDB/DfLTIOPa6VMg QzmsQZz/B0AGPdfgGcKnQYb6XYPrnM+ADO1mbRDkv5FY1mtxX3lEYlmvRX6H z4L8IOuD85n8EsOyXu35yzKU/rIcpIz6r710mRwz4W/tqnUC6xvv79dG9rOz sxY3jMIA11R7K7N+R/La90CcN1Gcd0Cce1j4m1g872T+OCYvrpTX3uNhcYuD u/FguGWgCQTuCQTu1xICdzgygcA9gcA9gcA9gcA9gcA9gcA9gcA9gcA9gcA9 gcA9gcA9gcA9gcA9gcA9gcA9gcA9gcA9gcA9gcD9KhC4BV6DROC2QulYuQIf OF2JD5wWu4HoSickXRJbGJGyVyDyNQH/NtGYkVYrCyOiukk6JgC/EfV6hS5A 8YRbTanpWHwoCctNhdqrPqgnhBy+hqMhAWG4FYZ45DWIIe6MjSEeqYohHj1D DHE9NIEh/qowxHX9VWKI68YrxhDXzVeHIW6dcwxxy8UQR2jLs4AhHsaP9O3q GOKIlaU7Y2KIh6tgiOPxixEaA0Pc0DGEURND3HpFGOImRmqNgyGO2TXsV4Ah Hgp7GOKRMTHErQkMcR+GeIQwxJ3TxRCPjo8hbobGxhDHa4MzxhB3/BjiUY4h boY4hripcwxx0/hTYYibRgWGuOPHEMduYVpVMcSxM5h2VQxx7PqmUx1DPFIF Qxz7vBWqjiFuYXe3jJoY4qihZdXEEDerYYhbelUMccyRZdfCEMdMWU4tDHHM QjhUFUM8jDkIG7UwxDEDYasGhjiqFLZrYIijRmGnJoY4qmSHamGI26iVbdTG EEe9bKsGhjjqZdu1McRRNdupjiGOekVCNTDEETwHgb9rYohH9CoY4qhrxKqK IY6aRuxaGOKoZ8SpgSEeqYohjuo7oVoY4g7q7xg1McRRU8eqiiGOmjp2LQxx 1NRxxsAQF/cWoeoY4lHUKmrUwBBHnaLWGBjiqFnUrokhjqpFndoY4uJMLVQL QxyhwVcg0veYGOKIXRSyxsQQN2tgiCMIUcgeC0PcYRjikVeOIR6phiHuVGKI C/zgUC0McQ90uxqGuK77McRFqTh+DHHzNYMhjtYbgkfm9DHEo6diiCNalKSV OZsY4uapGOLmWccQdzwM8XAlhrg1Loa4V919XgM4WxjiYY4h7vwRMcQdP4Z4 9E+GIa6HKjDEFYT3KRjirgoehriLZcgwxN27CIYh7p19exjiSEVk6NEqGOLY ncUmZCwMce80xcMQ98AZTwNDPOzHEI+eiiEerYohHq2KIR6thiFuV2CIR+Q4 VYkhHjktDHHHhyGOA6gZOl0MccfFEIclfQWGOHLgGIbjxxA3q2GIm39MDHFd PxVDHMdRM1wbQ9w6bQxxswaGuFkDQ9ysjiFunw6GeORMMcRhV0QY4rrBMcSV EY3CEHdrSGGIu0OliyFu+jHEzVMxxAVstn7mGOKRKhjiusEwxKNjYIgL0qNQ 5LWGIW4JmPoowxAnWO5qGOJW6JxgiAuuEKMahrg1LoZ4uCaGuKfsWcUQN08L Q9weD0M8UoEhHvVjiLuA4QxDPFwDQ9z574chHnUxxGHv7WGIC/upV40hjkZU ZwlD3DxzDPHoqRji1tgY4uEqGOLR6hji0dPGELdrYIibPgxx84wxxCN/TAxx 55xgiEdfPYa4HTrrGOJo9vR6whC3jbOBIV7K7IzFy/mBTEKaH4JbWOUhgvaQ VYJhOysMCZUFhvCg7XHIjSKlqgUR7i3hEcvly5n0Hrf9S08cc+wwxExuvL3K +8LIF8XCFQdphZ7NCHCa3U6O4Qld2rWsoWjErKSaemXULrx1ia0kvdcMbmAD vgpa3RF2caVMpdbglujSrlI4eue8dhujCxQbDTKEYS8sNRkYtiMM5KPwG8Pm mRBQ2NICWLQrZdgrY4kYEIsRi+3KYMuICPMDao8U0CsPn91vIpsUmNR40U9X pe5LuGca8jDiY3Rz6hr7kBEAPo7KUVwXCotrxCZD2FJBrHJUj6pYy8V4QZSE irWQ8NoixRmTox2iW2NWvEOkmJwWT8kGlFFagF+XRGmm1eJJpUlQ3GLeFi+U 9pQScSgtceKDdnuxHHiJzQ/tN9x80EZDvCMCRBx39pBLYbRgi8mtJyodVRYf drO8vA1b0mgc67MZExSCakZi0Ws72q6Y167Q6OpVNCtHRzsf1XQco3bTcUze dBzrTJuOEz4XTcexX3XTcSJn1HQcR5bRuWg5Knui6uV6261rUflOCNuCOud0 xJ6npE4m0UrLcKKutZs8+RAHezgroJfcz+PJtBGVh780N5QGhV0bjc3eGQYl JhOHNWFSXpwbUfPKVFesqw3NT+EXBR2Fq0EwQOiGXxN+N8CvBb/b4DcMv/jc ht/17e1NEfhtvxZfdVY2U9TyoxwTXHncYkQtSKazK9bSthFt41Bc3yGSAqkT 7wRR2AGSKaLIF2QEFi4ZEsIg2YjiIWAIb9cg55ZaMGQpK5CYu2LI8ok5VmQh aHZGP+/+t1klItMMV6XUiNqvT0oNNOk6Q0oN1+6rCqVGNDoepUY0wik1TLTw IkoNM6SfZUoNEzlOzVCoKqUG+FdQapho3MUoNUAdTqmBzrEoNUy074I4qlNq wIMKSg0TjUQUpYaX0jmh1DBD9hiUGmYognqHa1BqwBNGqWGGnLNAqRF1/JQa UecUSg0Tr3NQrzOn1DCR/xVUrUapAd5aET86csEdkVEDc4gZLJh4S4Rh5G0r Mm3oWn6oDIKp46lm2NYS2QwsZGXN6e4HjAZ+hEukG6autpNhXUfWDaxzyJCW GCrKaQ92KTmhRBkKtgC7Vp8SmvQt4EsDpZ1NBSNUoRKGhWTw+g06VDlfhgW3 6q4azD2pgTyuPMKQECzlTXHNg2QhZVROWA9pwkZcU60GusJOwWQSdTRZK/J5 Wy62nra7Wn85n8s2pcOwscXZrSusMUTPbKavcWcicQX+lgrxYuKK0lDuilI+ Gy9mSsYqu5HoDhozuUR2KJlqhDmysW9POQWDVqq4ql/EXmpKR1Xs1mnyk0z1 8ZO8gfyayL1A0yYjlsPioMSSvADciG+wLOhiS55V/pKLffwil/ncts+9ehz+ kjafu8vnvtbnfrvPnfS5cz532ee+xef+c8XXQXwsf+F7/kmf+/M+91Gf+5jP /Q8+9wmf+4eSK6T+AKX/f3zPX/S5f1/pDgR87mk+93mV/C8S4qGC+kW0e9k+ xfXJKVwwwqJES4u7Ki2Nt1iif5fz2kBqABYO+JMo7BFUMSUtk4OlRK6cj2vC zktLpvqGdoqzHRJxuPANUugUowUmBN0NdvSiv2rEJgODfRZTLRcxHTG4yLFI jD1Cad+Iow0kwzGMScvmd+KuQXz3ppUowlgsk+/DEzA8VcKxThTRImjOikdl uaYtmeLxkJyvyhXa85RphH2zDuSZJLdAmJkUZhN0P/XujZo2S8n9LJ4CxdMr 2+gUxY2zm8Wzl8VzB4VHHJwDFB7lgx7XDWL1uPE/SuF3SxiTKcRpgxg7bvxP sPif1rRLlPyCpi2d4g1PC5Q8X9PmKXkdxT8KcgvFj3I7C3Ojx4GDOE8i/AMg 91P4BySujxv+DhbmAAtziIU5zHh4II8NSn5S0y5S8klNm6PkFzxeIOThuZDK B3l4Lpzp8erMVWFAtzeqMFmQVRjQYb4Kc8RrJ8GjpDPy8DxKOqMMZXuBCgN9 9tJpsgvikHvpTJJhHF9IYRCbZ7GSD3ltD7F2lG71N3ph6h/3/CdBXt6k5Bbm 3+uFn7Tby/ukvV7eJx1g4aH9XKzkJ5n/SfbuT9i7L3nlPHk+k/dX8hFNYXxE 0xkf0XTGRzSV8RFNJT6iWdDvFpH/eTAvNJA896R8F+e9uS958jyLZCj/eXtJ fur1wV80+anx+YumYH9/Znz+oqk4h141Pn/RVCyzfePzFy2eT7jd4/AX3QD9 Ilig9GbU5i96O9R34ILx+YtiDrzWMz5/Ud8dp8df1HeIxsBx+IsSs6vxF71e 7P9WNQ5D887kc+eQAmhs/h8jFA5bHv9PBJ/rhmGYE/w/rwn+n4uSfzr+n2MH FjAulIWCl+Kk4NTBQezeeQ24gdEOzevV/Hw2fr6ec+1/YPbal/1cEYKwoC3Z 1KC6mKR0MIjSwWw0HJhPmiyrKXQKpcOlpemMI6GYgtVrKpdIqaiaGiDAtu6t Dalcfxz8kxUP5LQVx7ugBnlJ3+Cisq7S7YZouDGkN4Zs6W5oUNrgRAuRxra3 drR0bo11d7VuaNvYJvZgwn9za8e2WOuOntaO7rbOjm7Xf/0GYa7X1nG17yk8 h51tmPFJcH4It1imYaFUMEQY4zBEYDHD2m4O8gPMYJwQb2ayyfghGH6xxvBV tWEmf4zJDC9Ye4pxOSxiMsMjDtzE5PuYzDBkA99j8nNM/i3jb5jH5HVMZjjp wREm/wWTP8n4If72MhfDN8iwjIM/97Cz6wKMH2I544ewGD/EWsYP0cb4IXoY P0SM8UPsYvwQI4wf4j2MH+JDjB/iPsYP8QDjh3iE8UN8g/FDfJ/xQzzH+CF+ w/ghZjB+iCWMH6KL8UPcyvgh7mT8EB9j/BCfYvwQf8v4Ib7C+CG+yfghTjB+ iB8xfojnGD/ELxk/xB8YP8Rkxg9xHuOHuIDxQ1zO+CEijB+im/FDxBk/xJ2M H+JrjB/iO4wf4l8ZP8TzjB/i14wfwmb8ECOMH+JWxg/xAcYP8VHGD/HXjB/i 84wf4u8YP8Q/MH6I7zJ+iGcYP8RzjB/iRcYP8TLjh5jO+CHmMX6IJYwf4jLG D9HI+CGaGD/EBsYP0c74Ia5j/BAMT3/qQcYP8QDjewgzfohNzP8mxg/BcO2n fYPxQ/yI8UDMY/wQK5h/L+OHKDF+iJsZP8TtjB/iLsYP8THGD/EZxg/xCOOH eJzxQ/wT44c4wfghfsj4IZ5j/BC/ZPwQf2D8EJMZP8RsxvGwgvFDmMyf4YDP +CiT2Zg8s47xQ8xl/BCXsDA3Mn6IAcYPwcbtWYsYP8RSxg/RyMK8nfFDZDyc 9Fkj3jgw68+8PjLrBx5W+CzGAfAGxiF03hQPK/y8+cz//R5W+HlsnD/vvzys 8Nka44E47GGFz2a8RHNyHlb4nHcuc/knxCDG5U1qL9kixyWL5OslNrSLG55k GLV7Gc7sQYYze4Rhyx6FdG9z52V30h8HXtYLN4EwO4Ew+5pCmI1OIMxOIMxO IMxOIMxOIMxOIMxOIMxOIMxOIMxOIMy+1hBmx/7exjarfm5jW+yrVPnFjW2d 3gc3VexAJa7s684M1LbP1ArUjtQ0ArWdcWxAbZubgNpR1wLU/dzhbBmAIuIJ fuZTxfzTjlZYf0aMCuPPSIjbfkZCY5p+IkRKxKhu+BkxKuw+8cMKZfbppnFO rD4j4TGMPiM2aGzVMPmMWMziE7+geLUGn3bEZ+8JHn5zT4S9jVivwNgT74wj kWqmnpGIOnlB68rTsiWc4bMlnEN39asDp9r+nQ1bwUU+27VatoOPk+3bqjFt Cb3zowrztUIxv1NYcKV2Z8oqENmwKUMveQ42bZpnDzFrGnGczQR5JsmzkctZ k3cK80GeSTLkY5qymVpMYQ7Id0QYlJeR/6i0HZtE9lB4njiT2ZG56Tos3dX0 7oPS7mAS2RDhcZv7bjt7t4u920PvPiHt0MS7T0i7M/fdJHu3n72bpXdPSlsy 8e5JaY/mvruXvbuPvbtfviua2O3y3QDZqbnvHmTvHmLv3kfvTpVlJN6dKu// 3Hch/9OZDdEkZkM0ldkQTWU2RJOZDdFksiGaAuU5g/ynHKXwj78+bIIULdlY NkGBXs09Ox7LJkjY5bSMbxMUfBjK6dHxbYKmF+iudhyboAteojaF6U2rbRO0 +GluK1zbJmjJfGn3N55N0IXHT88m6MJniE9zHJugi5ZVswl6Ld7/rmosxpOZ oVLyHNqY4Fl4JByubv+jW7ppC/sfW9dN0wrZaP+jR8zQhP3Pn8L+J0j2P4GF R+X4c+wIjUQN0OKXawsE/+Bk4RNQd+ti7hrVvHm9TnF5snGIj0uByhXII7+V /8H77pNHfq8FHyH7dUzuLQ+IfhcgLbUvTNWCX1Dj0gPqwlYwG4sPMTJ9jdnk qlJ+FS13tA/TOIl9n+4skRdWI45l7aM03t5YpZg+orn3geIvxWS8E4srY0D2 TcASXxzI44icunR3qvmb2yremjR5p38b8+PzgM7kXVX0xTvHYc37hqJJk3YZ dO8s7Av2sjXVQVZGBZKjyqaGxYt2GO9j7o30DQZyTqJ9wZW0BrqF1jkX+PR6 F3EHI8cycawLW4QOFob4mnG9od2juXYd4u9qZc9D324c8uzdhR3DreRG+1Pk ZN9JbrybvbCSYlP8DZCNJ/69l2zq30Nu5Oa8hL1T9OVlx2ukCy8+y/Fd/Arf s31utKlZT2u4i2q806zulqv8qYWTMU6619AvcWBraONwHclLtcrvfsj2RtsG /22vEd/bx0jrWs2dV9X3HcrOR3Bn4x/eheP4n6d1QY9c47t/l9NvmK1ZcK3w bk3aPOG0jLzd7/S+N9K20u+d9LtFE/zTVVeQT9EArEbS59keC9yTHq3YowXO 21uxRwvMH63YowUWVO7xAguWkVuut+U8gW45Fgc+uZ/c08h9iNzTyf0gueX+ ksb4OuLAVmM6uGeRW4V/g3R/aTe55bdKwS+/QO7Z5H6R3HLOCT6q9J/r23PO 87nn+9wLfO43+twLfe5FPvf5Pveb5Lz6kV+AUrvnyvKaowW/gv2jfo7Ub5EW /KKYU+eq9XYggfWhwq+k8i6T29QCy3AflyR3sxY8+nv2/jotMIzl+iQ936wF kjjW7yf39VrgBhw7F5G7D/RZxvTZBe7lzF3Wgs8epgl9rhj3A93iWxZ6/1Yt 0ArzVPAkue/UAimsv5+Q+6OQvyTTb1QLbMV9yy/o+We04ONd+L3QxTLI51T7 mCPbxzdAH5gbg9Mo/W9De2hh8f0Q3P3M/SykV8/cz0N7OsncPwf3C8z9ohZI Y/msI33+nxYYgfoKbJJu2DsFrrkPvxki9wJIb6r3fmAJpHeEuZeBezZzQ/1d i/1Rve9ogQjkb1aW3G1aYAWUbx2VR+A6LbAd58Fecie1wI2wX5/8NLlzEP8O Fn+J+t/8uaL/BfaAfl3s+S1Qvqu9+gzcDu3lcfb8gxDfi8x9txbYvBe/E6L0 Pq4FGqG9TC2Q+7Na4GP99D0kuh+D+Nex+L8J7hbmfgrSe4DF/0MtsArL+yV6 /zkIv4mF/yXofyML/zt4P+u5g/Xgfpi5Z2iBm+sxXzK+INTPFxez50vBfTtz Lwf3QeZuhPhmMncE0m9g7jXwfDVzb4TnDnP3aIHLccB5ntKPqfFsjhjPgv0Q fiULn4f6Rb55h8IPQfwh9vxm0O/rzL1f9Q9ZPsE/h/aJ9X+I3r8H3n+ShYf+ dnQ/c38CqjBL349i+M9D096E9rzkfhzC97Lw/6gFijNxaqDn/wz9eRFL798g fy+x8P+uxgvZf4M/A/3XsecvasGvHvDqN/hbcB/03HXTIf1NXvi6OdDkMb29 Mr26iyC+o+z55eB+nrlXaYHDq+mMEMPb8LzAnq+G8W6+N57WbdQC78Lx7wly d0L4vSx8D+iziLlvAPd9zB2H/lzvjW91GS1wE4zfgWfIDePlVw/h1ET52wfv P83e/wDMV2p8g391B9V8N0fMd3WfhfAHWPiHQb925v4yuJ9h7q9Bl8f2eITS /7YWEPsqjA/m27qnaP6tJ/ez4pNE7/3/De5fMDfU39Ee5obxcRj13yfjh6zT eCzrux72ZzuewO806fkbteB3D3n1W79ECyyC/jrjMD2/BOL/iRd/PfTHo7uZ W4f8HWduB54vY+610J/mM3cbpHcfSw/6443YHu6g9Hrh+Sh7XqL1CY6XsD6p h/lsD+rTReHfDemPsvjfD+7lzA3j4/VY3lTf9X8J8R/26rv+M1pgbw+L7yFw H3bHc/+n0wjml06Kn1TZuxbaCQ7EDCqW8cvnYioxrMXL+QyarxTxgzD54TTd 36QzuaTAKOsfKnin3bFUbjhTzOdQSFZ8My2+hC6m3pFK4JfZuaGYiCCdL+7S hnKZ3QLLTRPH4rGr2zuvWt8e69y4sbu1J9az/qr21pgWiwmMSQ30wAvwvj0i PfkRuGTaAWXFYbv4n9BZJLEzn0/G5F2KVKIwEk/s0sr5bH4kVRTXiPmE+wm2 JHSMIRKw/Bp8qNyfQv5GiFx4lArxkVxM3JXwL8dFsYi3+jBRKeKn5wnxdTte q9CX6PKLb/ouPFWQyWDuE/3x3M7UWN+gyyM0IULweC4tKiCBVllQCVIz8Ul7 qVxMi3TwM74RKCn1nfzmlvA2xJwSTxC0j8oxOVQwQKks1g5ijqO6A7ukquVi Dr9vdwtelKRoIKVCHvPacl3H+s1tGzTJAKEJ7if52kBBq7jxgDhUVcjP8BPF PYXyKV/JCzcURxavQVPqs35RpUNSe9UKRZOVtU4NryDAZTWByAVZKSLmeYzs r8Sn+v1Fr8WLBuJBA4hP9tVdjSwwLOB0vAytC4puYwabmYQagJggd2ksRvdj /kwBvA00udCw9yg0AOo6+XQyvge0Fd+hIZHThtaWbVtbY+1tHdesv7pVNXQJ ZUAYBoQtIMvMwM/cYinxSVssm+mLKVURNkxLp7NDpX6BegCKcRAB6jlolpba XcgUxQdbolnCIDAQz+S0VUPJzLBoEgVsLIScQPgGAmqkBmgCVq7mReoWNHa9 jAeDgKWRLuYH3AuwwohUJZWswE1w4RGgsNuwB0Euc6WsPF3rbuve0BLDiw7w lWNXlQcJ8tvWcW0stCpSEYPvPS+03DHBuPllugdomHJT+Vd0lPiPmvf8u1We n2TPf6quBadfufzD9FxiZYj1ymVyLyjWVjGScV5rJBn3DOYCkmG/YCkZ1j79 JOM+w1AypNWkZFh/blUypPVhJcM6YYmSYY30DiXD/H6LkmFtt07JsG96i5Jh TVNUMqxXhpQMa9tuJcO6qkfJMIfdq2TYn0SVDJN/Xsmwzny7kmHO/aCSYX2x T8mw1iooGcqvlWRcQ+xXMqwXtykZ1k7DSoZ5+0NKhrJ9m5Jhfr5WybD2G1Ay zJu3KRnWpCklw/q1U8mwVviAkmGd26dkWDO9S8mwHhhRMuw9rlEyrEO6lAx7 oBYlw/o5rmRY67xTybAuuEPJsEa6VcmwfruYZNwLOkqGdckBJcMeYruSYf1/ g5Jh7bBDybBPCikZ2uFVSob9T4eSYa+lC/nR2Q3aybrRdffXjbbct3S0Yd8B LRDcBwv72Qi2sfPvA3LNlzkw9+JD4D4WEIcBS9PyW1Vt9l2wRLlnZUPwYHC0 /mD9uun/n7frD46rus6rp5V2tbKt1VrGwhj8tDZYCBuE4xSXYepNahKVuomH gCxZtlnLNji2GTyUNi6heKFm6oABeb0IlTplLatFmTGgTAXIsNJuqdpxCyXb 7UbRZERnsdWiEGEMQxmSMKjfuffcfXef3koiTfOHZt+779xzz+977nnn2Ytx 1u4MnKvPBlNUjKqX8Hf18+9L9Pv988kjeCbeFlznct31wqJ33nyhLFXFa7k6 AqY7U5bydhhhd3plcjLtSU5mDFhPd9gViIg+Apc/4ppHv/Qsh2fPDstCVQb3 NA90eTOY609Ofah/S0vfAlvXQ6mLK+MbPloZb8K6L2Y88aYY5mZxnzFCrkww uAJjGzqMQ1MSX3wD4PpTwboT+O2L+s2STNCkuX0Q5rejge5a3Ie0+0bcb+gA HO6bo4FTRyGD70jZmQaP1WDsXh4r1cbu5jG3NraHx8q0sZ08Vq6NbecxrzbW ymNV2thtPBbA2B+C3hjGvsnfJ7/YEQi7mY8QxjdKecc3RLpNXQ8xHm8iHaV9 IdfxBrP22I3hWsCtNhgu5Kq6RsGR3LKA7TBCvgyy5cx1yVfsciZdWHqMN6Wr kq9EjfXPPtUQBu444V5cG3HdQzgJ5lhDmOT5NdDalTZcFQ+9zoXLkiWfukqW Nsq/y5qs62J/l3UVGf9Mu5/Hv0vt8gi5FnzIdtxHPGRhR1nYxGz8QY4hJ/kC 39sO+DbMAd+qIvj+hX5HAG/TcTjmN98fMchv7/x36UuzrrFQ0ZaCH+C+Sq4R nMe2UcnP+6Wv1J3AWDnT8RzDiDgAP90rxwFIB0PQDNsps76Jv/MUz8sVef7X bLeIVe17mKcDGD8p5LAymUKsSLEs5ot/YQj8A74PMjiwWMCfO5g1uldgztMa 3kc4zqQyAdOXuSE5RL5L/EBeJKsnlb+kg+2miCNG0KRYdUnEVaHRFAfsX2p4 he12eJKjoG0Y+IeB0wWcfjyL8Jo0ZmTWyGvI2E2/mcXJocwa06C1ojQf6/G8 P2FeJwA3QbzaaOgDzJ0aDd8Q8MD3VIPpP74m7kdMr4CvdtA4/Nh/bE3YHzXM Eh4XsSs9XQbf4DX608EdXaTvjFHX5SCDFGC/pq1/7QwyWD9HGfRLGdR18by1 s8ggDZgrNRrmKxsFzSd4j7lM2tqdKxjXaeA6zbiK2U6Obcdr4d79CfMg5rrz 9koy2/0BX5vA3weYPsAYNVZcXcx0YV/Cc2FTIa+h+ZQcJzmL8TJeCzre/Qve C/ss/032wcfe1eTwadRfjz1+94fMYy/m9hINBsuL7kn2gPm5usf1uXw8Mswm khfgRWy/EmN4/hMBuyJ+E8PcxHYwi9x2v6rJrVdbQ8x3M9/CxowdyEV2p6zY sn4KsaXLb+n5xbTRbgLmFSVDCRM0YWtnydZgM/Vk02xvEcCeysub/bc84lqk j51cEy6jnAd+YcQ8yYu0f0G2fuxJRifuo0akkvgbMbrNmC+3rBP+8VRDypcx Dq2LBUK+bHD9Ot03NPxi7JTEX23DX23D3z9inOwqhl/yZVI8cOG5q0va2oOs 4xXQ4YpI9/qpAOdPUsZ1HaDHre3pz7Jt7ka8/aaDXG7RxxAjytQeHBV0uypI B1noIOqLLwMtJccbIhVZY/26Dl/Ix7H7d3kNP+V4hKsLunkG+RvZ+iLKrwIn u/Dr7pQ8bLL7NWziCrbz4TT2JdDaIv5BD9AiYkTANEAT4prJcW3BFnquxboA bLAvFninawQ4kZPu5jUGhA15kgMZYUclA7acU8UVr4MMS2ksBTptur5F13UR mfVnYdtfQGb9lszquhxkVjoHmVXOIrP5s8isVpNZv5QZ+WfJvl9HZohRS2z5 up9y9LjfdenHK+MbP1kZ35S7IXkBMlgXcu16S+V/iG8PcOwuEmfOe2Wc2RW3 4syuJzhH2gj6x0Hj+HT+5/+bvhcCLkc5FX4P6nsGdFPDfB7Es/ug0/vk/F29 ikbCP4J8F747RdejPrOks9KcupTi8cLltaOeZA7wzzKeByj/ygT5enHyAvY7 txxPjmd94ZJsg1lu3SMvbDA9uH4AOZo3i7EoncnEnrjrccaJMbMmI+whvgn5 9CTyuE2Q+xH8HaYx0pG2B32kdEc5gJgH+qM+cwrXY0XGRzE+CjwlNbwnpbAG 9PozxjWKdT9nuDHALYHOGoSMWGbgYQJ0wzZ33cFz7oMedsi8r+75ANswr++W /Ai8n0m8grfPiDcHnLdoODey7Y7NBRfRixzoWp6TxX2W88kF9hwC9uCx9tqd LRkxd1c9y/WYkgXmfwCf9DvM13KWnQdpPnQ6Cr++CDyXMJ5D0pbryK4rNV+I zM0Xdr5t+cLON5imCNbKAl+pfp81wibOHaZ2vwL3tJ9EcB42aQzxZAXHKZ/K 0RH3bubrUtjDV5nuOoUbMm9U+iH+QMc5bd1RioupBrOR6Q9jDHt1pcqPj7D8 y9Uc6OWI38qFDhM8cgOTnx3GszVsa0cL7WLnMM/BGX3eP3OMjKSD4VW2tXf8 H9ZeWEzP4D3Luo5L+cZJPycUblx36+clslclH4rviBWbkOt9LsaCNCZ8bp4V S5JHMkGz/iKuFQ69JqLqIBTbMj7T0+ELT4E/N+hT5zF3Dds0+baiG7hW8JjH 4LwZY8scckSvOo/SORL7xuUMW144Xno3j/sLx5e+zuO+wvGSm3ncrcunD/vf dD6HDio+ZQ6+U+UU44h/OZnPmC6qG6VkHJi01TqOqpoT4FZFug9RHrVaG2tE 7C2jeBzpdlXURlxX6XsfYANaTj8JH1oLHxI1K/hOfci1sFfhAm1XWTmWpMmS idC9mr9Wm9+lzb8kD2sARs7fkqeV9jADNo7snmgFbVer+hnJFvtLOfKQqazP LO/AL50xAmwLcc9QTs4PQYYBkRvFxP4mbKe8E7ZDeTLta9GFy3Hmax+UPjeU k3ui72VVX2C69yqdAnZC098TLPdVNhlfocl4qV0nBp+d1Fhm5dCYWlvWBU4h 1gwhHrc/baOrQ82T5wVzVRpwdM4F7Fn1jPOpSSVX0JIDTSUce3Pwu3sZNge9 71I5l01ue2eQ297oQtq32++x0bfHJrelmtye0eSWryXhvLyWfi1+yG+Q5wTN Rs0uPZZdUs4hcJRZtibG1mKNsPSXoTGSC+dzNQ68fWkW3kLAtc7G2/VyPYk3 kD+DKj837rLOzu2m9WxojPhy9vdkhGP9JO1xiPO0bqvKiQvrnu3Vuq9qOdA1 Vv0NehfnUeEL6iy/C3tCuc1XRS5pix3KJsfJJuU6As+8fG7GOmIelT+OYw9q 9LOOeD7Z3bg6z+P3rC3OeQviuWHWZ7iObqNpgeYndLYr0Z55rGfY32Ut/aIa YzzLWPd7LN1X9yvdk74Xk74DuQMh144E63uP1HfFS4W2HPi20imfyZHf7xiy 7HvHOUlXyXmtzt9ItZ+YyFfmP6LVBa9yoOsJyyaTk50y71D2GAf+mI2+x3V6 ssIGy+psNN/kQPMxjeaXmOaX8/YqdTGh+Z7dPiZYF4aWW0zQHuW36jIKplrN Z5icfCb0NaHsQ9mitQeLuERrX6vvmTZ5fXUGeZ0Fb002eX1lurzcPy6UV7Wy H+R51e/zNXRX/Z6DHNdrctzJctyl5nPOPlbEnsc0GdrteYzlM6bZ8xjLp4Jt a4xsa3YZ+X8xg4w+DbnCU4Uy8n7qIKOjNhk9p8moR5PRyekyCn+iyWgJy+gy xZPKrRcJHzzZCJjLlY8EeE+18fNPxfmpo/XesPEz7MBPi42fP9b4OaDxc7cD P69b/IT/m+X+rp0fPLvAMXxPB3LjrHgWb8TvHjzLcE2Zzg97KD/ms3CjPAuH /5WfpxA7IiOAiRk5jFf/F48fAHxOgx/i2sR+0LAfsqtyWza1iGnbL2s4IS/W 3B+TtTpadz/V7WJGypfxHYpkfcl0dEnIl2lYT7Tt13KG/ep8zOuPaeu/rMU1 J521zKCzg5i/3aazzdN1Vvpzm87KNZ2VajpzOejsdk1nf8ZyuV/pwKabfdN1 A1xG3Mu87iyimwc12ei63Pzb1I2KC8B3gNe/VTvPxW3nfqqFjWaMHdhbvPvy eaV13h3NCpkueEnTb42Dbg5L3knnyckY1pd76ju9Idcd7xbq1pNzPlOVuQr1 63/C0q//MUu//iPT9XvH25p+S/RYaOUbZ1pUvpFamejD32n89eIvDjns7Qjs QLxOnODri7juktft8OHXevi6FtcM316fXnlm4P8zdzG0/gErrtwxqsXHusK4 P5iyfK7qu9NznHNhzP8LqY/BFOvjAZvcGx3k+4gl3zt+INcsLeO89ay0FXpW HtPspM6BpubicSB4BLi32mi73UZbhQNt2zXaHpa0Gf9py79yMVHbqrxyev5V QN+1M9A3APxrbfStnu4Lxj8U0lw15kDz9RrNtzPNP1R7COwqkfacSdhsic/V ZxJsSx6Ve1HvBuy1z7IpgiGbOpOATV0ozOss3FauleizraV+981hzXYbTK2q 6dGYFUsSJ8DrVZrtujU8p7X5ZoBrUPp8zF2i6a5SxpvXejOAseLNuYmQa/sb Gt5eDS/lWWvkvFf7sgK3itHbL8gYPTSMs92wc4weGrZi9NCwFaOHhq0YfX8K MXpUxugbUwRnxeihYRWjU9e9mirkbft5TS6lDNMHvZxmfm0xo0C/fAZI9Orn 5Chkw3LvAv4zDKPw/dCm9+d5j8rhbwwxsSdd9Wqf1iOTx8uxj+JjnGXcE4U8 +T3lerWW3sOgnsscrxs55/YeDaZCj2Gq34PxGzp+Of8U/HS7Hmcc1jjlBcxj 2hoefY2UxF3qgJts4c+1ebxHIc7LOURXD+TWo58tyZ6sGFPxHxpt4rzUjXgR B4wVZxaIPbST40yXtINqpqEW8YfouLQw1pQHJC2v9RAtoCHOa1RLGs6kOqFz xtGUxXPg8EocZ1KiXgYfHJExahPLg/1M8FNaWM94LS7jWcnjDKvVRpNj9O5W 4ip9tDDeLYhPj3fb/seKd5Ivdb7TegJymHvMdtZRzyDXBY/y2eEuttVR6DFB 87jWNco68drqmeUFPTyRkqts59NFAa4Py9pJeBVkfVjm7gns74kBvT+DajRY b1T6wc5NgEn4uWaqYFUfQNSTSGm2tQfyxx6y7ZTUVyKVlvTrZ+Ef2c7gTjWa pVp9dTwNHjJG2OT6qLtQrwXn9AqtNkNjpQ65yDjTQnWbc/q53Ir7kn8873FY 46TDGus4NzwLfpFvJvrl+7gE9Vs1ylw55JPvBvPvyxoJDrJ6THuHxrFyW5fU VaKfYrHESfm56aU5Mp5vu1/u7cmz3bRu4XyRP8YMs1r1hsK2nuTc/Szn7tcz nu9pvuwu4D/i2qX4Ksz3t7X9ZvaSB0etveT3RovvJUOjyK3PanbWARo2ajGs VtkUP4/TXhkLnE9L/y35o0L/nd/n4L9llv9uu5p5ecSuG+sMv22Vtn5VYS42 dBYx4y2n/rg0+7SfYzr5ozVn2+JZ5lyj+bDTO75lfE39S0uZhyp9HaXHkGvr ZzPovdrmf6vgf6vI/xxgy2331nuxvM9/ntHes7qMghicSMgYLM/U/vzZK79v +9ReXxjfXaNOMRvPExz/L7fp/EvTdb71iKXzraetGD2/3orJ8690Pmslm9RZ i/oh6JyJM1WP7JMueHfnCWjnIKxdkWlw6XV9GivNNFjvg+idT7YB8YN7qAvP 5lsf4Nyvhno9qI+XZdqg+nrzfFn9bBSvg6ovjd5111jv7ie5F4HOyRy3khS3 AkxTfixTlfx75KEGx7B+0Qcr+ty2ci0j2S973cS7ULoeAP2GNjZAfSk4B389 /45rTdjg2FYrY9dW9V4goWQq8eRrFLVYMwG4G1WNgp6PYCxmhCoz4p3b/NsK etABw7JbrWoChBd4BqKGy6f6zxhvqdYLKXoLrF7Its/UGV31Qlr5Tlklr5lN B5HbkQ0ETHdhD0tZRR6G+aZebcj2tO1d9OK8TfvM8jjsiHoXqTcQvPRKXG0f i7yLYmWehspXVM7Fe/co9cXFRPxvE7WlLo/opdgo3luCf+pPekbKxjeTfVO/ T6GNC7utnLvdtr01u922/fS3a7dtP5i73cY3Mr1Xql4lzH9Bi6HLtPFejQ+d tto50LaRaXv4i/mU+97iPtV2eG4+1ba7uE/NO+TsU20ts/tU27Uz+NTK4j7l /p3Zfcq99jfoU8um+5TvnOZT++j/itN86hLNpzZN96m2L9t8apPyKQdf8s7d l7b8SvkS8oyPZ9B7udK7Gl8k1j05IPWy5WeavqnGUMO6djvresvbmq4HLP1u ebm4fre8WFy/pUOz67c0UUS/A3PQ7wD5DOjvl7i2POeg3702/dZb+t3yN5p+ m0TdFzK39Ltl0KbfdXOImcYX0PND1llJ8ByfA89xrHUCPJ9gnvc68LzaxvMm jecd+Th9Q/I9Lc6mVczWzlTH2R64L0vk2r9ifadBx5v0y7HuLF8buB5Oie9A 6Fsls555Wc7z3oSMlpCMOvx1z0P/X1Z9rVGPiHXDsk9sy4357xJkv+AwrY9c z8Sc+iJzVtvn0PckdK7Cdcqq1yffFHuEL7yc4jLjdcq3N2r59h+wTK7Of1+V P49tWWH5YTLBvYaqNvgBjwsf5JhO38icxd7wj9beIPER7dLnWn/JfpHi/SAt z4qQ++Lk6yRn/L4HvVYInNCl39pLU8z/tHWY11XIn3/iLMPWsV9jXXdhzxzp nc4G8Sac8fapfZPlW2/to60j9m+G3Nz7xPcf1Fi1AmVnaS0HyI8VyhL3cp9N YQ3V65WWPAn5F+WF7gu/0TFixeNv698x/T00T/UuUwzGGbLHtv/2AP4RjqO9 GbFOWKyDfbjH2od937fF5l4ZK1r/lL8hyq9DsSeG2GPbj2mdW4rH69bfLx6v jVtnj9ey7paP10zPU6BH3yetGNq6394rpPfM4PldLEP93VOZ7LFaP+XnvgB+ /0Q2Pc59ePQ93b5oIH4QOL6indX91pmv9VuMO6f1Yui4VS9ITuHmfWAcc7+u 9/Tz2Er7+Z3xlBXvhUyE8r2QnqEJ+nZgsaA7F8ka8Q2X4rpzoXkk5Gp5i98x TnAdgnjrwJr1DvJZoPqNOwGveo4JV3Sh2SV7jltSGn1HVc1Y4Y/668hWYG+t C+3vM1SvaaYKsPKMuzz/jN/vES8xz2Av1u+V75aWY29oLVXx0rDgx7kGzDmY l32G6r8ka/yKb45Fj1bhu5vk1I+tPsuWD3T5SHuug822PJmPORoug3mIY920 qCN796i+7Q5Rm275W1nXTvQSjIyL5APe7Wrv5Ho26SEl69ktu7kmyry41Dv/ Xu0bpxDg9mqyX63D4NlfMf89JEMax9jDSqbgQcWNJitPaPmO4p3q3DHD9Ev7 rohyDYS+F61lXPcUkdPNRWhdX9x2rX5lW17i57yAcosJ+d605dHCd+HVAQ3m IsM8ZMdv65knv/iU7ddv9cxv/tzWdydiSHF/qsP6m3853Z9ObgLe276YP9W1 SHo2T9rjhuwfbLmUezXHsdY46/gW/R2spO+dyIiQweafajZ94wyyPyJlt6ND y3d0mlUvJH0nH/dr30ZkRayMh2DDFU815EpiRqTi6Ya4uzOY8h1vyLmjwVAl 9h5PFvN4DdhNadUMa/RhjZi2Rt8XWCNWhL+D+j7gEJtvVfaULt4n7rf1JizS nlVM7yPO9yhcsPVXXmN937H5uPZ9x+Tcvu/YvFuz1W8p3GxzyEE2P6rVAhdl 5Pcdsi4YNFfAjhrlfk/fYEi4lOghpl/xXYPoQ6dvHDqoZ0r0k2zut3rMkzkZ L0K+GXp0hbz1HppA4b61mnOGiaiokW4+ofclU23YW6ifOu37shjHhUu1b+g3 ZDHeEQRN3IPrzdedRS13Qn4/IfsLIdfbooEdEaz7kPat0BjVnC96RN25bLY4 ZfuOVb3r7UOucBPVZYH7egc9km+mSY/SP5s/0s48BzAnrN7F49mY07pO9CAO 1PbBhoo9UzkmYCqcYOKAoX3q0NTU+5JvZ1wa3Hv693NF4I9w7/THRXp9AvyN zCRy0slR/Mn40N4kv4OImyNGbsVoqVkPWfyosPdf+NWkfl6E7KqL62ywPrVy 8GiHZ7DLiuH07wKoGB6ELTR/j3OHLiuGdyMeNp+fOYYPdhXG8CDnRM3ftey3 JMbvuHoUfisnan5rek5U8rDca4d6tHdYPemqwS6tx2C52htt4/lzpW3cZ0zP ed524JnqMz7Q9bj9vb7sXxg86s9/2zl41DY3HRO23/yglrvyO5XBo/yNkaJh UMaAwa4Yzh2dnuQe5PT1zyBnKCNc/m7EheZH1XdKhibzQn86d1H60xDOIs1X aDK/gfutuI+uuZlxLfMWxXXe1HBVarjkmbsqWa/kSXPB7/VpH3TpM92cuxbY hg13i4X79o813PN1+fwva88CFNdx5AJCwIIiBML6uvKEhS1jEH+M1oVB5iNh IYT4CZflE6vdJ7HWsrvZD4LUOeiSuBInKZd+tpWck6CzXJFdOhknulh3FhK+ KBdVojtjwum4hKvgBPuIDzuKozgq/7iemZ73Zt++fbt6Dv7svjc93TPdPT09 Mz29/IwKbOMG8HmPY13w2bu2iGfP/K477xfI5Tj3t5gsyLlm122CDPHe5uhh wFEh+mcIfwLgrVFkTups0KkDvm7nJzp1ErHOGp06MP93Xtepk4R1ovFvRODf KWFuGMX6xfD+kjqfXhw2mE8JPsxR0HlEwPUi15nxlIukb6/g+fPwBMiCzaX0 ++EJek+Sfv8WuYNHvrP78T03JmFeZPduoDxXusHXROFj5bmbMFaSgcaPBF58 OXxMXJyDMdH7HZC1OiY6fxpjTLjBP7UIvHpI6J9f9FN53w3GBMFVJeBqFHDt CR9fnV+6tfHVWSbgav4rj6+1Au6K8PHS+Q0+XkBnwHfvLBV05tk4dWaRgP92 db108Vkoy0fb/SzYbukojZHuxHOei8+iHtWS76gvN0nuH9SXZ6HsZualTw+q fntns5Hfjr6I0Twb5rcy/1e96wT+zrx6/zJsfn3vM9JdJt5LrLV0/Elriwxo vxsn7ZtRaGcL53qSGm/bMRFHG+qxDf8Xqw1KjrHo7Vgh8AB0reOHAv10gWZt HHLh7fpfAz/ntHhmADp5U+g7jzm/qewzWUkOCCX3lp7sKMwRgDlm4/uQHaNK 3Eh+LY8F4XH1JCbrHaSTCvbrZg61IcNXwDdyH8+WxqF+EY6XVGzbVlhPNJPy p7OlGSH3xDzyIOo+Aekj3wMQcJD8FSnR/dhRn/ZcBebEabb2G52FeXjWgC+4 PxwBIyUq8owoSxN8nsUcZixffQabMKvycJTEkv1G3VfswPX46AzUm8F7jEui 2OrrzD61Twv2aYbv96DvC3BvriS+L6xBWgH2F5q9Cyg/KQHdvFvYu3AfzV63 AWmPCrRfQ59jCv6bjNwP7Fiqsx+IMXGj/B6YQ2wfXesBH4DOW0JdvBc9OqPE iVnvv6mRz6oYMGncn+Y6o+FJK8zXKUD3ZwJdWxzwr2rjauleXKKUQmXN/R+6 Hzc6w84MRmfBV5giegK67Bd86bXoHxBZvoSy7FbXk+3d6GdQWR/OGoY1ZftD /B1p29DCR5jzbxTW9YsS1Hmm/YeC3NoF3286E/s5vvTinLCekNR1Rth7Ud8l pb8po5PQlxptrG+kDof1J19ta9I1/A54kn4ptPurQrvztPdIoPxv1T3b0SmW e4XErIxOku9oR1fgeqhbqOfh9MQY+hh4xD0LbZ6C6+p9Gh7XFWYnrAKNeh0b pI3LzYwCS+SSFaUszYBGgSC3VDVXILdLw/XAn18Ke1kJiWqeiAQhj4RFyCPx W2GPvhDf4ZqTxUkcpXJmcPzd0MInc2h7nEDLqbNfN6nqJ50jfhGlT9XKeoqu SZgvEtancLwXsY2viL4ttvGf1X27tueFfbvdBj4j0WfMP9h2UN23a5ORj7th /nTC83fFZyEvC3/eMEnXGMozzdMC33fjWXICt286suB5G7sFWVTx/C3wvRrL +VnbbrwD1MvbDGU70D/vjeWfJyoxlnxd0HaW4yV5V/hY4+Ug62+hrHugfz1i nCbpL9QX1y9d4fMo5UcP8KOWrLn4+FdpJ96poX27upfe1oh0ST6hVmzrE/iu g+OAuh21loTXkB58b/uKBmeq0NaNQlvv4e/ZvirLpYq6kqLaEuhDrhiryuBA r7qhbjfZR9bkyOXxn924x9wN4/ID5R3Ft04aY+MC1/yqHwVri9/G49cK7WC5 esPHVS605z7h7Jj7f7qwqj2KKBPsakSZNdLm8ft99Fw8geUvpfcnEybJ2LaC P5pP7bjiP/E9bp32L9ZvP4vNQZlsjtI2YmPvilKWlqjGFej1d1W0/hrwqdqA TwWfgU8/D+dTWN+1fvMh0W/W8ydV/3tnpeCn6MCs+zrAFAq+AakzItgsIz8T 91d33iGMtf8SfRzVh90ZjLF3q8U9grgzVFvd+qGObwf+yM5HtHn4YvjHuHfQ +mcB9+/QP55hvj7jCfP/tL7yznodX/kw92nxvVvHVwYfcudqoe5uvgYx8JWX xIARfbytfK3IePMPqZO0L62vcnumaXOOcNYDa+K058Q4HvG+tYAzE/D9QCfe 5/cauJUA910xBigK3Wagy+/oNhvQBR1qfUKEA7rNOnQ3ANyQsPc5o+7TclmQ vIqt06JfjHIj94BWRPGvl0bxr9N0cP9U2EeNRv8C+rku1c9t5Wd7pPxlg7lB uA+uxJ6lC3d1ViOeC0Lu7rPAm2aSu5voIqyHkoDGQe16CO3OhYlcEvcjLSEx bCx+TbHLF3hsB9q0RWy+bn2GxyTAXJyBZSlYdliNV6g6DuXLtfMcG3MJ2/g4 Pkr2Mli8AsmxmAg4ntSxH+nqvUv7Wra3YvkqzxU0krVureCfzF9PtESdZxl9 FqsY7vfQ92eFPYyVyOMlannro9FjmSQlTzfuHWWSHOPjoDjQ39sMzvhou8aU M/DIdYjB+kHSmYeKo8BuzFLzsoTNvzRfqLLPEl7PYE+YnyEk43ogQ7inpOxN oZ1OEuIlk3XXBJcW/lVY5yRxu4BzDb8ba3RGPCCMFZ7TJkkYKyuV/CdsrCQR PT1SSmMfaa5NIe/mtDanLMkzMZFbcx1zV/D+kdw3bwt314hdmsPz1bmplEuz v6Jn7Tt2RNNFjb3MUOOFWSwD07sdITXWgfLqfQ0+H+rQ1JgaCyf2/VF+9o85 +gh/ZtH/iNATxQbq62KqcP+V0NDq3+dvUY9EmdYJ+VUTWCwg2DDqQxF8zIfS kcHrYpuWh7cx4m410uJ3xCgfuB0CXu/R5iVdrOIjzwtCTjOx7cv11u9Eb0CP SM6UycNZNB5iSifP3XHcf5661VgDIT7gAwMbUxW+R33pBMa3fQ7XbifEfWF4 L/H3aBe/pLcfjPvA9WNg58dyWcxazqo3th7Nei4B92rqc+77E7nP+cQEzTcP z3dufOVo1vCn8Exz2uUsyngKnvvhOUMvhlTZb06kcQ9JoDs1E9xOptD91Oan 8meSJhJ7MkmMEvCUxMhkkn4cyR9OIvv7qxW7p7YZ1q/LjyYOJxyHfsM6dnkY vtKZ2wHf8uPkzi+Ugc2qFeJZZvH+Fc2baEU9Qru3ksUDs3hdvKcEvmBKljCP rkSePsz1j9lDapNrJqgPRfEu0sw/BNc8wY31twnnLbV4TvEHJf+zmgt6nreN 6abSrnl6pxnokViQ47mH0msti+eixfIepnllacxiJszTqQC7V/UNw2TD74Pf u5LvvWZKVYRfhH98zMB8PzBJ39VaMRf0VvRdxkneKNDnIdRBIuuthCa8+6IY g8hiJxfXCr+HQmIeu+HdhKYfteF5/Ngam+RKUHjC3pFchqmad7PwLkPzjuxn D3MZszjLxXYlLqziVy+QuGWcN+bonV1rrZXMCcerLOnXSB4G66H0oyTXPOAh csC4daoHYC9SjpX2rEJ7MY8xYHMchtj3HFvJuzCuupAGubc0hzTmkcasQOOU QGOG2B+gkQE0liMNOmfwGDV8ns1JS10L/fg10pihOsNozCCNOYHGaYEGieGe BRrLgMZSpMHyglPbpzzP5RR7AyDz95DGLM0ZxmjMIo15gcYZgQaJmZsDGrcB DSvSUGK5OQyVR/WeJODVS3HKY8SUPJa9+UfoR36c8jhnSh75GcuARnac8jhv Sh41O5+HtXZCnPK4YEoeq3vuBL2ailMeY6bkkftGtSDzWPK4bEoeNQvXgMbL ccrjiil55O6qABoX45THVXPymF0EMs+NUx7jpuRRsw9sycljccpj0pQ87v5e K/DqyTjlMWVKHll9iaC76+KUx7Q5e/W1J4BXewV5zGj6Ec22c3kkA401hvIo ziwAXtUK8pjV9COaLeHySAMaK4znj2eeBnu1U5DHnEavoukul8fngEaWoTxs fS9DP14U5DGv0atocy2Xx3KgkWEoj4pvXgaZPxKnPM6ZkoflSDLQaI9THldM yaNywyDI4+/ilMe0KXlsuvEpyONKnPIYMSWP1AHwGU6+Hac8LpsbH//+GvTj WpzymDIlj+qKOujH1+KUxxlT8ljW9Tjo1btxymPMlDzyBz6EfiTHKY9JU/Ko uW+OxG/GKY/TpuSx6tdjMD7+O055XDAljzsePAby+Eac8hg3JY+aT58EeTwQ Np+vpvhm8FPPRi0CvGsNZbBu+jHBfrA5nOHj+Md0+J4OeHMM+b5mf7fgf7B5 m+Hj+PXmhkzAm2nsyw62AK8zwuZqho/jn9Lh7wrAm2bI37uL/gX4UG/A31Om +Jv1lx+Bjr9gwN8RU/ytPjsBeHsM+HvBFH+LXvoD8NdnwN8rpvhrvfM3wN9/ M+DvpCn+2k43AR8+NODvsCn+Vtx3FfjwuAF/z5jib0JuimBX9fh73hR/K0Pl 0N5NBvy9bIq/m378NrT3LQP+jpvib8rc96G9Nw34O22KvyX35ICeyQb8PW2K v9XWrdw+UJxVFtbWrKi6xnm8GHCvNuRx5s8vgQ4/o+RjZ7jnEbfeeOZ8tgLu 24z3F95KBdw/QNxziHsGcevZTM7rpYB7mbEtXj/HdY7iYrhnEbfevMT5nQO4 0w35vaoL1uEnfxKD3+Om+H3HT8qg3Udj8PuMKX7XfPQJ4H4sBr+vmOL3OvsK 4MkbMfh9yhS/17zzedDvHTH4PWaK3zXf3AS4Z2Lwe9oUvzeMkf2B5TH4fd4U v7O/TPZQTsbg96QpfldPkvnwyzH4PWKK30UtFwB3RQx+XzXFb+s/3QDcr8bg 92lT/La9eQ5keSQGvy/fOr/5+RC9ZzFPzpQmc9nvx/MzABKrwM55gAaDmxPg UgW4VA3crACXIcBlaOBmOBw/Z1DzOVj+Plr8IDkrU+MIWMyN5iypMux+Ns7T 5AzsWP5wIr9jPmntSeJ5btUzIx04aOux0uHUiXwpIU7YTIBNjBN2JcAm6cQ6 Kr8vmXlp4WefgRf3qHf22Vm/5nxsjuf8pb/fBs8kLynIJf2adTiB/PboM/nD MF/WpmvKErEsU6csCctWkjJyRhqjfxOx+of3nLR9E37zj43JsDM/zGOspc3v gJmgtySC3tLhbRP6NK5Hy6kn5OkisdXbYsRWPy7EVv+NEFvtwvLHwuMynhth eWob3xfze/H8kyRWQYhJCMuTI5Zr4hh2CXUyRNjjNJfbcD2Lw/zdeaA7qclb cW6S/tbr8IJ6X2wL/pbEpXMCz84Bz6bwHDUX4bYhru1KLFZiTwH5HFp4v1Ib oyT+RsfTeB8ReTKGPPlH8Tchib4KMFcIzLXEmQKAew7hijCe5PwEPf/tKRha +AuNGXia5hqLwP+U+HulwwyG8L+AxSFsSRVy8mSSnNvs7todU1CWrYP3OuId QrzpLK8BazfwvI/dxyW//dnYr5//d9TC9Q7ao/wO0NDCB13heYQaj2FcbS+J qyV35lcR/NlSL+AHe9zI7//0Yuzou/Du91Hq+LDONrFODm3v8CF4/7xOfFlm FFxfR1xVIq6hhfdKsL+b1Lj7xl6Mce0BuB7G88ZvC/1MY7nJGo+E53YfdY6n jDr1YjqzoQ2Hs3pGsN5X1DuXo86hhYV0AeY8wuDZ/aiTxTaNOnlMpwbOp8ZJ Nj6qyfmM+fxZzDbPDQ0yOxOZG7oxQY3ba4wrB3SUfI/J8ed7bEzW5HsciSPf 4wjQOgPz/Bkml4b3tPkehxb+/LKQ75HwakzN99jw1i3ke+zU5nscWnh3SJt/ L87cifcJuROrNLFfQu7Ehv9Enb6qyef3uk5uxHGAf0XI53dVyOf3H1FyE67R yR+4eCIsFyLLMQB4rpDfAiKwLBdiw7eFuosmGJ134Pviidh5D1+Invew4YTQ 56uavIdXbzHv4es6eQ+vAo1Hb4VPkXkPWdw6z3tIckTyeWhoYX6b9nds9PW9 gefMLBTjm1Duu5AH5+LInXgO4CuVOSU8d+I5njsRxnmLJnfieWzHXXHmTgQ6 9R9Fz51YfyN67kR2h8Q4dyIb33q5E8W8iVNQznInNtz+184rpLkLB/PKm/SO MJkzns5ed2gNfJ7IJjnH6kfEPEhsDjo5DO9f1HkP/kv9KZ33MF7rv6fz/jq8 P6Hz/ia8P6rexag/pPU3gYe0T0UWS/3ZnJmPzyaPLcU4b8vhLFhbJY+lHk4c +lhZz9L7XfT3ozUxtJfmZ6Ds+5ctFlVnhj4W/NA/anknfB+GOex/NOXwbvqU +A7/Esn/1m+V7U7Zb5OKQgF/kdvrsLuLHP0Bv9cbpG9kvz9Q5Lc7XaGAc6Oj oF8q2VhaKpVs2nRvUXFFUUmlVFpmK6u0lVdI/Qf8rkCvxy41DPik9ZwIRWJ3 9hEcdocjqLyXgw7yzrmXPbd7/f7BjVKLV+qV3T7J3m93ue173bJ1CSvP25gf IN9ZUyyWkNPH3gdspFIg5OiVArK/3+WQbRIDKgIYK6dnDwUBwOs4IAfV570u j5OXQ9vCysmzUE7o1HlDbqfnrqC0z+s/gJiLnHJ/kcPrCXjdMofzeKU+uc/r H7TS9vplR79NapO/EJIDUNfv7ZN6vfAtLyA5vE65Os9ZILmc9MMte/YHe+Gr 0u422SG7+mWnFPIc8HgPeiR7MOh37Q0FZYlCiY9S0OuV3F7P/gLycH+1JOCR 4A8IbuhENB2DPlLlbg5Q7/f6fC7PfskZ8rldDnsQ2EibCpUKpaZ6GyLb5nK7 CVjI45cDPug3NE5y9LrcTsnncqoUFXx+7PcG0rg+u2fwbl3EjcBSaR8IHboK 7FWq6bWB/LXaAwFHr92zP6ydoAmdoAWSx94ng074oCsyq6IP3+Tpt7uh2aQS YA9Yo8BtdwUCpDOk9KDX72Sw0fFy+GYynnRqWSydLU3d0esHBgNBuU/yYUWJ QYBiBSW72+09KCu4ovXLAeNJBhXW0hbhQx4ywkBrpJDPCRJX6REJMPjO9rbC 7Q0tnYV1Wzc3Nze0bGlg7W9p6GiH4Sb775foM+dkQHYDWZfXgwN3i9fr3Dso r+PjeH2b3O8KQLmNWZL11iXr66m26dmU9byaZTOMV9kTjNBMLvEWkLjVAK5d doT8ruCg9IBftjt6FVFEg4/UDG4H7reIf8RakU95wEUNxxdC7BM4Q3pp2S57 QlKr37sPNJvKb5835KHSkFo2t9PPMBJ5gbwA1wsqiq32ALGoLr/sXGIV3u+C gYgFkstDBny9fTCwhLcTZOwm1kTG54e8Iemg3RMEy0QErhRLg95QTc0S644D 9kGpSToIWCl8CdZrlz1Ooslt8qNEnbz7JDrKCQ5iTvICaEE4XJ2CWB+Uw7Xu kjY7DsTGZwgEfwOKXIoo4xww4j3BgMUv2G0Ht9ten+whGADPPjDtEgITZGhv QJNgTgLTFpD6XIE+e5CpirSuGgVE7CjBq4zjgJ0MJQB5WCq0S2Ta2ON0+aVH pIcL+4DZIH06ofUBSoB8hIAFJPoxwD6cknMvq0Jwur37iapY7Gr767TNJ6MT 4PYDfxQ+5BWWlm8sLQ+Qpoj6U0hVxE5GpCXs/S673wMIeH0NGOUb0WnJ65EC rv0eMGMbhOkiPr/B6XIE0WmowPFdUlRWIpWW2Mo22cpLdHyGvEBaWpfdHQKe Fg/kDaSReYrY/TQwRF2gE15/u092uPa5HGw24HInpKDxdv8ga59fb96mDFQh xXG9uaOjremBPS3b68Tnzo4GBQ/7xyLg5TZCnYOBWTA70rkYlFalZA2Dp7MT m+oNakTS6Sd8iVEjDwdEAJpEpOvyBOX9st/i8hG9Bj6BndPiDRJfIEZDCLw3 RA2A4tuQv67NzZ0Nuu2EkeUfvKX+qXyMzZy49C8EljWgUcAymGOk4mJbeamt pDxSAfMChVTIyrzX1NGwHZ7JSCbtpSix3V+U/V7eVPKeypXYeJ/s73MFg7Kg n/4Y4xlmJac4nusbGjd3NndQOq12fwD46fcDHIEltNT5Itzf7PW6nbyNEfrv l2kTSdXIcaHfkINRxxHCH4RZVYCH8Us/C5hbYLGyR0sBflH8TdnB/AhvP/3c gUuDdtmH8z0zTQ+G3PjJDNN2Oxvgm31+fGafjTJbSDxo98Rvn0JBl5svaoh6 VBaVlBaVlkulpbbie23FxXr2KbSR/xs/nT5nhUiGmsHiMqnkXltZla18k97S KS68ZMD4YJxzI1uudKIEsFfayspsxSX6CzOQXrWUa7HsBitbXDrAnkFT2afb qdi5rba87ba8dilvr5QHqvNQWP28QC6fB3FdEWTrijjb74iYH+DfKgmYX14M U4Tu/MDGE/2ExVcQlgx0vcbtOKDUair1vcQKoISoloo+qv4GeAueYEzXY30T OHHo5GlkW1ZUWiWVgGDLbcURXYCx1+zqB/SBIFg3v7xPhkHpkDkqOiWB7QHr CU66AxZDYkGdt88Hy2JiBaV9bvt+GJNcTiUbwW/eVEE1q5I9SxJvDfFbAOme roaW+h1te9pbG+qaGpvoTEffE0O3p6G7o6GlvWlHS7vyfnNd3Y7Olo6mli2a UiiHJUoF51/ij1Mtia/egP+uW+i2xaJP2GdyGn6uhM+M/2fvXKCkKs48fm9P DwyDyDA0CKjZFpGXMPT7NU5oBVETokSGiIrpaaZ7mJGe6dnuHhhQYycaY1xN RmRdjLiZsECIiVkkmPhIgN1kXc26mwmriR5jDsZHTBYfMRpN1jj7/6q+ulXd Mz6IZ/ecPcc+58793a++qlv11VePW7e6x7J3XYvzBJy35YeH37ZszyDOw5DV 4HBDk1Ynai174pUy6VpyrzGWXft9nMfTMon8yQzxqcF998p1DNdWnD04xuI4 wbKnzBJsC9U6hN9rySo/zvoLP8igz3dwWPwuJfgMH78PBJ/r4/eP4FYf/6Yh uM3Hv78Izvn4NwnA/eCnma8F/5J5APwk83YfvzsD7/Hx/5sA7/fxu1XwIR9/ fxj8CPgR5sfBDzM/C36Q+RXwD5nfAh+SbNeBf8DsAd/P7AV/j3kBeD9zDHw3 81Lwt5lXgL/JvAa8h7kTvIu5BN7BXAZ/lflG8HbmbeDbmHeCb2XeC76F+fvg AeaHfPx/usGPgm9gPgL+AvNR8LXMb4I/K9nlBn+GuQF8BfNJ4H7mueA+5hC4 wJwE55mXg3PMq338mxngDLiDuRfcznwluI35evBlzFvBlzAPgi9i/ha4lfle 8Cdt2bDwZxf5tpWce+o8Z5luHFp/FJ1g76ZC17rOEvVLAa/R7ZyNSSENHMVs kZYKhIPbd72i0pHT9nHUKR9bGiKdvb0qHZ5+UW4Cx5SSve96HGUc/Th6cXTi aMOxGscKHOfiSOKI4fDJ++4bcO4rhvW/NP/73qRT2fqAH/s7K1R+6DCGamQs eOwZs/c3qPTksIlkIt7KdELvKx2nnp3haxwNXu8/R8Oyz3bOIrGVfT0XrPSG kadzsj3ZQle7F1O4vqJILYrxGWPVRfnC+pWd+V6vHMdwd2+oabU3k8XoGfNi 5iemL/XWOUuWJLxzzzl/1TxvoCnaFGgKfhj/w/gfKH4Os7WV+Y7SxnQhKx1U zqJWoavA80tWLBHmc2k4+aKzly/zzg02+eZZVlOXcH2rqTNd7LSaMpt6ipu6 5blUsJpWrjr/opRa6WsqZHPpprXFIlNvrmQ1lbL9JUqlC387cEJYHo/gaatp Xb4kEkp3d7VbUlkGtJfyeHprysiTSA83LaXX4lwq8Dm9Folmsv1Qz3fj2bQk hfjbOVJJ5JUuCY6xF+PDhb+P0lYVfqVlhls8t6plPZrD4XA/yvM6S8zt5DGR 53EuOaejY9whDjuRzw1iDifjuuRckI7amaPc96/EPFLoeQYxBcRhtXE6NXym z0Jml5wTinnhLNZp5DCaG0YNPYTTIeaWpHe8oXcm5wFz0xMw/tJx0yNG/tR9 z9F6NPcV81/PKHqfMPS2QW/bO+it1PWxC3NfOho+ZujV8flS1sN04Z63LIuO irmvqo82cU85l0ZcOqw9xv3cnGYXpzdWzrnpcD1UlR6l36Pve1+/ZdHhKo2S v5LWe+CoZdHhhJnlvcLQew16r72D3udYDj16VKDjtJ2j3PcfDN/B5wHYxfXE KH61z/BdfA48xr5foffh/j+9/6+JXubS+6OmvPW/9fH5fb5IKIQHMfERZ79z HQmFg5BBIRSIBKIRCvcH/NGA5bP+Dz6Y6qQLuCWtcHygQtInJAvn80et/yef qzFq2i7bbCGuyra2TsyHrZD4O5dWAczRSg6UanCUf4vOOCZHsKpRUIyyHI9Q RhIoY6qh8Y5nDsQmk++OSVrl3fJ/QA7NbKO9MSKDr45pc59K+zQ8bdYpNJ2l /YUer2i3gbI1/mijt573cdC+EGtLY5u11SPj3+rxijPtC5nEcUnvzi0WxR1H v/Foxk1yfBVni/j/XZbYIziZ+4qp6Dcof2Z6Sn8nfZ+gwWrc0iBltP9H/I5k 9OCRQ3MOPrujYZY9Tw7SH93deMrwgLvN3iH2iXsbvhbwNhwJDbqGar2W/F9q Mj7f013eaU2uOzj8OsW5ZYH8HhqlM4B06Peo5pYtYQeVryGXd9Q8Kt7SYE03 w2kPi7LvAOw2dJzX+Y3SQfE/ceW+z+o4Um41DE2U/4uX9fe+l/4Ap0l7DrkP HjvZyL+Z5z2oE6Q1dmh+m3Voodc28zlQ63Vv8Wh7724Qv61lDy30evbWeqfw /abvxL3LOwfrQmXLtbPBWzfghq2bLGvvGK9Ne6DIHjINq3HvGKtxt/uIa7f7 UKOoP0fP26g4yf8jndNt4HQbBuV3KxoqfQDXXF5K38w/xd8x9gDFmaR8e2Bs uXHA9dHBLbW0n9BJg/IodLa6Bxv24Zr88lbxW4KH6g9jBjRUv3jvlhnJusPI 41bXoF3eMTjRfXD4j5RflIfKMmm0spg2ry7PDlmeSWZ5KP+DlE8hp/3Mslyq bkeUSdQ3l8mx88gyHWt5ng97XTvpf02P3uaGfjvn4KNHowcPU36H3ML/PMjn ZNovt43z+xWp3zA058B20jmF6wBjsrtCb+yB7bei35hVtuom8X6+wyccPCzu 6fQzXseOZjtUYeZvKw5NHXTB7z3k9+gDZozm99BxU9+B8xicf4VzHc7P4lyP 8/M4H4fzCzgfL/ZjTh1swPkozo04v0TtaWDMoFv1aarulO/R/xpFf+JRfjco bQnftWawvkf870injr2qrbrN/A4dX6a+og59aq3qg+i34ihMlad6X9xkvf9O hB926X63au+eY9dBdXZ73WKv3kQcTeL37F8cakKbn3jwJZxdOL+Mc015p5f8 5TX4i9vcX/d+99WJKVP1K6h3eXtTvf9txN438Z6jnvUWFsUeHejpvWu08UHs P6tQUe9B1BY4tfVtCe0VMrc+Vb2BvCCX0XuMKD/ZjRXXF2YXildC1XLzuujN dIm8if0WMie0aa5i/1sXvyQuZHtzm9RbV7Ffp6IAvK2B9tuNGjHTtc7ZVmZG dIoHa7Zni8WOvhy05U4p2kGmtu8tzfaILWV634d681tfMR/i9VhZvce+FAlX tv9gWQl6/hmf0cnOMTh4huazjPXKjMEbDL7D4O8a/Khme5rBawzebPB2g+8z +DGDf23wnzS7JhucNPhSgzcafJvBu2bznlWc9oHnMz9k6LwMPoXf2NhaXoOp i3UqM4Ydaw7zYjBv6Ko5D7yUuRXMWz9qUuDzmdeDL2CmfK5gvqbsvIKs+TKY d7XWkK14R03NHjA/HNXcU3Zerdf8C/gq5p+BP8NMNvwC8x/B1/Mj73jwF5lP LqsZteVeAY4xf16Xy30zeDEz+UCS+etluY5BvA/MO1/cB7Qd3A9rO7gPl+V6 BvFT4HOZKZ/nMb8K5vUI95/BF0muHaPtUztR26f2RDAvTdfOA7N710Z13dWu BPcxp8HXMVO5bmD+Z/BNzD8Bf4n5l+AvM78AHmB+oyzXOWj5I1KWCwbEVKcH mcmGvMYx5ibwT5lvB/+MeTf458x3g3/BfD/4N8wPgn/L/FPwfzH/AnyUmWz4 IvNr4JeYh8EvSx5bD36dmdrRH5jJB/7EPBv8Z+ZF4LeZE+Bh5iVl57Fs7HLw WOaLwbxOMvZybf+6rZBPZd6j5ePCkH+E+VxDjr7CPo35JkMOP7cXMj+l5fUo ix1mnm/I2yDnLq6+CGb/rL8KzL5Xfz2Y22b9FjC/na6Hn9urme8EX8aMdmez v9UfArO/1f8YzFsl6+Hndgfzk+AtzKgj+3Zm+Lm9nRl+bt8heTz83P575gZd lvEol/1V5qAhTxt8u8FGn3xcDfi7zHj0sR5gnmnoUF99hLkb/Dyz0W9PoL6d 11AnnFqW65/EiwydT+t+YEKXId9WdvrbCTsN+TNlZ6vohN9p+fE3gJuZtxpy Gi+WMT+o5RNv0/3zxJ+Dg8zPa52GKQavMvhZzZMM/5nUpss4qdeQD4KnM99l yJ/RY8ek17W88XzwPOZLDPl9Os+NPzJ0ngafzvx7rT+5yeAfaPZ8XPfhnssM +XW67/XcYshf0Pn0vKHlU6h+ZzMbvjHlAvACZiP9KdcY+kYdTdmv63rKPxny Zwx9o1xTp+ryTp1tyKkeuf1Opbi8ljX1Ra1zwkc0TzPmANOMucq0JzVPP9Hg K/RYM/16LZ/xuh5HTnRp+Um+slz/JW4x5CmDrzN4t8HUVz/LTD75HPMbuq2d XAv+NbMxzzn5b8C/Zzba+Cmf0jxzQPdjMwcN+RNg7mNn0hjB+31mGm1tFtlz DbMx1zrtOj1Wnmb4z2k0Lu+QPPs4LZ9t9NVzrjbYaINzDR+e26NtMtfoZ+Zj PLJ5XX7+PEP+OOSTmY02e/pXIP8s8ze0fIHRxhdOMNiwW1NA+3bTYt0XNS03 dF7RvOhig2/TcRd9Xbe1RXfrOYCvTuv7jLm078ea/RMNbtccaDR4bVm+gyJe r+VBr8HUBluZd2h5iOzJA3ZogSH/IuT80BEy5slhPAvY05gv1PKIB3Ke90Zm znL6+cj8pGTEiQSScu4n+seljk0EL1PvW8CfNrhNvVtaKud105hpnPUyZw1e x+/eiDstnrOCL7d43ok/6/ndFHG3JfQiZ19rPF8tlfO9TuYrDf4S699cpd9r 6BTUFg8wbSfcykzPnNuZaX7+LWbadHov82acfsRMz2ePMF9lMM3hh5ivtnhs Xirv+QIzvbM6ynwNvU5i/jxObzGj/VJbitxRVRaU14bNI7+pkl8n5YLxjGA3 MGOebIeYbwSv0Da012i72co+N4N7mWEb+0rmvwVvY/478B7m22njDzPsZz/E jLmQ/Tgz+hxb2QH9sP0m8y48t6l87gafxHwnWPnJN8FzmVEnLh/zXWBVrm/T MyXzP4JVGb8DbmXeD1Z+dQ84x3wfuJ/5fvC1zA/w+19iPCO4VNnRP7gGmQ+B lZ/8kPcaEsNHXMpPYA+X8oeHwc8y/xv4NWb4To1qU/8O9jD/Bz2/Mv8ErNoL nkdqzmD+T/BSQ76a+TGwqlPUQ40q7xNgVV48s9So8j4FVuV9GqzK+Cvwfmbk vUb5OcbBGlW/GAdrlG9jHKxRPoxnH7fySfi722PIVbnwvONW5UI7cKNckder fLsk5dEzq+SsL/hVsPIBjLluZRPY2K18AM9Qbvh89BOjpE/y26rkrC8Yz1xu +E9018j2KOS/q5KzvmD4uzvD/N9gZXPYyX2jZOrm3exLtgvMvkR9gJvblF0L Zl+yxxiM5zg31wU9x7nZx+xxYNg9SuP+suHht9E+Y7VJ+Sw/Hkzj17nDw8No m7EZ9CwPRpqx2Uk5v2oEh+j/dsj36LGzwMtpIgc+Pyn3LqBOY5cl5ToJxo6Y WCdBOmgbsX5aJwGjf4jRM/UnwfCrGD2/X4j8EH8jKfc2UNx7wavkJo3Yv4I/ JZdxY48l5XoC5hCx58Cr5VgTewl8MefzTfAlkuNUxkvVFuVDxn4BZjFO8UOT 15B3vhsfeR8s9eUcSMqpT47XJ2UfP1nrSL894nB8clI+408xdNYYOmsMeZsh bzPk9xryIYPhA/GTZvH4AD49KRl2iAfBE6T944vBx0ubxz8Onsh7c8iXGrRv i1c63F/Z0yXHV40yRruNsdJtjNd1xngNjn+tMq59otaxT1b7YZbKNQeeS9gz xbtkyafq8d2mcYPHLLEWodoXPb9wH27P1eO7Tc87qn0t1GO3vUiP3TaNOapN BfXYLdYu0LbjdyWlTWaAv4e5lke2qfhD4CmyTcUfT8q1lHfyyXflI8Zelvdg ys9zqOuYYU+T40bdJfSczW6Wto2/hLi8fhgfTkpWOouNdJJGOksMXmbU1zlG fX2MX+kQLzWY+hb0KYnxsFUStoJtEx7c90zeDzaaTTxGeZMGUzrTvc76QyLm dZ5DE+eBW5gv8jprpIm011kjTXR7nTXSxGZnvd1ZzLcWZft784XSos58d3aR ej0jX+hYehtMu7WuvT2QapdbFTNN9E28RMnfUvA3Lwz4Q9FQLBgJxZodjDbT d3YLiVKgpRBo9jX7A5DQl/m9ImLw3SL29dBXNMW7DqiGSNXXvNDP8StDw1Wh +hYREeL3jfZp9kVH+5hpVN4mKhKrTML/DmkUO2FOGS0mihkMRCOxZvrrhFam HpeFiITDwTA0ZIg0n98nkvAHYtKETkQO9suogTAiduTyaaqUAMlCkFqZfN/a XBYiYe8YiUThHLkwrj9CAVS1uWy/zJE/3FKMFbLpXMK/wLcgGGju6k6vAwcD dKGV1S3J2BF5TxXk3INsF5U3V2GVmSArxTgXG/JdGYjiLf64deGSlbhYGfC1 zA9Yxfb2orjyt6RFkcPx5oCV6u3cVExnCqlSojUQaCmGColAkBXgdDLvzZbW KgVCSA0Rc+m12ZyIRkXdgJIGIhzRLyJGQoiotEqBMCzXvp7Q7yfnjwkpkT9C GCMMBoSC1acU/JKlSlyw1AmRene6X+vzhQjoLRV0AF+IgFQumy4a95bXRg6k wMyHEcVvSsw8mbFCwkXoEHeJtvTFUpmEPyhNkoKdYo6dgspOfamKSPERkYI+ J1LYiUQ+rPIl2oWRI5GTPpVi2GqnL/yKxH1WRnHQapeqMatXycL0pVZOtbgJ PqNsk8n2S8x3dMjIXT15GWNtbj0nFLQ6ivoqjKuOrpxz5U20Bv0t2bNSy85c vvLshG/BWanWC1edjYbRbK3N52HFHpGIn7ITCQkOjLRFcKSj9ekIoZERwk6E kIqAQhSzJVlFML9xGbdy2R6mTFdxvWO4qJXLqbJH6CYdiUCUb9KbCEbRDlJ9 iaBsNHRb1dyd1pDTlo+NTCD+ngmsT3XkSpzPsCWrJkj11Z7vyRRlnXenL89z RXajghh7C11ceanufCYrHSWfymQ3KHGfTI6k6zT25Lp61iuVXuUM+RRXfdxa n90k24pKFv6jMrZOgZNK2OI7IkcqsLfUSd8ylrlXF5xsCD0US7r7Stn+RGvI 11IMhFKV4pT8+mPITxYcJSgRCrAHBJv93KtV69G+hESo0uLVOtSFJUJBqrpR QiKhRCg0Sg7gmomQcsGozABV5+j3yG/syRaQVFC5Kv6Mpkf7G0kJQ5t0jqri wHg+bT1yEBgv0lJEv1UhVbaLVuTcCYHpqu0lwt7dXEJF5VDmX2dQxkf+Ijp/ 9IUo5C+GIShVIexNhOIt8/1xZygywkQisSoXkSmFfRUpOSGUXHVSTqBwzCqj cXL+iuRUwGipqTCRmN9K5Xvas0gAgyvGBycFkgrHCAcdzxQ1HghHjMSEGiWE Abxrc1Y2iaJCv1Xq6s5yR66GV0bZuqSGGgx71KSHhws1WDhDBbVL2gzk9Cwp HSOlo6RUnJSKlPrrPpSlNRxSc4GY6rJEQCkcEhmhoNYwTRhKG1LotVRfh6s+ eakmSKS9Od9DlouQ+uYUOjPUU3FjtlhSkypIM8USqRpTqy5RYnmnKLl7Vykl vrdDojAPnpCJn6UggXJPilfsRS5aw7HRctgzMoekLqonJi9LhT51LbPB6cVH 5CNWnY+Ykw8dUyQVtzoLqpoxBJW6E60ROHcwUuoWGVS26CYLOXbAZWe+r4Dr SEgFZ9KbcB2PqOs8qVP3Ia83ZdOk74+o9DbKCP64SnGTFAQCKsmuYkbUBpxW GqUDrSldXC/mARiQNCOrmCtG0IxwQwpa21UqJiJOtyznQn5fICRTIfVSBDPF /AayYCSIGgGn1qaL2UTAx5NqCDBWm5VP6v/D3rdAx3lV5/4zI/khO4msyInz gExskjhGsef9UoylSLItS5FkSXYMJOv3aDSyBo9mRjOjsc2CRkAo4XFBMQ6k hQsKheKWNASaFrc3JQZSrsvKXTW+JsstpoiLSnW5pjg0hZQGdL99zj7/y7Is JqXtXRetOLPPPufss8/e++zz+M+DJBWB8WbyIHMAmUNb03s6e/U9Ax39A32t bTTwoPDAGwdk0N+kojslIoDxCGcXxEIUAiFYbshHESgnEYls3RRh82AcBjoG Mzrh5LAiEYywdpnoSPZAIhJSsifkCHWfiZiQPkbyInM2M5ZB3pjQAGcupmkU b5E4IYnFsICKh8BlVFa3v6O1nWt6X3/noBxlyUQiR1TLpcvwViMZkhFMPhLK pXTgUICSMBCl9FiSbsQqJcJcMyBFzxBm20K4UMyX8yNj2SOUU1qYwhKGKwoU un/al0i4iCohl83nD04UqAC2NSAVLgLvj9Rsc4iYyMFVDCeiPqNDDQtpSMfZ 09bbs13f2drT3t2BaScNCJBnFL40EQ1s3RQNQmcxo26piWIReMN8Skl9JDmW yR6RYxu62i4N7x8lt5aFM4Y6VXvL6hxrGh9tlqTxHTKEqcEb1BLUSUCrQIg+ MWrMlILNAUQ0+f2Uf6x0YFTkjtIQByGdNhIaulAIq8UTjmwxGhO2KPXBSJlO KoNQyVRKbDgsWTRiw8sMrBdMNg1+yH0FKChaW0iyw+FKOmtwI1BiYKDcDsbZ 6MqISMxHRGR6bjSidsqhEuWgkQvj7oJumTCCt3RhHFSoHy6N6yOZIhxPDBqN BbceLukHZX+ZUJ2xTC8Gq+iCOSSsYDBGygSJ8Yk0/G6M1QmEGNz5RV1iJolR HprGMDbNFMkXxYRyCxl9JI/mFoMXiIUlEeCGkiASi3ClCJHOpUfAKVcNmDSN xUczkGOc27AgLAoRU6QYGvDu3nt26Xt62hN3+ZsE3N6xHY1ZgNSwO/pVSLTt /gQna9ur8PfuGezYpwIDHfe2AkZ3nB96iygJPclEMYeuPit6llgMYjQwCUuk mguUZXAiBwYxP/VHyiUpgbgPEuA2BRxql8/kKgkhFFp3aTaJIWuMxkHlEsjE 4pwAmVi/cb8xUYv51cgW0fBIceEb0IioWDFihaoCvliTyH9IKS+A1iQpUkXB S0U2OYzT2IU0k4jjga1pISC9tb21b7BzL/UJEjHQ19kDadpj9YHB1kF0C2YS iQkypr0fifr1nl6BDdmxAhd2UiSFRqCRg+b0Qwg6oPFMJ059np4vJGGpiXjI nMLGjemgMdSPB0WtwlvT/ffpA90dHX2ojwIlA34K2/kMWFBcHULIu6ZQC5RA fYXiTBhnPCLKYKsThbA9+lV6JMXIHqBQymCcRmEBoyJq9SMgKxInr81pRdao KCW+NU02azDja5JBwawsijomk7k4SiRMYtDv89kEZ0hLZqA1QYzxD9I4vYIR D9LDqZj8SVeN5JxA5vATVxiebE237bUwRQELS6mKwRDSaqkiOirkCtJwLVVE 5z1ieM8iTbgN74fgARGUXoLSymjpIigs49lvA1GSCdhdE4JTxBXF3IFiXnar bPpUikT5fSFjlS9oDiaIYcl8UCti+CFn6kU5EEFFxKom4dFxJtjpifBY8rAx PGjWihNiOzwyYOweDRQn9AkxSFejbyBKCiHHRcCARLFUMqsIVEZhZB0JM8wY WUnClCSGq0iEMrmRbDlhVEvQfgujYop2rnQoWRDyN2jnhoTBAhdW1GmJlXEx g37pQClHkg75IyaqmKoQKmTSF9ckEmuhmCoiV0mVDgET9qsCchmFCrF3GklO ZMuyF4UA0RVs1zt79rZ2w9q26339vdSSt+sDvdsHu3vbutCGZWBPjwgGm5p5 oZUJxLamu/W+1h0dItrXJAOc2s/B/o627tbOe8W4l8a8NIz0+6gN6r2DO0U7 H5DjST8AOZoMAOrY19GGIgf0NkQCRy6jwiX7fVvTe3t6e5B3b3/HDuTc297Z j2x77+kmPve27exHhr3dPV0wnb3bO7f3wh/ube/t7U9Em/aipm0YD+8dID7j yESF+xR9OSzwaZUcDZtRGJpwxFeRfXicV/4qcpgaJxtDk67o4i4vFCYbVUWv jJTGCJUeHk0XMWjxYzzh99OAAjEJZYgVuAbEhSguTHFUZr5ACaRdCkKUJKDs ElPHMsYjY8BFKFsU2Upl0REpQ61g9n8gTb1YjFLEkYIQCWW1FR5Ioc5stBW9 iNGzaGZcrCBIgTCXOpIhAYAorfn7A34QlaiEsl9wNlpUiai6Aaou47IZDKqU WUNcFUjcL2xaeERRcSl5v1aRCyP+AIZT8UglKed6PLKrJE3upVOgBKQqNWdA 2OrgELT5N4RHaKITNmSc1Kl0mprE1XyIcLSwmAgbQkvqtDZCaUhIMk1SupqY EIFEjSkU1U2iUgpFbVOiWNzhqKI9lD0oyKMSPsWmdBolKjISUkVWUrKuUR83 6opaEYK8tOIYyY366nu3d3bTyKP/XjSNjrbB3v43io6kdGRsJE83O1NCdLg9 vfr23u7u3vvICUiAklVS6cOpLKWJUpqejn1t5CbED8XDndM9xoiHF2jrF42U Oq3+e7t6eqktEyQbJWJ7+zuE+yiOSUbDJhsSEeECZSjK5GUoplVK6ZSyCUwY Ar5KiY2COwoKJ1NZ6xyZUelcWayksWnQNGnESMkGopAqLRtKs1Gu5COuGc1z kJpryR8NVPIFnW7+S/iD1CyC/q0jPOqnmFQ2X4KlBqkxBIMUxbwhTswp/EFq +sEwRTGHiKKLLimbGsUTLpNPlTEbClKbD0YpvTJnRJbS5RGKpOYejIvIiMHE gXRZyM4fIg5DgkPlS2ReFW34D6CT4mwa0TQaQL7AM2ekpRqFRI2UB6HqSpvw h6hSobCsr8+s8Fi+QrFUhZCognIuRJkamz9ENQiJGiinInKK6Zw/TBUIiwoo R4LYsYPDGbAfJpbCgiXuKUXWMRlJHIUFR9xjKhXIaGIpLFji7lNI5siY5CpM XIUFV9yVqtwyPkJ8RQRfqkEjfqR0JJdCJPEVEXyplk3qzCXhFUgcEWItQqzJ Vq5y01IMLQP5I4KvSNS0HJ6RRIitSFzkZG8goydyKkFTNBgxFZ0GLkq8RgWv 0YipuTEolRYx/FHBacxnMlKUxKLEZ1SIMGZaMTqWVJoim2IRq2SyFSJI7EcF +zHTkmGPojfy08KCPyrEGjdtuTDB0THiNCY4jZvWPIaRlZ8m5/6Y4DRuWjKU KWOJ05jglBb9KPp+jRIMp7MyAfEVk43IZxp3Af4IkcRVTDYin2nbwxMkIpqP +uOyCflN0y4ky6O02oUExFk8KBOY1k01yuQRTazFJWt+08CJuGjeceIszs3b NHFashCeJE7MxaXK4e6tDkC5yICPvsn7/OwirG7AkqQJrspUouyigQ9QVsl9 UA0aldOTvXNYIzGNYO4R8NFqx8iwWrVKV+iG8wTxRH160QirPl5mlN+JQ1pu RH5VDGtytQT04FLjgXF9HINsWtqLEDM0vBmnW614/UWtz2B6TtE0tsEIeSjB nnVczyZlLPvTcT2XPgyEX0hFjc/Gpb8BVrnRcb0AyZDzj3A5ckQXUr5ynD9Z KSc5TpOBQumt5oLpOM0zGBNjoqOZQ8my+JbFVNHjSUSYqQ4lc8MFcOIHfxgk oraEMQZV48a4k1wehgDjlvGfcmbAwdeMg0qQqIRo2CUQyp1BCoKqX3qwGBCH kpApjcHCcllY0pAYODGByY2UihUhJXZdRMdAhbjs4WIyI05Cx4WXkrTKmGTm y9B+JBYzyY/TBAe1NwYvQvfSJGAIgsdBEkMpEBsfUqpjAwNC6YSVPWQag1L3 kGkArOohQwlK1UOGFpSyh5RyWdnNkhfBmD+gjY9k0tnhErGGodXunZ33icHO bgyWxOrH7ntb9/UNvAljnd33dvYQFGzaLS60Bcnd2zv7B2iRZnd3K34jQHS3 7sA8ZPfAYP+eTky6Yk27aQoSpzU0WZIsOEwfvidonYwaBAqPiMXbDKaquYkx tZwgw7yay0u3GdM4ed02YxonL9tmnHIBxiEX8COa3iC1w1LIN54R7hkqiZKd xYzBDiJgFiJC6Sajj4uBEaFYN0DJERHhWDvAJYfp6xLhlIIE++QD/LRCT4vY EVXMWAnDlURAbDwSkxAWkUAbbTWDXlByo1prRgiRcWFVtjJTo8U2a7J1lZND tGspINbayxiuCznAJ/GSbpkGaQolawzc2MRhEysrLbGHDKxalyX/gzE/FRIU q9f6eJnYE3ugfGH1IWB8KE+1VRaf1cVeGcsa+EgxndaL5RwRoiUUER6ZQEsO BMiBBqKisxDkRFyyeMA0FMpflhtSMCanOZ+odmxrKRwZRqNAJPFEWggwT0DL D2ViwKtGtMBmM2OEZM6AoCUpvzC3GAV51oZeNSQRxlIrzW4FRqpDNEVCg02B TiVTo2nLwByoMZIdNXK2DMFsmrgiP4oBt+gh4wZv8AkqXpkE0GL3RFzZg8GA qp8yCiNCVZG9uYGnrkPgwwEbfgJmHaQtHWnYXjEF4WczB3J0U5SxhUjOs4Oh S7ZwTPgjYkGPuk41vWzWhlFvqa6YJvq9QeoDS8GAcpY+Xi1H5dADi7DUEDnP nNVVQkGKb2mUQ/ohhWBBD4llAFgAZiiwAEPaQ7rqTUjEseYhtRoiNYKw7NNJ 0sbS+Jhi3RfXMJuRxo/5DPwKghiCGiMJESRG4GX8PrWOSVgMikPMvkjE3YHk nzDi6QLz0zOhxEdxY0ZEmJFMNus3vz4LlK1vV4nSYEJ8/ZPC7+xt6wP/NM0C 41qKrtlIj1MtoIJQKDVurQSFRB3UMuy4lXuExOc845MmEGL+b3jjlDHgUMuw 4+KbA82wAiExmjEsnNIyuyG/uRtJVEd+JpG8lgpgNhQQzBZszBYczBZszBak EE1maUQ77LcwKxABC7MFK7MGnwWHoAmhGA8ai/dyRCVW72naC79BXS9mlROh EFsO5C849zUrLUAJTaIFNht1Dcj9RWF262immXxOkArTqnkpr/YnsVPPizkd khmDWKAOFenLbJxHsUA4elbC2HtWYBw9KzCOnhUYexMCgmwXZRutSFKm2ho+ CyiqHScLR+TAOpPTC8YOTQTURsCQClCVqaEN0Ce2AObeEwLUhxCgbVElfcif EI4HjOhDAYJjEg4KFiMyEBKfwch9N0uRCSqHQCUuqBzyG5+j9UMB+q4mOVSJ BS8s7Wbjeyp/2kbXRjt+faLLBeOO79tcSYNoSdUNVVM9MFD0UkoiEPYb/jRg bn7B7FG2V9oxFcuMFdE1Z8sZgwrvpi7KvTQjNLM1iTdrul5J6mIdsxyKayOY kcmdTGKhrRwIB8UGOLmyJLe1Gf2C3LVh9CvScnTV0YkekhqCpX9sFpulqKcA uyFa8xq1f7Ifpc4EBGkbAxcwKgRi+0g+qsv7iwzjlGlkNSKWpa5cWhUmPkHn 7IXlLi0sd2lhOdrhYf32THs0mCrtDgwU7FQLl1It8MYOc4Ajrk6SNMSWq5Kd RulSGiVpKEYDNfeKGIzRFUw006DdWMFI4ZCDr0M6pzAGSkBNWD6iIXjAssSM IC1ZmHsfgOArIS3bUShTOpWXeyTiiiwtQJmbUIAojaazwtean86YFPgVu71o q0uhbLCb0u2j/xQt3olodt/6EI2vzerv6ewZDIlNvEl6YlHMLWjfV8iXpKU2 Zb75Io02SsaKammMg2xaHGK7Qmh02Ox5J4zUXPsREyHrPmHS58qPWDCy7gfT 6QIkZhugk7AnyqO62PoRoG1fgYBYE2cHlhlW7otNX3mMSpouvEaPrnaG+cPN cgBLfaQciEUs+7/9asdUs9a6Z3CnvrO9H8084hcvgPGu0kAEbTMUkwqIhM0t ZwHebym34BkV4vbClbn0pTFjxVSO5mgBMBAxVguatfbOtkGdXgwjTkKSE1kE WInSF1HiS7HDPBhBtZdJMcWrA1wWDWsiUfNroShLvLpFhUU1kQstIyPqTevw 8YCjJONdrSpqnOXdiqqy6LElJmDsx0IfD8HSYBg25GO+ozTiR+OHY2XGBc96 X2unkFJcvMCqS88fDdDURj5Rpj4eTAwXVNcie31pQSEyIWVYYXLRpgE1yR12 zaV0qpguC4zYQgIUP+8HvoKSL66eeLmUtrknjHVvua8zOVagSsvlHq4STQKj AbXKzfbX37GbtmkG0GzRnrf7NUzlUok+8VtJ9AWiNEgXa65+zXIXYDYztOVA KnUX/ZYKyWLqrtJE7q6SvII+sDmyhW+u35LJpbITw+ktpSOlLUNHymm0xnRx 86jtpNlv6P566ZaSYqechvErhiaJop8wVEwiGgZI31DQuAiGCRQDUVqHCfu0 UqVAIWrB4ShCKWnQRWn7FEVT+IhfU1cIEiqCTv8QlesnA1aBgAgQNDQxIuCx 4bAAY0YzDJPj1PLZYW4RgphoZdyyiuJIVjJrsFHOlxFih4xa0chI5DJRsi1R 9RHI0P90sVgBWgYgxaKLd47RAGiIlOgLa0YL7otrYHUE84k+C/G+X197MMSr iUsfdXnpoxAbykpZw7b6yV0sqEIRs4D8mM6CBIIhwT9F5jAYkuKgWutcvR2B mBrihnxxoY4S/Ko1moZfB4SudxAtGmaPDCd2GCXsIKagQ6qJDNjupddqtPkX FwivUkGXPCO7hs8D3+0y78hX71gtc4Q9jrAzfa0j7JZngZfRPR2DDTJ8u3pT YI02/xNNPIPOt3PxRTSOcMIR3ukI9zrCe7nO9Uz/AUf8sCN80BEuOsKHUS26 d2Mj8/9bjvj3Ouoz5Yj/qCP8SUf49x3hz7F6XuLynnLEf8kR/rIj/Jey/vUa 8/NNR/g7RJtQTP9/O+T1ooPezx3heXvYVeMIX+UIr7WFzZYnTqDy0VN7KzIM XxOrzfLBZPH5q1gZOiIiqK2U89pYeiw1VtBUNrF4RMhSuiziCke0EpGWzZVo sIPj1qTusBWfNEslTTy7NCK4EZ00rTqgwdMPlUM/IGlpx9ZGa3Vuql2S79XJ kchbcmnAILLTpbKYgcridD2TH1Jn1tUrmHRmvU69w4E2tHa5usSL38rbJ+8z qF3NcBPj6X4Hn6ZdpdKHOM1+eYXCnSv5jD3a0Z2rGe7mvHQnQh+nJ3jQQh// Niqa91to4t9qhR9lOnR3UVbTrlP4AqeflP8MHh6y8PAw552SdzAYZU1x3il5 95JR1jTEouDjmna9ktvTgJXcTjDNE/KhjzUq/UmmeULez2TQPKdpDQq+aNKk uywUTbov6zZO41JyOyXvSTLSQ26rVJp9lrz3c3qU79pv8kN3Swp+Tsp7lRQ/ LiU3ol/WtBsV/m1MZw4wXVGo8A9xesJDhhsUP5DdLSoNZLhB8fOYBT5uKfcp pv8yPQJmoX+C6RP+pIXmOUveGZmX7pVxzVryzsm8An/RkvcVTXstw27E38o8 0z1Pgg5sw91o1t29jul45f1Pqly6/+lWrou7yQLD/usVzZimrVTp7wZepWm3 wGgX16o00NFrFPwBC/6EBX/etBn3BUual0z5u1+2pH/FlLlntSkHT70F7zXp eNCWX6fgh0yanodNmp4PWPI+YfJD9zAZ6U9Y0jxnof+8hc6MhZ+XzDQ1NSYP Nd0mfbqjSNl8zahp5zWwz6tVmg9Y8LBDr0oPO/Qq/Kc17Q6V/mnWewtg2Nh6 hX/Okv6UqXe6t0a1I3pHSthGi7zfyODtvNkea2Ys/MyadGpXcLk7JQ1lb7X1 TJPwjZb095t2VTts2k/tqCm32oIp/9qyKefaw6Yuah+ypH/Ygn/MlHkt2uY1 Cmaf5jos38Qy+GSfJvCnOQ39nmWY2vR5TkPwDMOUZtZC52WzD6p9hfPOyKGg SE9wjZl+2Qqzn1q22pTPMtjw7QpGP9WoYNjzTcvNUWKtx+zvVijYa8IutPFl Ct7IMMpcDTnfzPirbub0wF3VbcJXr5Mw3V10tc+E16yWMN2jtOZ1FjjLMHS7 5iELfJxh8tknTbgR/9YzD40KD/k1vsIwfq8DP2s5zXXQ70qGr5+SaZYVXvWD d0v/c9nfqhJ3yY4u8KbVKk29MSb/Pi74NP/UmG+Npt4Yk3dBo624XrKkU29p 3WAve+UKzbg33JbuFvs7QCshu+uPWfhQb4fdZq+Hd4bvv3fWYzPzxvy9+X6+ i4/KW6mZb8hFNPWGnPh7AHoTd0o56b1BU2++iT+d5jZ0T9dyxin+Ou3pRlYw frlmvqe2Wo6vbOka+T5HSldrSac73keq14x7h0z+/l/Z/2dMv3+Nb0zR3UTR cHjh978CPl8wErK8/+Wn978guchv3v/6d/i75P0vN7//5bpqn/RJrzzD3smL VrBRu0ncJ7ZMYFzq/msa/4t/teZyg+3dvTUOX+Wyr47c3S3/0RviKgZht8Dx eOyOp0VbdDGX2t37EL/PnHNIpyduAhbLU5mhLdnhzaX8Zr5bWNyV+6YFREBr Gvw+grjLkO8WFv6AfButl+xmXKsl33azfxS+rcWcE4o7yfjeYHEnIpny6y15 Nzl46LDAMTkHlILhX36vQt2NZvt7I88J72Nft5fxW9Ude/jrpwvh8O8eS76e /wBzu8kRvuVV0rO+Leq3wGELzHe9i3velb3yPeziju4tDpqqE7/dYjd835yx 3kX33t2hLgrX5H2bEUs/SutgdL8m+YHAZXr/s9xQlMXPWdbpEPYM29b5XCtr bOt8rlVTtnU+16qLtnVC1+pGDi/npaB9HJb9uyuu6K/k8GEO13FY0V/FU7Ru Dq/msKIn15jcW1XDv1qG36DoXSPD21T+eg4PcngNh/dzuMGxbnmtI9zoCK91 hK9zhK93hNc5wjc4wjcKbchnbugtqwYxRnFvFXfwMnPXsDzLDVKe16G+o5b4 m5D+aUt4A+g9ZKHXhPDDlnBYcw8rR9kgfJL7nmmaO90qw9uU/NdI+e9BfujH vZLTP4Dy2y3lHUT5Pku4iPDdlvAhpG+yhN+muUKHaV7F9XkY8X2W+Cnkn7KE H2X7aWyQ9vMxpG+0xE9rrrXoTl0PM70/RP5BS/wJzdVY4HVoiv868scs8WeV fa2R9vUdpN/J676U/vugd9yS/odKXiyPi5orSNdKPsbp/1Vzt83IdVWKd6GX 23rRzO9aifBOS/gapR8pf9f1iD9siX8t+PVawq9D+H5L+E6k/7glvEVzXUdj yVOSH1cM8c9b4rdprgj6Wdd5jt8Ffi/KdWJR/l60j/tZHvjP9YBqb2tEe3NB n1sfstD7LYRPWsLv1lxhCj/B9Kc0l2FPaN+uj3J7r+Hwp1GfFZb8n4M8qX1O cv4vKftj+XxZc109yOvkFP81lH/Okv8bCM9awt/U3AMXLfr4G/Y/ZE/wP67v Qh7U3vqY3hzyv2LJ/6LmunYnr5tT/C8Qv9+Md9fKq8OV/NxrYD/PmfTcN8I+ yV73i7B9/Zl2PxfLWrKcz1jWonkRXE/nKpliPkfAsCbWivUd3b33tHbrvdu3 D3QM6oOt93R36Jqui712RIE+rPFSebIs1s/F/8TC9oF8fthYBuclaLE6rYvH x8Ua9b3t4T2FYWR1rLvb1+mNggQtvf2NPa33drbxYrttcduy8s55eQVfl8xx DXkFX67Z035f/gIAdrZncsmsWojPFAAE6IIp22K8nhYPu9JJ6LaO9j39HXp3 Z09X644OJSH+NMDr+JKhAL0Yq6fF67A6hnDGK+38cSFT0KmSUhVSwOLTgPq+ IL8QqPV+XTzdTnssBPvGWr/124Ba97d+OzC+E6CqnaQGcJIrZeVgcqBzoK1d F4/TZ4akySwQkWLcGwf2tt7Tqfsl1iDiyGpmoJE37HM9z4W9y99a5jdI3Jt5 nOCSa6eXxO+wxO9Wn3hqo8//Mce/Wf6QX7tV9qnCZ0YYpvZ8G8PUd9yxlmH0 GxsVjDaXUDAamE/BaHt7FYx2e7OC0abvVjD803YFo6wmBcNPblMwfHpYweg/ b1EwfNcOBcNvtioYPqZXwfAvfQqGb4krGH5jkGHyaV0KRvvfrGC6XljB6Bfv VDDkHFAw+tfbFYy+8fUKhl9+g4IxBnitgJ+p92oznumWT3mm2z++Ydo7CY9L b2NO1dOCaNePXdL39kw13HoY4f/jEhOIup/SL7+zuebRJq/7mHu65lhNSx0G MVMfaZh5+Oz6kzTR2CjTd83w7/fol9/EFLM5DGq7nlz7v972ZO3Ja7gsek+z 5kztyRVT7v3yjczlz14446a3i/db3yBX74pfmEHcJ5+TA9QzCFM+eqf3DPLW Pzv/ovPdThMW7zZPOd5tfqgF/ZTl3eaeqcbkRfQfPeD/6aONt77seLd5aqph /UnQ6TnaMKQdQ1qk+6OPIB1+P8XvNiPvyp1It87xbrORF2mnkX8jfh81323u +gS/2zxlebd5UtLr+l3k7cPvey99t7nrI5d5t3nqCu82T8p3m7veW8W7zT1U H+R9+2m3V/E4Dh734Xe/fLd5/X7Ah/ndZoo/DNwkv9t8DOFDU40bLp5eveGi /d3mrj5+h5nyHESeKfkOM+AF323uarek15F+mtPr5rvNXbrj3eZHOX0f0p/A b/Ay7zajjtq/gM8Z+W7zBpJX78LvNnd1L/3d5q43LP3d5q7Ild9t7lprf7e5 63Z+t5nkfDvJ2f7Gcdc61OWi/d3mrhscbxyf/jW820z8uKcaJD+Xf7d51/f4 7d9j08Sn8W7zrovy3eZdL176bvOu71/6bvOuWUedPvZv827zrj+7zLvNU6dr vJOXvtu865Tj3eZJSks6sL/bvOsrjnebeyzvNl91DOmR5mH5vvCuR2G752Q7 3PUxaof4fccS3m2G3e86iryw5V0T/0bvNk/Jd5tTRPM9SncEk+2Z7zbvmqQ6 O95tjtjfbd71Lse7zcTvCGym3vFuM/mgHvlu8wb42w2jSHf/Au82T8k+bQP6 tF2DZ9zk83dFL323edcoyzUj323e9ZZX824zaMYu3jHd/pM7pne+dMd0N9rl Y6jzStT3auJRhc8sn955dvl0N/BehT+9fLod4d9y1oXoURzytJ9cv7/x5HrY E+C1N3xz59GG33OdWU99JMLN//QWhN97Zj34p/Dtm790tGH6lwivEOGa1Y8i XEF4tYX+pJVfUY7bW/9IYL/naJ13G/rXOVX2C+D30U0zHsiy/ph7ciX0Vgda 9VSPRzZNe6ifuBH9nuyjTZ7Puvc3HkX7gj2sPLve22ijF5h5Deg1HnO31FEc dNGC/n1uar22EjqYRdpuhGcnP6WtrJuUYw0R796/DuW2H3VrdaY8n51t0ZY3 yDEDxXnXsUzfzOOIWdIrjx+2IU8301Xjjas4L9G6QLQ5f5cah4BmC485xLgJ /e4c2SLDFxRvVL8pt8EX8qF+KO8FwMfWT65q0ZbNOfRs6AFtYg5pd0Jm5LPQ py0bUnw5dDN7WsjGG12Hdi7Ha94YyYvkB75qhW3Vew+fFbiWOtR/hujA/3zo aMOnTgE/8+D8/INsg6TrnVQmcG9VcjwjcWijy1oUH+QPgUO/v+yMox4tqh7S lqAvyAV81Rgykbg54FY4cLPArXbgZo7KPmIl89GCMpNKH2vDf/sHsOnDUtYk t2dnj9a11EHOc8di2ir8zhyrm1x1tIHk/+w06YHSKjt4ZNP+5Rjr3DDVIHFi HCp0aIRn1ib8P0K72stlXACdOS7jApcxaynj05YyZpB+BmWsRhmNXMYM0ZQ2 aIRn165ccTPq8W0uY0bYjCxjhsuYs5Rx3FLGLOkbZaxBGddwGcIuiI5Kg/Dc Wl++BJ3/I5cxS7rnMma5jAuWMp6wlDFHMkEZ16GMOi5jjmgKW3Mb4Qtrt+oe yOrzS9THU1XpY833XkQ9Ni1RH09XpY9Nq9egjGuXqI8TVelj2+7PHG143LVE fTxTlT5u3H877OrcEvVxsip9rP/mVovOr6SP56rSx7b5F1DGF5aoj1NV6WP9 fWGU8eUl6uP56vQxi/HS4+uXqI/TVelj2wh8yeMfXqI+zlaljzs/0QdZfXCJ +jhXlT4axtyw3VuXqI/z1fmr97wXshqy6GPGUY/L+Xalj1qUcdOi+vDVN0FW LRZ9zDrqcTlfovSxEmVcv3j/8dGPwF/ttuhjzmFXl7NdpY+rUUbDovpIjH0B 9fhDiz4uOOzqcn2t0kcjyli9qD7C738OOn9gifp4uip9aI/UooyBJerjVFX6 iGw8An28Y4n6OF+VPuIv/RL6OLVEfTxVlT5WHMaY4fEfLFEfz1XXPv7HV1CP F5aoj3NV6WNruA31eM8S9fFEVfpYs/fdsKsfLVEfJ6vSx6bDP0c9apeoj7NV 6WNb8xz08fIS9XG8Kn3c8O2TaB9/s0R9PFOVPjbs+jD08b4l6uN0VfrY9ssP Qh/32PrzGwW9Gf5dyEfVgO7Ni+rg1vNvt/gP2YdLeor+yQXkvgp01y4q95sO 7LOMP2S/Lekp+gv1DWI9ePGx7JEeyHq1ra+W9BT9cwvI93rQXbmofO/c8ueQ Q/si8v10VfJt+Nkfw8b/YBH5PlWVfLc+eQZ09y8i32eqku+Wz/8Y8i0sIt9T Vcm37vbvQr5fX0S+Z6uSb+J4J+Tw80XkO12VfMPNz0MO715Evk9UJV/X+uUW v7qQfE9UJd/IRAj8xheR73NVyTf+pz8Av3+/iHxPVyXf5XOfBL8vLyLf81XJ 1//6tbCz9CLyPV6VfLfW7VT+QdCMaZLXhsvampLxMtC+cVEZ13/jWdjwR5n2 LNO+wLQXas9KznWgfd3i6wt/vwK0P8u055j2DNNeyGcqWV8D2msW98Wvm1M2 J2hJ2rNMe6F+Scl7LWivWlTeN+zFPPzxr11B3qerkveGrwXB99EryPuJquS9 7V9/Adpvv4K8T1Ul71uT10Mm37yCvD9dlbxv+uEtsO/eK8j7ZFXy3vb+OGjP XEHe56uS98aTtD7QeAV5n6hK3te+k9ZQHr+CvM9WJe+tZ6k/fOcV5P1UVfLe 0vMMaIevIO/nq5J33Z+8BNr/7QryPl6VvBPfexq6fOQK8n7uV5e3+j7UIvZ0 0Dels+vFNwzjW8FRwPI7D8qQ6eYs6VZY0q1wpJu1pFttSbfakW5GpVPfGfjb Rgt9N3Z823jY+q2MvvecNOp1ybekiPn9RNqBqCPof3jTtFt+3wEPdfs9ZzeJ bxlz5jejBdKB1w8Hplec2eR1LTFtPdK6l5h2HdJ6+LuYS+2robxH3dAFfeN6 dv6/vwpZvN74fib2o+x3O76PzUlZtGhH66bnKfwCfetxT656oW7adaxuZv6j m6bRX7ascsS5Oa5+gTgPx62jOPpGeoX6nblS/WSbvqRu9RY9X7jkmx/qRPp1 lo3yflRleVddUt41011nFi7j4kJlyG+aLvlNE3Wn735s9zWwe1jEPU9wnOCB 992sIty1mvahqYbU5Bn5XfQh3s/1oacaNkyCt2VKzxfdglf35cvXNlAc065T dQL+SYKfQh2Qf52zzuDt4QV4q5V5vJR2leKBvpWSfZ92T2qo73UWugvyZdow ZFunaY9u2r/ukcT0Ot6TsMqQuz3O28D1VnTx67tM2s0Nxvdxu674O/LNC+Vb S3tGGqYfOV0HHdV5a6bq9s9zvZfxN99akofaL8ffoBVt0SaR3lPDNqTSyzao 0k23w16+qmRH6d38Tfmp+m3z9QzX22XtlONhZcOoz3nQOW8tV+mT8OwHPNRW Hgm0rAA/507TeLfOO39GwiqN+6jYsyP817kz67ddxO95S/3Og+8fKLlBVr2Q VQu1P1pLOod+4G/FfrfWX1zOFtW+MvueQ/p2fatX+gmyu9aLSjanpax+4qBX YBs6d5L7aEfd3yJkT9/Y0a+yfGZPblrYTiD7ay5jQ2SLK5QcuQyn/d3yK9qR Vadtaq8EfKPrjBgnTLcfg7zP3kH00GdKX+PUwV9beWq080hlLLfyyGVtVGWR HJQfgqwf4zZ+lvZBUf5lJj0KzzeacrXy3qj2nljtmuwGdoSxwrNneSxyTo5x DP5nwP8xynsRaRew6ynaS3YZ3zE1jTja1/Tg/PxPF/Mxlv2wLU+u/X7WsR92 hdwP++Ar9v2wD84vbT/sg68sbT/ss9Pg8zuOeOD+udGKM05g0iHCnenkcLqY 8Fru2kpVSnRKVWDSxWLJvDmrqeL1bw6IU+lb/IEt/qDXH0kEgwmf31s5WMyU RnNJb8fhgvd1dOVPZqKk0SVf8hBg3luaSI166VgBvffqva205bZSHae7S9wX SpcwteUnssO5O8rekUxu2Et78L22JHXMPJ+hkGcYKN9oMncgkzvg7aM7QPPF Ye9Ivuili9O8VIzWmx02ouggZk/6kC3cn76Ldvl7nXhruOQdzgjexpLl1Kjk ROztF/lT6UwlPezN5CrJbGbYK24W88q7zLx0GsBrq8B9yaJ4fcF7mYzyCrJL MxrVgzTprZ+RiSxSp6j26eE64kNcZOhtT+cyhNgjriyDDLzqEjlJZ0l6HxsO W3Ue3eLzb/FB59FEMJYIxZ06XzLdiXIme4kxBULeQCDhiyZ8vgUI3zaxWf0n zwTSuT73tj55htd9gH9L/PtOcYZenh27is785Ofnf0lnGfE7z+eGa/gsZC2f eayT971oy/hM5Co+27DWOLInz0Kh3bja5d0V4szj9XwGcjmfjVwh7/MR59VW V3vg1EMnvZ+d/ye+QOFuH4/3AO/08fgS8CDgHzK8H/A/MJwFPMvwYcDfY/gh wH/H8BTgbzP8ccDnGD4O+FsMP+3jsTPgkz7uBwA/D/h5hs8B/iuGZwF/neGL gL/G8CuAT0rYtQLwXzDcCPjPGfYC/hLDTYCfZjgG+AsMtwN+kuE+wJ9j+H7A xxkeBfwZlzr27Yo/Rj8tGzfcabixlf7NYW8bXThOzxyTBQa83ZkK2mOpnM95 O+gi6QIsMF3yduZSfI62WZxLnHy1J5NdzXOKH9kMfnVm5qUNG7+XufPDev/f b84B/6c+B+x6RGnMJf3XXeqcrkvyt9Khz3pH+GZH+A5Vf5dMG1b1d8n6t0E/ z7MzWyHO9nOY70kZVfJ0SXlWNNfVOy3p3+Eo7/2cvobTP4LwJN8vSeHHHOk/ obmuxwhn3Xmm9zmkP2nJ/wXN5X8CvzMcf0Jz+ejc7WoOP6u5AnROc5jD30CY fHeBw98CvVPUzJjedxzlz0IeKyzl/RBhklOcwy/C7dC56o1M72cIUx1u5vAv 2H68Uj+u5QhP8qE4CjfYy3O9BvnPm/JzBVWY+4t7kL/TlLerD+1hnyX9mxG/ z9Qf+hfZ97F+XROO8t5mP1fuepf9XLnrffZz5a7fsZ8rd33Cfq7c9fv2c+Wu z9vPlbtO2M+Vu/7Cfq7c9VX7uXLXOfu5cteM/Vy56x/t58pd/2w/V+76uf1c uWvefq7cvcp+rtx9rf1cuXud/Vy5+7X2c+XuDfZz5e6g/Vy5u9V+rtzdaz9X 7n7Afq7cPWI/V+7O2s+VY9xiO1fuPmI/V+5+yH6u3P1++7ly91H7uXL3Y/Zz 5e5p+7ly92ft58rdf2Q/V+7+ov1cufuE/Vy5+yv2c+XuU/Zz5e7/aT9X7v6u /Vy5+wf2c+UezX6u3LPcfq7cc7X9XLnnBvu5co/Xfq7cc5f9XLknZD9X7mmx nyv37LCfK/d028+Vewbs58o9b7KfK/cM2c+Ve0bt58o94/Zz5Z632s+Ve37b fq7c80H7uXLP79rPlXt+z3auXF2tlCqWM5tL8sr30l37UptThCqVJ0ZGAOo6 vSerd3cODOp0brzdFhrO6wey+aFkVh8u54slPTlxWDuQSgXoSQS6m2x4syZf QyrnxftCGp15pjcQx45c7n5XMX2gs82DxWSuhNxjHN+ephvatY6c+EECnc9o M0hHrPta29s7e3ZocpBkJ5wr50ez2iiGR1m+OXqzP6iNyvPam/0+e63NmqWW VjM6Ec81Yyl19LQLIbWZARSRg6wXPNKvDwy29g/q/ymP9gv2f3PA/z/ogL9m 3p3nojuWrrrbHAp2qkuDxORgYCLXO+ANb454d6Rz6WIm5W2dODBREhOEqPaq rw/8/zx/djjhHciPlA8li2kp4CQ9M+XdA2+TKWcw17oL8eJy+S0d3du9G4Ob fXeacyvXT/nuwVVi1CP6Du0OCxy06PUey5xx2AJXLPB/tcB/aoHPmrBrnQW+ 3wK/1QJ/3AL/mQX+lgX+Bwv8cxN2X2uBWyzwmy3wIQv8Oxb4M7eLG91oDuD+ 4u1075gY/7tPWdL8eNK4D8vjMvGejZPG3Vme0KRx35WHBtR8H5anc9K488oz OGncY+bRJ437xTwHJ4174T3EJ99l5nkX4CTDHwI8xDDJKsfwccB5hv9kku4t kvBfAn47wy9MGvfAe0iG72H4XybFPdZi9L1qUt4NT/BrJo17wGr6JuV9awS/ 26xXzSOT8g43gskG+G63ms9OGnfA1XxxUt4NRvCXTTnU/JUph5ozk8bdcjXf mTTuD6shPjsZ/smkvD+M4F9MynvcaPlrmSmf2mtM+dTeBJgXP2rvnDTu0K+N mrqrHQDMc4/aJODfZpjq9T6Gvwr4vzD814A/yPDfAf4Qw3OTxh36tT+b/L+M XQl4lcW5/k9ygLAEkpCwWGhTDIhAkrNvIdejBgrKohB36iEkBxJJckLOiYJ9 vJ4qbnV5XHDXerQudd+wtWoLt/pUanG7db2KguC+b8Veq9zvm2/mnzch2Mvz AO/5/pn5Z/lm5ptv3n/GPWdvaCSvzvBWmNt0k8Zch1s0vjAv590zvpbwSxrf Svhlje8nrNdbQx/Jy/n3jP+S57Wf4OcJf6jx64Q/0pjr8GONvyL8icZ7CH+q jwMcQfhrjbkf/UNj1gF9lv6waXleNwquJ/y9xom8e77+sEPzrutm2II8rysF H5dXZ2grfJKt/5INJNf+h5LfWvnwcJ7PjhI8D+Q0VnimanwhyEnPPfocweHb rHwElcWjz7gbMQPky0muh7gRWcJaP0eclldnJit8LmHdN0dcSnipxqTnHn2e 4og78nzGlGDqdx6tbyM259X56Ao/RTitMem5Z6XGrxG+VGNqI8+1GpOee67T mPTcc70+3pb0nNa1gstsWUZSuTz6foaRQZC3AL4WMIzJo4oJ/07jCsKPajwF wvBYvV3jLsLvaAzjdimP7fqMwdL983K2I+N6CHOiHQdKO0B+Vd4957H0ZpDv zLtnFZZ+buWjf5V3z3ccvQHkPF/osyZH/8XKx1xtx+cxL+fdcwvHvGPDlFUB PgrwLovLQX/Kl9sylveAvJB3/WPld4N8p507yr+28opFeTlvkfHxIP+DzXPF ExBmR949H7PiSxt+bB3gP1pcebgdwyt/DvKz7dhbeRnI37P5rNxt5VXcvvqc xyrQjarFefcc0CpIv+pMCA9tVLXRtnXVf4F8J4SHco0bZ8s7bhrIuR11/x3H cfU5suM+tmHG/9jiCWADTABbZcJrFk/8EeBf2Llm4rlWvt/Xdh75UZGVT/IR /o3GjSBPAT4b8K2AeazepTHr5Nsa77Z9bfIQwu9qDHbO5PMJ63OtJkMf/+nR Fk+52I5jUwogfzUv53oy5jmiWmPoazVcn8s0Bltr6tl2rpwK+jOV5+Wb9LGg o6x8GozVB5wOGPrgdNDh6d22TqbDODOD5iNzd8uMA0H+Csm133sG9NmZ15Bc +3pn3m7ls6CP15YChnqrC1jdrjvIjkV1CyDMZxbXHwf4ahu3/jbb1+rvtzaA r8SG94Et7XvKYv8YwK0WByoAr8i7Z+gGVlt5sBow98FmjW+y8hDXp56wQ7NA fh7J9U5vCOzkMK0FPHo/ILzEyiOVJNd2b2RKjfLP8zoiMiMpYz7FiQSSYvup 8bEJzvJtknHbq/GJgJebPcgmsesmaNyqzxNmnAa8Sp8rzLhdnxHM+CRz5myT 3J20XOMutVfgROasl7XPY1p+oaPPmG/iMz8tvkiHv2RA+B4I02u22Qjzfu4G jXmf/TqN2T6/S+N1jtzpwvhUR93tojCvz7ZqfBpgtuGf0/h0R8/NTfLO9zTm /eOPND5TnfMp+CxHzmpnfLbcgxS5XsoyZrktL983EHl/gPxskSt8ntwvozDZ yZ6QxhfInTKmDj3LbL15TP1cInfEKLxB7oVR+HK520XhK+VuF4WvlbsfFKb6 82zR+Ndyh4vCN8kdDwrTOOz5RuNb5E4WhW+Vu1cUvkPuXlH4TsLTNaY2KfJp fLfcw6LwPbym1PhewqaMDzri6GS8Ue5eUfgh5SMX/AfCazV+RPnCBZOtVWR0 4zHl8xa8SZ/3z3gzYaMnj8sdLgqTjhQZPaH6KDL68FfCuzT+m9znojDpTrHp U08TrtT4GV6/avwsYdNfaD1SPFvjvxNuAvmxGr+o/MSCqR2KTXlfJWzK+7rc /6LwNsKmvDsImzK+JXe+KLxL7nZRmObBYtO+NA8WG92mebDY6DCtfbxGJ0nf vZUgN+Wi9Y7XlOszuTMj8rXodsXFWp4TefTgAXIdXuEvCBsdoDnXa+qE6thr dOBruXsjulCncx+kz/KrB8h1eIX/IfdzRG/RYTba/qjknw+Q6/AKfyP32ij8 LWFT5/+Su2wY8zDv1brkKSKsdYnHAK/uU54hcjeNwkMBD5O7aRQukTtoFB5O mOo9yvP+3D17vqf+GRuSlLX8SMI8f83bs2cP9c3YfryWJ0xpxqYlxb6qIBxK yjnhlG7skKSc6U5rwtiipJwNTm0a+3lS/CQ0d8SUn4TSob4RW8t+EsJUnzFe Ux9JmPQqxuv3JZQfxrcn5bx6jvtwUs6ZryL8ZFLOgC8n/GJS/AlkQ8TeTso5 8TTXxD5JyrnxnM9vknIuPuE4l/EER+/9b4Yz+zVW89R2e+69kbf/EN7+/8AS Xmyg7Zq4QPkZkZQxfqwNI3q73cXxsUlZ41dBmGUQZhnIl4N8OcgfBvlzgEkH 4pNqOC9qXyg+MylzBdVDPJiU+/Wo/uMHER4tdR4/PMnnR+uz7pv0fKJxubUB PBMFx48S/R+7AOZoL8yVXpivS2C+Jhy/UcfV47a6J0WH8UzWXCjGP7a2hGeK uReA8P52fvfUOPIOxuyLMP1rmuEJNKk7f8z87uH1julftXbu9tTbudvjc7S9 28R76+7crXwX1LfjdyelTvYj/HuytSqlT8W3EK6SPhV/JSm+lH3p5A/i7ZY7 8e8w5+ftGj6bW/aEOZ8xaLs4tF3C2mxqv4DqNv4Jxf0P2X+O70kytmEOgnSS kM6hgOdCe/0M2uswR/sfm4TfZvDhck9EYiTVVZLqiuo2UUnvPdjwUAapk0oo bxIwpzOx2vU/JGLV7jo0Mb9a7pJgfEy16yNNtFS7PtJEV7XrI02cKv52tS/K gzPNI0NYF4eBfH/AM8EnnwAfO/jSnW7AlwO+B/BW8J+DH8nTDLgXMKzfPfcD fhrwm4C/AJ/5SMAxwEsBZwBfAvh67ZNnG+iOvMtDKmL/p74fo+hx668o2gq+ 9LppvL5QHJriRA3b56oOi+cWxFYn/Sg+kvAauaui+ISC2O0LwG537NztlIEN XwY2vFl3rIW1xjpz/4XFxbxvkiPduwp0rAz0isNkatieV/vixb8oiG3fBLa9 yc8vYXxbD2uis+x4pdbmJj/nQH7Yz09zW/H5NeyvVhyR4qsL4rvmOrmloOxz lZ97CV8KdXIZ5GED1MOVgK+B9dd18i6F2YeZ0/gGR/vKxVZ3CtZWd4xtc5uj bEqFb4e1zB3cGazcM8va7Z6ktds9TdZW95j8PwBrk4fkDkrExY/SPxtkfCje pDHZnMVParxr8LZTcZ+vYRtecUyK3yiIz5/r833Cf4T6/xPU4SZY2z4O+Emo wy3QjmTbO53WnnfWW7vdzDtsq7vryhdMdi0uZv/VJimXl/0Pm6Vc3jKNt0MZ R4F+ksg7kTL1P8J7884oMFZJe6OEX4Myvg5l3AbletPRPgix+d2y7IT17C5Y S74N68F35M5NY/+766z3YB30PqxlPpD7JRX+kPBnsEYwefjY2sC8Rhhi1oaf Es5b+3+IWU997jhD51mbf+hd1oYfVmZt8mFGz3cTfsXa5yVmHfFPwkbn/9dx hnut3T683drtw8066Dua0s2a9HvCZg21h/A31rYfqdcR7M8Zudna+aO0LnmY inqute1HfWRt+9Ima9uXXmdt+1K9fmRf0Gjdjzxk14++WWO+o1C3C9t4Y3Td so03xtg/ZOOVea2NV7bM2nhlur8z37Bc6wn78cr1Wob7ern2sfCdzBVm3qcx r6LT2ocVxr4i+2hsjbXxxup25PsYx75u7b3KmLX3KnV9en5CWOuJh8b1KlNe ml+qfmttwnFeaxOOW25twnGPWZtw/ARrE47X+sD+sfHG9juQhu1Z1j6cYOp/ JmFTLno+YYO1DyeY9P2EX+iPvQdTQbfJ2OWdozH38fkacx9fqDF1ae+RGhcG 7+8qzRax8Zi36u0siI3H/f2Ugth41Be8vyyIjbcAbDxjv82284Ky8crArtN9 XNlgRh/4zq1zwd7bCHGNnTzHrH0s9vI+3Wxd9gs0fm8fYzWHv7iG5wTFz/Ve W5D5gct1K+GFulz3FcRnbsq1GMp1BJRlCeClUK4lkP+j7FxmsJdt+CN0nh/V eB95VuE31bAvTXGEvc8UxK/GeX61IPuPnOedhE+EPKcgz8shnysAsx/VB3Kz PmqD9Y7G3g8on8slz4Pmk8OwbX+ScJu93xUYq3wOoQHPs1ryOaSccCfkswvy 2Q156wG8BvLZY+0iTy/oj8ZDJlA+u38gnxxmktjVilPJfBga86I72K4CeQ3g WrC9Z4MtfSJg2Ad0rgR8H+BnwE4GH74H9h08OcBXAH4Q8LOAdwD+Cuxn2Nco gvVCEex9FK0BDPs4RTeI7c0c86K7pvEenOKXF/0ZwrwPtve3wIeZAnyYOuDD xIEPcyjwYRYBH+Y4sOHTwIdZA3yY04APcx7wYa4APsxNwIe5F/gwm4AP8xzw YXYAH+ZL4MMMAT7MeODDHAZ8mNOBD3M+8GGuBD7MjcCHuQv4MA8DH+Zx4MNs BT7My8CH2QF8mI+AD7Mb+DAO8GGGAx+mCvgw+wMfxg98mIXAhzkB+DDnAx/m MeDD/BX4MK8AH+Yt4MN8DnwYH/Bh1gAf5nTgw5wDfJjLgQ9TAD7MncCH2Qh8 mM3Ah/kb8GFeAj7MDuDDfAJ8mH8CH8YLfJhS4MOMBz5MNfBhDgQ+TAj4MI3A h5kLfJilwIcBTl3JRcCHgX264fXAhwE+3vAc8GHOAfkm4MO8DLyXUuDD1ID8 eODDdAEf5hTgw5wBfJgLgA9zJfBhbgY+zL3Ah3kE+DBPAB9mK/BhXgQ+zA7g w3wEfJjdwIdxgA8zAvgtNcCHqQU5cABGgm9kJIzJI78DPswo4MNMAj7M0cCH WQV8GBi3SyuADzMZ+DCwZ116LPBhYG+39FLgw/wa5NuAD/Mh8F7WAx/mIpA/ CHyYzcCHuQz4MM8DH2Y78F5g37lsMeA3gNMC+lN+PPBhgN9Vfg3wYW4D+Tbg w3wKvJd5wHUBf1TFg8CH+ROEeQ34MMD9GDsd8O+B3zIH+DDHgDwPfBjgKlS+ BXwY4EVUVQBfBXSjaj7wYSD9qtMgPLRR1T3Ah3kU5NsgPJRrXBnwYWB/f9zz wIfZBnwY4MqOB/7tBLABJoCtMgF4thOBEzWxD/gwZwAf5lM7j+z3L+C0zAA+ DPAtJwFHYlIeMPBSJr0EfJjtwIf53Pa1SXuADwN2zuSzgA8DffynRwDv5VfA h7kG5H8HPswO4MNAX6t5F/gwYGtNzQMfBvRn6m7gwwwFPgyM1QesAwx9cDro 8PR24MPAODNjPPBh9gf5fwMfBvrszA3Ah/kN8GGgj9cOAwz1VjcL+DBx4MPM hTAfAAcGfLz1lwEf5kbgw9wJfBjgU/nAlvY9ARyY4YCBbxYArlFgGfBh0sCB 2Q/wRcCHAc55aDzwYYBvFjoT+DBgJ4dnAx8GeEGR0cCHmVTD47BaR0RmFWRM Nv7Jn4GvbB74dRcAXgg+3kV2jansYZPOkeBrXQJclKWAubxr++NIRO/Pkm0U OWQ625bqO9AIz5WHDViTlgBu2sceJae5sobtT/X9XyRXEFu0CTg8DnB4SoC3 Y3AH+NVPAv/naruno3g7xgeYAV9iD/iWNY7w2Nuqy7h+Oo9X+tvpzXvvbXH4 i2t4P1F9jxm5oSB7i02wt+gAJ6cE/PMl4J8fBTycMvDVHwv++Rz459eDf/5c y7Fxy3I++HIvsPuJyt42vtOLgQt0KXB+Lpc9O4WvcLTdqTk2Jm9XO8rnZXz4 rl/9evDH3gA+do0jzNk+Tdct2+H/OZjOaN8Lh/9zDfNt1LeQkecKinvDyUVe K4jfep714bv1fA/U5wOAN8J+x0OgG7+DPYsHQP8fBl7WI/Tfzf1x5G16eI/4 xyK8BryXMK0xIjyG30f4lX34xjnunhq+m1l9MxkdWWBsdeZJKMsW0JOnAG8F nX/a0WOl8HNc/X8Wyvgc1JXGUZ6vtwzwe5T032OK/rhG3RHN37pGeSzaBvl8 A/L5JuTtHcDvQv2/D/X/gfXPqDVXyPrbndnWx+5y4T4DntsXoMNfgt5+ZY56 EB+7q7e7Hdkv1750z2zrS3f3fb519JpE/OfuXg+tyzzAh/FcZ33mLsfsXYvZ f274Zuw/97zQH0fZtnlTdD7Ktt928bVGed7cIboUZTv2LdGlKM9NO0WXojw3 7SL8wj7G2OnQd+4DzO/tqeH9SvVNf3RdUvYxKW70DOE5xK4CLqIDe5olsKdZ 2R9Hn6nhcUidGxB9OSm8QRy7HNhnLIFxrLo/jm4Xv1nsdaeuQx3+4dS1t2Tb nbq2dd3ZdV3yf67XqVt61KJj3O8a63rTnS11K7JZjXo6c06d+vyxTn0GWqc+ YazrzaiPKetWZXIqoZaujlZHAssD9Y0s/ZD/VHr00lzLCvo/16v/b1lBibal 11LwTFdXujsnQvq3fe9AKq/8k0G/j5OPzVU3VC+mv0c3Buv89P+SxkG/6QtU B33Vi1vVt4+R6kNZ4tRne1pa0/W96WxPR7c6Wijb21rf2bGC/7Y2VNefkq3P dAfi0dpcJtOZrefKyvb0ZuqXHkrR61dQpLo6+NHaWl27dnGQ/mldFYtX1x7T Mqu2dVU8QAL1JpL4ZtUuyFXXUq5r53d0U/im5jnHNqeaFi88eP6ixgOmqPZY vLSZ/i6Yf8iUAyhY/1zS63OZej4LKUVyyi5nm1Lq7Guj9Furq3syvbn6Venu eqglefFamo3tZ9b16bUqaHumK11vDkuSs5WcOntc18DPnEmdEjl/Y6+/oTbg D0VDsWAkFGtwYbTBaW1v6U3kAo29gQZfgz9AEv4ct1pFDP5QxL7ubMeqbnWM FQUNcVBfQ61fx+//NDzgqX1FRD3x+wb70+CLDvYH0+j/mqhKrH8S/n2kkW2n 6pRoMVXMYCAaiTXwv+7T/qnHpRCRcDgYphDyRKrP71NJ+AMxqUI3on7sl6iB MEVc2Zlp4UYJsCxEUqct07eiM00iVd8xFqnCuXJVuf4IP+Cm7UyvlRz5w43Z WG+6pTPhn+WbFQw0dHS1rCIcDPAPG9i8kis7Iu80j9x3cN1F5eXmWf9McC3F dC5OznS0kSje6I/Ld/qJpQFf44yA/lyffvkbW1SRw/GGgJPqaV+XbWnrTeUS zYFAYzbUmwgEdQBSOsl7g2ND5QIhSo0idrasSHeqaFxU6iOJQERH9KuIkRBF NKFygTDVXOtqhn4/K39MSRn5IwxjDIMBFcDpMwH8giVIXGEJE+LgXS1rbXj9 Qz3oyfXaB/qHepDqTLdk4d3yG3IgAswHRPGjBPOEsUJKRfiveku0sS+Wakv4 g1IlKaqnmFtPQVNPfal+keJ7RQr63EhhNxLrsMmX6heQI5WTPpNi2GnlL/FV 4j6nzeCg0ypBY06PkYUprbRONbuOdMbUDU0fAjMrV0rkju6MxFjRuVonFHRW Zu2vMP1a2dHp/qpONAf9jelDUnMPXrB0TsI365BU85Kj5lDHaHBW0NSQbulW ifg5O5GQwoG96yK4t6L12QihvSOE3QghE4EKkU3npImo+uFn3OlMd2vU1pFd 7VZc1OnsNGWP8EtWJgJR/ZKeRDBK/SDVlwhKp+HXmu7u9oZOW/OxvROI/9sE VqdWduZ0PsOONE2Q26s1092WlTbvajkpoxuyixpIw57eDt14qa5MW1oUJZNq S59sxH2SHEtXWdjd2dG92gTpMcqQSemmjzur0+ukr5hkSX9MxlYZ4KYSdvQb KUfmYU+unUbKNsm9+aGTDdEIpSVdfWRBJZpDvsZsIJTqL6ZqaVmVTYT8XIOD PEqEAloDgg1+PaoNDMfnTiRC/Wt8YBgewhKhIDfdIE8ioUQoNEgOSDUTIaOC UckAN+fg78ic0p3upaSCRlXpn8HCsYnIgWhqE+UYUByqPJ+tPVYQqrxIY5bG rX5SU3fRfjl3n1DVDawv9eyHq0sFMTmU/NsMSnzKX8TmryWX66X8xWgKSvUT 9iRC8cYZ/rg7FcEzlUhsgIpISmFfv5TcJ5zcwKTch0oxB1SaTs7fLznzYLDU zDOVmN9JZbpb05QATa40P7gpsFQpRjjoaqZq8UA4AompYJwQTeAdp6alS2QN 9KsDZfRAbqZXDaV3SQgzGXYbo0dPF2aycKcK7pd8FIs7sqRsjJSNkjJxUiZS ak0flaU5HDK2QMwMWepBLhxSGeFHzWE2GHInp2jUMmMd/eqTn8ZA4tCnZrq5 5iIc/NQUDWbUTtlT0tmcMapI2pbNcVAwrTpUieVNUVb3jlxKrd1YFNaTJ8mU Wc8Co54cL9tDuWgOxwbLYffeOeTgqnli8jPX22d+SzZ0evG98hEbmI+Ymw8b UyUVd9p7TTPTFJTrSjRHSLmDkdz/tXc1v7EsV73fe0lIlAACRWLBgk1WkV8y 3dPd0z3mEjm+9n3m+dq+tq/fCyA182l37nz3zPjewIoPsUGCHWIXiQ0SrFjn D0BixX/CX0D4/c45VT3jdxMJRARS2tJ4uk6dOnWq6nxVddXUVBh0fTFlD/l+ QPJhvlkhncYue9h7h3SeuvSc6DQfmn436hE/TB29Ry0Q5o7iOwVEkSNZVkMZ DQitdsoY2tSr3kgcAIdUP4NVxIop1AgVMqtfrqtu6s2yxkJhK4qVCtHXKSLF +ZY9mLYxIngu+r1q1I1aFlQDAF+9O/hEZ0+lEN5yDjL3KBw/G70+uyxe35xc 31wdHTPwYPrmBzeaDA9c9pkCIsQjVlyIxUyBECQ3bjED9XTT9Nm3UxMPgyHQ 8cwUhGlY0W2nNrpGdDy576ax63sCx3Sf3Ux6H5G8FJ6U0xJlMxkBK4zZK6L4 nR4nkCwm8rR6BJcdbe71ydFza+ln12e3GmUpkpToBLPRGtZqXLKPIPJpPBsU gKEC18MAVKNpb7YuB1U3sZYBKJ4hMdlCWmbT4+nkHUuqhDkoIdZQgOD++ZPT hKWuhtlkPn+zWbACkzUAHSyF9Qe2yRwyNjOYimG30/IONZHeUMN5cXx5cVp8 cnTx/PwE004GBCjzAFva7UTPvt1pY8wy37bBZrUC3ItP1SvGvWk5eaexDaKW +xGsf4dmbQJjjOF0+jYpLLcWPv7wGOM7FEio8J5al04CowqA+MSOnym1DyNk HIQhy0+r+wcp3WGIg1TBn8TyY+EAuxJPGGWxk4ks6ngYUPF0MAjqDQbys7bV zojswbWAjQsmm54fmq+ISdG2WNmx9HY08dwISAIDZ3YQZ8OVkUjWIhHFN6WR 1jmDSsptXwpx96LYmTCCt9FiCSr0w9WyGJcrGJ4MI5q1n72tijfqL7vOGSu+ BKtwwZYSKbjNOJggsdyMYHczG04AJLgLpS1ZTeLBQtMMsWm5oi3KZHAXZTGe Q90yWIEsUSKA9XsgkqXWKAJGs9EYnFrTABkxFn8o0Y+56bAQlkpkipRBgV9d fv/3i9cXz7sfhwfy/PzkFMosj1Tsk2uXEt2+7hra8Z2Dv3x9e/K5S9ycvDzC M9zxvP9DqQmeZLOawdVPxLNkGbrRQ7o7mW4usNbkZgYGMT8N03WlPZC30AOm U4ChdfNytu1Kp3Dd5bAmhqIZ46B1BTJZbggoZOObh36iloUuskU2LFIutgFK xGolYsVQRa3sQMo/usGLoE1KkQ0FL1tVOcRpZkIO2cV59GwkHVQcPT+6uj27 o09QwM3V2QV6cz+XvyJ4C7dQoyikbZDn10C6Li4uBRrvQwWWPKXIAU0xIm/q 6Yd0dBTYTCenzyvmix4ktZvH9RQ299NBH+rnbWlV8mx0/Vlxc35ycoX2uEdl IGR6n89oB2TNIeDk9Oj1OVuBGugrHGcinHkqdZjUSSUmj6HDByoiezzKoNzm jMIi3xC3+hFpQ3JabcOVoh2pJX82osx6ZloHmhRmtSo6ppq5HDUS0r0NW629 jvO9pQW4JogY/w3j9C0iHuDDqNT8qakGuiFoiZBcITx5Njq+22GKiR2WBlvP EHCDwQqOCqXaDNcGKzjvsbeeK064vfVD8l6SaiWIq9lqIpjWfLPbAFSKYOaa AMPIHcXZ/WqubtVEn7UoKGzFfpWvXQcTZFiZbwcrhB86U19pIIKGyKom4XCc XTN6kp723vrw4DBYye9TsgBi90602hQbCdJd9A1A5QAaFwECEquqqpsIUOkg 2kZChgbRRhJSKcSaSELlbDxZd32zhPYPDZQ52rPqsbeQ/ve0Z30RWMASR51L rAbLPP3qvpqxp+MwrUGrwZaguKZf3s96E7IWZ66K2XZQPQKShK6CWelAsVmn cY8/YyleFB0IV3BanF3cHZ1D2k75u5vU5NPi5vL09vzy+FPosCZeX0iyfXBo C61GIHs2Oi+ujl6cSHbrQBOGHVry+uT4/OjspcS9jHkZRoYt6mBxefuJ6PmN xpMhHjSajPB08vnJMaq8KY6RCRhNxtZqDlvPRncXlxcoe3d98gIl756fXaPY 3ffPyefd8SfXKHB3fvEpROfu9Oz0Evbw7vnl5XW3c3DHXxhFPHx3Qz5zFGLl LUdfw4JWsJ0xbEZlUOG0tVUfntvK31bD1JwyBpXeYmq+QYCemFJti+24mhI0 Gj6MVghaQsQTYciAAjldJ4hbmAbkxcxLmMc65wsiqFwKIaJETi4xdVwjHpkC lrJYB8WqtTgiJ6hbzP7vR/RiGTHyZ3y1BaVxUru1QAptNqHdFitEz6JmVq0Q ZCKxWsclOwBEueYfRiGIKqjr5BecPawcEpsbsbkGm5QIqpxYo7u26PFQZFos ojRcez4MtrowEkYIp/J029O5nkV2217NvRoFInCo3JwB6V0Dh+SefUN6zIlO 4vu4V7B2Tk1yNx8ijAuL3cR3Wq/g2ghx2EmK01NTk0kXKGjqQGybggYORN1U kHV30nG0+5M3Qh6NaDk21WhUrDKNXZXbgba10zKl3roVIfRXsJqy3+irX56e nTPyuH4J1TjhLxr/QBxJ9W46nk8mc6phBId7cVmcXp6fX35GI6APRNsORm8H E+J0iHNx8vkxzYR8MR/mvLemekSwAsfXoqR0WtcvP724pC7zSZUSuZfXJ2I+ VlNlNKnZUEBqFWqqY+Q1lQXbajRwMoEJQ9TaViYU5iiY7g0mu3NkA41ma1lJ M9HgNGnsMU1AHNDhmqAc+nqVjzzw6nlLda3CTrSdL6DCnNy0qRbt8NnYon7m yO8fI4vK0G4zy3hDnswpwjZVv50wyzhE1uOqXLOYi+IJK+eDNWZDbep8u0N8 J87IrEbrMTOp7u1cMlPPxP1oLX0XxuQwFg6dLdGyLtvbD4B7cu0QaXoFmC9s 5gxctiiWFjkLwuaqTIQxGxUn2t5W3eDpfMtcNiGWJjjjQspUtjBmC2JpgTMq UlKmc2HCBiTSAGdIkDt9MyzBfkKWEmHJPKUUnWomOUqEI/OYbgg0mywlwpK5 T+mZd1PlKiFXiXBlrtSV1vyUfKXCl1No5I+rd7MBMslXKnw5zeZwznqwCuyO lKylZE213JXmUgyXgcJU+Eo7teTYjCQlW2kuJc0aaPZm5hAOOu20HugRYB3y 2hFeO2k9clMMKhcxwo5wmrVqRlZKrEM+O9KFWS3Fsu+BmQdZutszky0Jkv2O sJ/Vkiw/lH7PQuS/I92a17K82Fh2Rk4z4TSvpXmKyCrk5DzMhNO8lmQMpuaS 00w45aIfs/8oIMJwNFEE8pWpErVq4V7AHiGTXGWqRK1atocbdhHno2GuKhTW or3orR+42gUEcpa3FaGWbraonCObrOXKWlgLOImLeufkLDf1rkWcSxZiSXIy l+uQw9zvGgBnIqMW38m3QjMRu2ZgB+UApqoeRHXRgEcsqty3XdDojJ565yRg N40x94haXO0YD92q1WgL+1l1yRN9+sqnnY/XgvqeOA5mY32rmAS6WgJ6MKl5 tCyWCLK5tJeSGYY3S+5ssvUXtz6D6TmzGdsgQu53zbIui0lPc82eLovZ6C0A ofSKi8+Wam8AdWZ0WSzQMzT+qdWjEV3sbOXSXlk5I7nkZGBR/aheMF1ynmGQ zIg+lI+9tbzLMqrweApIjGq/NxsuwEkI/hAkorWE+KBq6eNOmjyEAMud+M8Z M8Bga5ag0iaVmGGXAJw5Qy8I1VAtWAbAYw99yhgs0WVhpaEQGDGBzMbVaiu9 ZKaLdDwotrqHq14pl9zlYqWU1hqTzPkao59mWU1+yQkOWu+DFxl7FQkIgvB4 y26oomzZd0NnAgaAGxMb7H4tDG64+7UA2FD3/SC4oe77UXCD3XeDa4N9qLwI Y2EULMflaDKsyBpCq1efnH0mwc4rBEuy+vHq5dHnVzd/gFjn1cuzCz61D14d X76+4ErHq9Oz6xsu0rw6P8J3CsD50QvMQ17d3F6/PsOkKzt4xSlIzjU0rUkr Tvjie8N1MioEKk9l8bbEVHW2mbrlBE3baq4t3Za1cNq6bVkLpy3blk/7BZAn /QJ+RPVuqYdV3FqWYp4xJB3KWeaDHWRALCTDjU1ZLCUwIsjGBiCNiAiz0QGs N+TbJcLcAAn7tAEhV+i5iJ26aqYVwpVuJBuPZBJiXSRgr6slvKBy47S1lE40 WOLqdmLqNfYwUO1a9/rctRTJWvsa4br0A2ySLemuGaQ5kLYYsOnmbQ3VRiv0 0UPduiztD2J+VtKW1etiuSZ7sgeqlbgXAcv+nK11Ej8pZK/Mzho4L6ooVusZ CXEJRdLjDTQ5imhAo444CyEneb3VfS0oLL/WDSmIyTnnk2Znz6okHUIpkEme OAqR8QSwviiTgNdFtIBOyimBxhkAXJIKRdwyJm3WBq8aK8AvtXJ2KxAdDlFF gsGmgAe9wcNoJzAHaMq+o5KbZAizI3JFO4qAWzxk7nmDTXD5TiQAlt0TuZMH z4BrnxMKn+GaaNbcw+k6BJ5Ee/ANxLrNLR2jmV4905uU9zNupPVbiHSe3Y6/ sIVjE6ayoEfX6aaXh8EQ7dbhygLxe7f0gVU7csayZavlaBw8sKR1hGg8Z7um EgPk+Fah7BePDmAd3ZdlAEgAZiiQAN/b/cJ5E3Zxdth3qyE6IkirT2dP+6Xx qWO9lQeYzajwYz4Du4IkQlAfSUiSjMDKhC23jkkoguLY2BckcwfKPyFyBU39 6pkgeSnuZ0SEjMvJJKzfPgtoz7c7pBGYkLd/2vlnl8dX4J/TLDAeDHiZ42jJ VmAI4niw3G0EU9IGtwy73OUeKXmd519pAiDzf2+NBz7gcMuwS3nnwBlWFEs0 4yWcuMZuHNa7kaQ5+ppEea0WYDaOhNnFHrOLJ8wu9phdaCfWzDKiHYY7zAog 2mF2scus53PxpKMJcIy3/eK9RlSyes9pL+wGXS9mlZs4NslB/wvnrUM3ChiE A9HAQ9/WSPcXJWbWoablfCakEq6aV3O3P8mM+lzmdEDzQSxAjyu+mc0tigXg iWclZN+zAvLEswLyxLMCsq9CAFB2UbfXIqXM1nqbBRBbZ2hJqoF1OSsWfocm Em4jYOwSbDIV7Yav2CLMvTfyWPSR4LaoquiHXTE8YKToR3zO9LktLKaaiOU1 GM33oXaZUHkElVyoPIb+dXTxGPG9mnLokIUX6+1D/z7VXm3DtXHHb0tcLhh/ 8n7bGumJVq5taJrzwAD9aLRC3JCE3p5G9eYXzB5VX7ljKiunK7jmybr0VGw3 9Ur30ow5s62JHwZFse0Vso65jvNgjBmZ7mSShbZ1lLRlA5yuLOm2Nu8XdNeG 9ysqOYVzdOIhqQg7/vFQNkvRU4DdmGteD/uv7B/oTECQ2xisggfpkL2X5A+F Xk3thVNxtBnpzlLXbOQqk1fQs/3KZl+sbPbFymbc4bH77pl7NIwqdwdGi32q iy9SXdjGjjrAkVuxlYZsuar2aVRfpFGpoHgFrfeKeMZ4uzZnGtyN1U4Xj0/4 eiwMwwdKAG12XqIheb+zxIwklyzqvQ8A2ImZne0oLDQazHWPRO7IcgGq3oQC QPUwmoitrV+dGSnwK7u9uNVlsfbsDor96H/AxTvJNvNd9Blf181/fXZxG8sm 3t5kYnML7vuKWz0utTnxna8YbVR+RbWaWtJEy1ImV0g9DGvPu/HY1vpxDdC2 b2r61vjxDkTb/mY0WqDH9gJ0dvZm/VDI1o+I276iSNbEzYCVQ2e+TPSdxdC7 6+DR3c6wMDnUAJY+UgOxdGf/d+h2TB0GR69vPyk+eX4NNU/DYFgO1rarNEqh m3GmA5Am9ZazyPZb6hY83yDTF2vM65vru9FsOF/dLEaDclwOun7FVKM5LgBG qV8tOAyenx3fFke3t8JJrJxoFWClwzei5MuxYzz4pNvL5Jiy1QGri2FN2qnf Fkpdd0fnr2nd0o4e6Sp4Ox4r4zp8Hj2piZWX/c36f9Liie1WdI2Fx1ZI5Pdj wcejYxkMQ4ZaxneHET+UH4bVGBeei6ujM+mlPBBxUcvfiTi10bsD3cuDzXDh XIt6fZWgmCLkBCuhia4F6EB32B1Wo8FqtBaIbCEBCPVsuI804n6wKM1d8wYP 5WTIbe5dv+6t+zp70wUbrcs91iROAjuRW+U2+bs+ecVtmpHcYNg9DQNM5Qbd K/nedq+iDoN0WXMNAzlyNpkPehM5K3c/GHzMbzmO9nG1mX1c6a130XfS79pl ee6E2nerd9V3++/WI2jjaPWdh72TZg3dXyzdqic75ezGye4qJITVdDsJHvkO BcrFZ4jAKupwHSZpBdV2wRQ1OOkgNVCBXqnsM4tT+JSbs0dqHQBK4fQfWW9I AXaJSBJ86m/G8jwdJvKYeTVMaDh5a6ZphBATLTPNWsmRrN7Es7Ger5Eyg4xW MTKSUjVIdYnNR6Lkv0IWK0DLP+xcxEkFYIjUvUoCr8FXuV0US3XwxK9+cfrg uxesLSbv4M3vRfnRbbwQdDe91z7dxYIm7N3JSoA9Cf/MnCEY0u7YuSy1+yLK XIgbt3IZjp0LSSXb30SLFGjpDbbdF76GF2TKbj7VRGBX+f78Y6eK0xw5bY6c /h8eOb26RAx7Qv8eir9jSBtx+utjW94xfXz7OZfKwHzG9eFRfQC1fei2kOoa UhTvnIG0zaGmS5GL6lI54EU/n8iearu6Giwl/gZgavB8s15s1t1FxMOo9RM1 fxEHXIUTJx+524JRJvfgha7a1jc5P83do4mncyVbdmM9R4lvGDUBx/7qZSFi togld+nJaYmos7MAuUNo6On4y727Y9DS7lxE8Dg8oslXVKTb6yKFzwCfIT5v u1FeB9uJXQUuFN7TS1kwqRvzQ3z0AvF99GynA56g19eK/6wa9orUF5I/Rde4 c7GHHbgryn++dTSkxjw25vH/1Yn8tDmR35zIb07kNyfymxP5zYn85kR+cyK/ OZHfnMhvTuQ3J/KbE/nNifzmRH5zIr85kd+cyG9O5Dcn8psT+c2J/OZEfnMi vzmR35zIb07kNyfymxP5zYn85kR+cyK/OZHfnMhvTuQ3J/KbE/nNifzmRH5z Ir85kd+cyG9O5Dcn8psT+c2J/OZEfnMivzmR35zI/6U9kQ9HRucgfX8atQJr ziIJHhD0yMH8JA4eDOMu8nvCeBQpCmbu3HQS3I/WLnGq23O7CxBUMu5w8x3G N7ifz4ceNQy0Qp73mK8tDKde3Jd1SpEjDCMLGK3FHrviinjYmXFrUKLQW0kl AaVMJmynoTyjYKcdWO+0QQJkI9khDL7RH6yFtOXoeMcdL2RrxQe3hPg+Zzw4 uLHqw+BhPZ9NumN3+vsq+V89xD1bzx/2qf93/j6wz4f4z3up+fmNJ/n8+xo+ XzY83veOz4d/iu+PLP9L9vl1fL6ueB8NkY3Pl39seb9t37xj+resLPC+Bhg/ H/71e+r9nflPf/qfivf1vwVp3nn/x0bnI/vm38f2TLz/AB7vFP+W4fym5fEe 806N941vAvRNu0OceL+2g3dkPHwl+OBXPw8Cfg6+scOfq/dFjZejrfzoPdtP 8F7u4L0F3tufgXdTj0eOtvLz4U928L5q339oeB8FH/7ueRDwEzzl70vWV18x PLSBn+Afd+r7ktEsjd6vBB8+wxc/H7x9Qo/0Z3W9v4d8foJ/fw9/6xrve+CN H5+3294/2cG7Bd7tz8D7M4MTD23i51s/fk+9fyV95/++90eW9U0bUyd/f7Mj uxxG4H30T++Rv7/becbfp181uXraL//wBO8Ayb9/D71/3sc7/9cgSCfvofcv +/z9eWy6+ZTeT/bx/gL8fXD4Hrx/28f7y+MgeHz3FK/Z/1fv/wuav+av+ful /fsv1aksegC+CQA= --416219727-687689762-900380434=:21534--

Ross, I have emailed radius and other source code before and no one had problems. In any case I plan not to do that in the future. If the users had done a search for vsa or for radius on http://interproc.ae.usr.com/tkb.html - they could have got the ftp link and could have downloaded it from there. This code is based on livingston 1.16 it is not 2.x based. Livingston 2.x is actually a product that you have to buy from Livingston/Lucent - so even if I had the code and did modifications I will not be able to distribute it. krish \ T.S.V. Krishnan \ \ Network System Engineer \ ( : - : ) \ 3Com ............ \ ----------------------------------------------/ tkrishna@bubba.ae.usr.com ----------------------------/ http://interproc.ae.usr.com ----/ The Yadda Yadda Search - for simple anwers - http://interproc.ae.usr.com/tkb.html Any Sufficiently advanced bug is indistinguishable for a feature. - Rick Kulawiec On Tue, 14 Jul 1998, Ross Becker wrote: > Tatai SV Krishnan wrote: > > > > Here you go, the source with modifications > > > > krish > > Tatai- please do not e-mail whole binaries to the > whole list; it's bad form. BTW- this appears to be a > hacked livingston 1.16; if that is correct, then > there is a significant CERT advisory related to all > RADIUS servers derived from livingston 1.16. I would > not run any RADIUS derived directly from 1.16. I believe > that the 2.x livingston RADIUS had fixes. The original > poster mentioning he had hacked the merit server- I would > be much more interested in seeing that. > > --Ross > beckerr@softrends.com > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

On Tue, 14 Jul 1998, Stefanita Valcu wrote: > On Mon, 13 Jul 1998, Tatai SV Krishnan wrote: > > > Here you go, the source with modifications > > > > krish > > Is your server handling the Reboot-Free-Request and Resource-Query-Request > ? This is plain old radius code based on 1.1.6 - it will just ignore version 2 messages but will not crash. krish > > vsv > --- > Stefanita Valcu > Network Administrator, Dynamic Network Technologies > Calea Victoriei 155, bl.D1, sc.7, et.3, sector 1, 71102, Bucuresti, Romania > tel: +40-1-6590696, fax: +40-1-3122745, E-mail: vsv@dnt.ro >

> List - > Has anyone used the Quad modem in sync mode? > I am evaluating modem chassis models, and 3com/USR website says it can be > done. If not I chose some other chassis. My needs are V.32 sync (Bisync > protocol) at 9600/ optionally 19200. > TIA

Tatai SV Krishnan wrote: > > Here you go, the source with modifications > > krish Tatai- please do not e-mail whole binaries to the whole list; it's bad form. BTW- this appears to be a hacked livingston 1.16; if that is correct, then there is a significant CERT advisory related to all RADIUS servers derived from livingston 1.16. I would not run any RADIUS derived directly from 1.16. I believe that the 2.x livingston RADIUS had fixes. The original poster mentioning he had hacked the merit server- I would be much more interested in seeing that. --Ross beckerr@softrends.com

O.k.. I give up. What is the CORRECT way to bring HDM trunks that have been put into the soft-busy state back to an active (IE: they answer) state? Restore would be my logical guess, but..no go. thanks, Randy Cosby <dcosby@infowest.com> Vice President InfoWest Global Internet Services, Inc. (435)674-0165 http://www.infowest.com

This is a Telco issue, you need to have both PRI circuits in a hunt group, so one will roll over into the next. -Frank -----Original Message----- > >Perhaps someone here can help. > >I've got a 2861 bundle: > >(1) NMC >(1) Hiper Arc >(2) DSPs > >I've got (2) PRI lines, one for each DSP. > >When my first DSP card reaches 100% utilization, my customers start to get >a busy signal. Aparrently it never switches over to the second DSP card to >handle the remaining customers. > >How do I configure the chassis and/or cards so that when the first DSP is >completely full (100% utilitzation) the second DSP card starts answering >the calls coming in? > >I appreciate your help on this. > >Sincerely, Alan D. Criado > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Perhaps someone here can help. I've got a 2861 bundle: (1) NMC (1) Hiper Arc (2) DSPs I've got (2) PRI lines, one for each DSP. When my first DSP card reaches 100% utilization, my customers start to get a busy signal. Aparrently it never switches over to the second DSP card to handle the remaining customers. How do I configure the chassis and/or cards so that when the first DSP is completely full (100% utilitzation) the second DSP card starts answering the calls coming in? I appreciate your help on this. Sincerely, Alan D. Criado

At 08:35 PM 7/14/98 -0400, Alan D. Criado wrote: > >Perhaps someone here can help. > >I've got a 2861 bundle: > >(1) NMC >(1) Hiper Arc >(2) DSPs > >I've got (2) PRI lines, one for each DSP. > >When my first DSP card reaches 100% utilization, my customers start to get >a busy signal. Aparrently it never switches over to the second DSP card to >handle the remaining customers. > >How do I configure the chassis and/or cards so that when the first DSP is >completely full (100% utilitzation) the second DSP card starts answering >the calls coming in? Sounds like your telco screwed up and don't have the first line rolling over to the second. Kirk Kirk Mitchell-General Manager mitch@keyconn.net Keystone Connect http://www.keyconn.net ***** Providing quality internet services in central PA ***** ******* (814)941-5000 We unlock the world ********

Thanks Frank. I'll get in touch with my telco right away. Alan At 05:49 PM 7/14/98 -0700, Frank Basso wrote: >This is a Telco issue, you need to have both PRI circuits in a hunt group, >so one will roll over into the next. > >-Frank >-----Original Message----- >From: Alan D. Criado <ACriado@elink.net> >To: usr-tc@lists.xmission.com <usr-tc@lists.xmission.com> >Date: Tuesday, July 14, 1998 5:41 PM >Subject: (usr-tc) Multiple Hiper DSPs > > >> >>Perhaps someone here can help. >> >>I've got a 2861 bundle: >> >>(1) NMC >>(1) Hiper Arc >>(2) DSPs >> >>I've got (2) PRI lines, one for each DSP. >> >>When my first DSP card reaches 100% utilization, my customers start to get >>a busy signal. Aparrently it never switches over to the second DSP card to >>handle the remaining customers. >> >>How do I configure the chassis and/or cards so that when the first DSP is >>completely full (100% utilitzation) the second DSP card starts answering >>the calls coming in? >> >>I appreciate your help on this. >> >>Sincerely, Alan D. Criado >> >> >>- >> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" >> with "unsubscribe usr-tc" in the body of the message. >> For information on digests or retrieving files and old messages send >> "help" to the same address. Do not use quotes in your message. >> > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. ---490656668-1473546909-900446541=:30469 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: <Pine.LNX.3.96.980714230107.30469C@rebel.dnt.ro> On Mon, 13 Jul 1998, Tatai SV Krishnan wrote: > Here you go, the source with modifications > > krish Is your server handling the Reboot-Free-Request and Resource-Query-Request ? vsv --- Stefanita Valcu Network Administrator, Dynamic Network Technologies Calea Victoriei 155, bl.D1, sc.7, et.3, sector 1, 71102, Bucuresti, Romania tel: +40-1-6590696, fax: +40-1-3122745, E-mail: vsv@dnt.ro ---490656668-1473546909-900446541=:30469--

ever since i put this v.90 code on my chassis, I haven't been able to get 128K. I called Solunet techsupport today and they were very helpful but after tweaking the heck out of the modem still no 128K ISDN. I think that the ISDN calles are answered directly by the netserver so i don't know what to look for on the netserver. can anyone help? Leon

-> Thanks Frank. -> -> I'll get in touch with my telco right away. If they were ordered that way then make sure you do an "In Service" command to the HiPerDSP. Jeff Binkley ASA Network Computing

Has anyone experienced any connection issues with Zyxels and the Total Control Netserver? We are unable to connect to I2 with the Zyxels however all other routers are able to connect to this port. Total Services answer was our I2 port was bad and that we needed to replace the board, however we can not afford the down time. Any other suggestions or other known issues with the Zyxel's? Joe Kvidera, MCP Solutions Group Corporation mailto:joe.kvidera@solutionsgroup.net http://www.solutionsgroup.net Ph: (612) 929-3670

Hi Jeff. Yes, they are configured to hunt. I opened a ticket report with the Telco last night. At first they too were unable to get it to hunt from the first PRI to the second PRI, it was ringing busy instead of switching over. Then they busied out each channel in the second Hiper DSP's PRI and put them back in service. Right after taking them off the busy state the hunting started to work. Wierd. Just out of curiosity; how do you issue that "In Service" command you mentioned below? Thank you. Alan At 11:41 PM 7/14/98 -0500, Jeff Binkley wrote: >-> Thanks Frank. >-> >-> I'll get in touch with my telco right away. > >If they were ordered that way then make sure you do an "In Service" >command to the HiPerDSP. > >Jeff Binkley >ASA Network Computing

At 04:10 PM 6/15/98 -0400, you wrote: >We just got our second pri installed and the phone company, ICG, is telling >us that they "could not loop up to the CSU." They said when they take the >loopback down, the get a clear signal, but cannot loop up to the CSU, and >told us to contact our phone vendor. Now the primary PRI works just fine. >When we have 23 calls into the hub, we get a all circuits are busy error. >The second PRI is configured identical to the primary. Is there something >that I am missing, or do we have a bad card? Make sure that span is configured to "respond to remote loopback" If it's not, the Telco won't be able to loop the USR. Also, make sure your D-channel is up, and span and all B channels are in-service. If all that is correct and the telco tells you that it's been turned up, the second PRI is probably not in hunt. -- J.S. Nakamura -- Phone (812)337-5070 x213 -- Kiva Networking -- Fax (812)337-5082 -- Network Engineer -- email jnakamur@kiva.net -- Cisco Certified Design Associate --

Telnet into the hub and do a LIST CHASSIS. Make sure that the owner of the card is YES. Jay Nakamura wrote: > > At 04:10 PM 6/15/98 -0400, you wrote: > >We just got our second pri installed and the phone company, ICG, is telling > >us that they "could not loop up to the CSU." They said when they take the > >loopback down, the get a clear signal, but cannot loop up to the CSU, and > >told us to contact our phone vendor. Now the primary PRI works just fine. > >When we have 23 calls into the hub, we get a all circuits are busy error. > >The second PRI is configured identical to the primary. Is there something > >that I am missing, or do we have a bad card? -- ======================================================= =========== Andrew Aken - President ========= ====== GlobalEyes Communications, Inc. ====== =Southern Illinois' Fastest Connection to the Internet= ========== http://www.GlobalEyes.net ======== =======================================================

On 15 Jul 98, at 8:44, Joe Kvidera <usr-tc@lists.xmission.com> wrote: > Has anyone experienced any connection issues with Zyxels and the Total > Control Netserver? We are unable to connect to I2 with the Zyxels > however all other routers are able to connect to this port. Total > Services answer was our I2 port was bad and that we needed to replace > the board, however we can not afford the down time. Any other > suggestions or other known issues with the Zyxel's? Contact Zyxel, they might have newer flash for your Prestige. Solved problems for me. ---------------------------------------------------------------------- Andres Kroonmaa mail: andre@online.ee Network Manager Organization: MicroLink Online Tel: 6308 909 Tallinn, Sakala 19 Pho: +372 6308 909 Estonia, EE0001 http://www.online.ee Fax: +372 6308 901 ----------------------------------------------------------------------

Greetings, We had some trouble for a while with the 1st modem of some HiPerDSP cards staying in the down - up state when I did a list conn on the associated ARC. We finally solved this problem by making a mistake (!). I had to reset the configuration of several DSP's and forgot to put the modems into Round-Robin. So they stayed in "Fixed Assignment" and, POOF, the problem went away, my MRTG graphs showed that all my modems went up when I reset all the modems with the new config !!! Is this a known fix for this bug ? Regards, Robert von Bismarck PS : I had the telco set my hunt group to cyclic, so that the modems get picked up in a simili-roundrobin fashion, so as to equalize the load on all the ports...

> > >We just got our second pri installed and the phone company, ICG, is >telling >us that they "could not loop up to the CSU." They said when they take >the >loopback down, the get a clear signal, but cannot loop up to the CSU, >and >told us to contact our phone vendor. Now the primary PRI works just >fine. >When we have 23 calls into the hub, we get a all circuits are busy >error. >The second PRI is configured identical to the primary. Is there >something >that I am missing, or do we have a bad card? Make sure that the Hyper DSP trunk settings doesn't ignore a DSX loop >command. I think it ignores the loop up command by default.

Hi can I block Collect Calls in the HDSP? - Marcelo

Thus spake Marcelo Souza > Hi can I block Collect Calls in the HDSP? Uhm...perhaps I'm a bit confused, but how are you going to have a collect call go through to a modem? Doesn't that require the operator to, like, actually talk to someone before the call goes through? To answer your question, I doubt there is a way to do so within the system itself, I don't know of anything that distinguishes a Collect Call from any other. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

At 07:38 PM 7/15/98 -0400, Jeff Mcadams wrote... >Thus spake Marcelo Souza >> Hi can I block Collect Calls in the HDSP? > >Uhm...perhaps I'm a bit confused, but how are you going to have a >collect call go through to a modem? Doesn't that require the operator >to, like, actually talk to someone before the call goes through? > >To answer your question, I doubt there is a way to do so within the >system itself, I don't know of anything that distinguishes a Collect >Call from any other. Sorry to jump in, but since we're speaking about Brazil, this question seem to be related to R2 signaling (we've a "almost" blue-book R2 digital standard here). In R2, the CO switch would send a II-8 signal in a "collect call" case, so the RAS box can "refuse" the call. Not sure in T1 how it is done, but I think there is a similar "message" (in our case, is in a "out-of-band" channel, 16, not 'in each channel' like seem to be the case in T1, but more like ISDN). Marcelo, the bad news to you is that some CO here in Brazil don't send the II-8 signal at all :-( [], <O-O> Julio Arruda Bay Networks - Where Information Flows

First things first -- in case nobody else noticed, v.90 is out for the HDM's at long last.. :) Anyway, I noticed something disturbing earlier today on the one ARC I have in service. We're using the "Port-Limit" attribute in Radius (Livingston 2.01 w/ some of Krish's VSA stuff shoehorned in) to limit ISDN callers from starting Multilink sessions. There's multiple "DEFAULT" entries keyed to Unix groups, so that the limit is set to 2 for people in the fastisdn group, and set to 1 for everyone else. I caught someone running a multilink session today on our ARC (4.0.29) that was not authorized for it. Oops. Our NETservers (3.7.24) do correctly stop people from doing this. The v.90 ARC+HDM release that came out today has a new build of ARC code -- 4.0.30. Any of you 3com people know if this is fixed in it? It's too early for me to tell since I've only had the code on there a few hours, but I thought everyone deserved a heads-up about it in case their users were trying to do something stupid, or in case *I* did something stupid in my config. ;-) If I do run into it again I'll let y'all know. Mike Andrews (MA12) icq 6602506 -------------- mandrews@dcr.net Senior Systems/Network Administrator --- mandrews@termfrost.org Digital Crescent, Frankfort, KY ----- http://www.termfrost.org/ "Eagles may soar, but weasels don't get sucked into jet engines." -----BEGIN GEEK CODE BLOCK----- Version: 3.1 GCS/MU d- s: a- C++ UBX++++ P++ L+ !E W+++ N++ K++ w--- O+ M+ V+++ PS+++ PE- Y+ !t !5 !X !R tv- b+ DI++ D++ e++ h++ r++ y++*@ -----END GEEK CODE BLOCK-----

On a hiper chassis with (10) v1.0.8 DSPs and (2) v4.0.29 ARCs, upgrading the NMC to v5.5.5 caused 1/2 of the DSPs (slots 1,2,5,9,10) to drop their callers ( or reboot, not sure yet ). Is this a known issue or just me? Marshall Morgan Internet Doorway, Inc. (aka NETDOOR) http://www.netdoor.com 601.969.1434 Ext. #28 | Fax 601.969.3838 | 800.952.1570 Ext. #28

Thus spake Mike Andrews >We're using the "Port-Limit" attribute in Radius (Livingston 2.01 w/ some >of Krish's VSA stuff shoehorned in) to limit ISDN callers from starting >Multilink sessions. There's multiple "DEFAULT" entries keyed to Unix >groups, so that the limit is set to 2 for people in the fastisdn group, >and set to 1 for everyone else. Port-Limit (at least on the netservers, not sure about the HDM's) won't stop people from using Multilink PPP, it *will* stop them from using more than one channel, but they can quite happily use MP on a single channel and everything work just hunky dory. You probably don't want to stop MultiLink from happening as more and more systems are defaulting to using MP and so you'll get more and more tech support calls on why someone isn't able to connect and you'll have to talk them through turning off MP in their stack. Better, IMHO, to let them use MP, but just limit them to one channel in the bundle, which is exactly what Port-Limit does. >Our NETservers (3.7.24) do correctly stop people from doing this. You might want to double check this, because I suspect they behave the same way. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

How can I tell what firmware ver the modems in my netserver 16 are currently running? If I telnet in to one of them, is there a command to check this? Thanks, Greg Coffey CoffeyNet 307-234-5443 142 S. Center St. www.coffey.com Casper, WY 82601

>-----Original Message----- >From: owner-usr-tc@lists.xmission.com >[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Mike Andrews >Sent: Wednesday, July 15, 1998 11:27 PM >To: usr-tc@lists.xmission.com >Subject: (usr-tc) ARC multilink PPP glitch > >We're using the "Port-Limit" attribute in Radius (Livingston 2.01 w/ some >of Krish's VSA stuff shoehorned in) to limit ISDN callers from starting >Multilink sessions. There's multiple "DEFAULT" entries keyed to Unix >groups, so that the limit is set to 2 for people in the fastisdn group, >and set to 1 for everyone else. > >I caught someone running a multilink session today on our ARC (4.0.29) >that was not authorized for it. Oops. > >Our NETservers (3.7.24) do correctly stop people from doing this. > It would seem that in your configs that the majority of your users should not be allowed MLPPP. If this is the case, I would remove the Port-Limit entry in that "DEFAULT" RADIUS entry and leave it in the fastisdn one.. You can then set the same setting on the DEFAULT user on your HARC. "set user default port-limit 1". The default user setting will keep the limit to 1 channel and only be overridden by the RADIUS attribute if present. I will also look into the problem that you reported above. -m

On Thu, 16 Jul 1998, Jeff Mcadams wrote: > Thus spake Mike Andrews > >We're using the "Port-Limit" attribute in Radius (Livingston 2.01 w/ some > >of Krish's VSA stuff shoehorned in) to limit ISDN callers from starting > >Multilink sessions. There's multiple "DEFAULT" entries keyed to Unix > >groups, so that the limit is set to 2 for people in the fastisdn group, > >and set to 1 for everyone else. > > Port-Limit (at least on the netservers, not sure about the HDM's) won't > stop people from using Multilink PPP, it *will* stop them from using > more than one channel, but they can quite happily use MP on a single > channel and everything work just hunky dory. OK... I wasn't very clear here. ;-) It's dual-channel that I'm worried about. Single-channel MLPPP is fine with me. Several people are doing that with no problems. So I think we're both still talking about the same thing. The problem was the ARC allowed a dual-channel call for someone that it wasn't supposed to. The NETserver syslogs the usual "max link count reached on this bundle" message. The ARC lets 'em do it anyway. Two sessions, same IP address, same session start time, both ANI numbers point at his ISDN line... Mike Andrews (MA12) icq 6602506 -------------- mandrews@dcr.net Senior Systems/Network Administrator --- mandrews@termfrost.org Digital Crescent, Frankfort, KY ----- http://www.termfrost.org/ "Eagles may soar, but weasels don't get sucked into jet engines." -----BEGIN GEEK CODE BLOCK----- Version: 3.1 GCS/MU d- s: a- C++ UBX++++ P++ L+ !E W+++ N++ K++ w--- O+ M+ V+++ PS+++ PE- Y+ !t !5 !X !R tv- b+ DI++ D++ e++ h++ r++ y++*@ -----END GEEK CODE BLOCK-----

Thus spake Mike Andrews >OK... I wasn't very clear here. ;-) It's dual-channel that I'm worried >about. Single-channel MLPPP is fine with me. Several people are doing >that with no problems. So I think we're both still talking about the same >thing. Ok, sounds like it. :) >The problem was the ARC allowed a dual-channel call for someone that it >wasn't supposed to. The NETserver syslogs the usual "max link count >reached on this bundle" message. The ARC lets 'em do it anyway. Two >sessions, same IP address, same session start time, both ANI numbers point >at his ISDN line... Uhm...this sounds like he's running two seperate bundles from what you're saying here...depending on how you interpret Port-Limit, this could be the correct behavior. If you interpret Port-Limit as purely just the max number of channels *within an MP bundle*, then the ARC is doing the right thing, and the Netserver isn't. If you're using Port-Limit as just the max number of ports that a specific userid can have on a specific NAS, then the Netserver is right and the ARC is wrong. Personally, it makes more sense to me to use the first definition, as the second definition doesn't seem to add anything to it since if these two channels just hit different chassis, then there's no way for the netserver to deny that. Personally, I like my hunt group to look like one big dial-in system as far as customers are concerned, and this would break that appearance. The flip-side of that, is the actual name of the attribute "Port-Limit" would seem to imply the Netservers behavior, since it makes no mention of channel limit, or bundle limit or anything like that which would seem to apply to MP more. Anyway...now that I've probably confused everyone about what I think, I think I'll just leave it at that. :) -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Man, I thought I'd see the millenium before I saw V.90 code for HiPers, but apparently 3.1.2 is on the TotalService site NOW!

Thus spake Marcelo Souza > Does any one here has users trying to use this feature that came >with Diamond Supra Sonic II modems? > It intend to use two common telephone lines (not ISDN) to make >connections up to 112k (2x 56k) using multilink PPP. > How can set up my TCs (I have both ARC and Netserver) to enable >that ? Same way you would with ISDN...MLPPP is MLPPP, it doesn't care if the connection is an ISDN line, or a 56k modem, just set their Port-Limit to 2 and away they go. They may not even need the ShotGun program to do it as win98 and win nt will both do MLPPP natively. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

For a moment there I thought I was going to read about a user so fed up with Multilink PPP and their usr-tc chasis that they had to resort to using a shotgun :) If you're using radius, set Port-Limit to 2 and you should be all set. - lv On Thu, 16 Jul 1998, Marcelo Souza wrote: > > > Does any one here has users trying to use this feature that came > with Diamond Supra Sonic II modems? > It intend to use two common telephone lines (not ISDN) to make > connections up to 112k (2x 56k) using multilink PPP. > How can set up my TCs (I have both ARC and Netserver) to enable > that ? > > > TIA > > > - Marcelo > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Does any one here has users trying to use this feature that came with Diamond Supra Sonic II modems? It intend to use two common telephone lines (not ISDN) to make connections up to 112k (2x 56k) using multilink PPP. How can set up my TCs (I have both ARC and Netserver) to enable that ? TIA - Marcelo

My customer is trying to connect to my netserver 16i plus using a 3com office connect isdn lan modem (3c892). Does anyone have any suggestions what I can do on my side or on his side? Thanks

We have channelized T-1s (ESF b8zs) coming into our usr-tcs. We're trying to bring a new chassis online, but we have a problem. When we plug in one of the T-1 spans, the first call comes in fine, modem answers and user gets authenticated. But after the first one, the box stops answering. No other modem picks up. I'm 99% sure that the new box is configured the same as our others. Anyone have any idea what I missed? Thanks! John John Powell, President john@jetcity.com Jet City Online http://www.jetcity.com Business Office: 206-281-1774 Customer Service: 425-820-7006, 1-888-747-6464

At 03:30 PM 7/16/98 -0500, you wrote: >> We have channelized T-1s (ESF b8zs) coming into our usr-tcs. We're trying >> to bring a new chassis online, but we have a problem. When we plug in one >> of the T-1 spans, the first call comes in fine, modem answers and user gets >> authenticated. But after the first one, the box stops answering. No other >> modem picks up. I'm 99% sure that the new box is configured the same as our >> others. Anyone have any idea what I missed? > >I've seen this before when you first turn on a chassis - for some reason, >the telco doesn't release all the trunks. While it is turned on, try >unplugging the T1, leaving it out for 15-30 seconds, and plug it back in. >Sometimes that shocks the switch into re-evaluating what is going on, and >releases the trunks. Alternatively, call the telco and have them take a >look at the trunks to make sure they are all released, and not in a >maintenance mode. I was using a 'live' T-1 from our regular hunt group, moving it from one of the old chassis to the new one. When I move it back again to the old chassis, it works fine. So I don't think its a telco issue. I'll try plugging a T-1 into the new chassis, reseat the T-1, and let you know. John John Powell, President john@jetcity.com Jet City Online http://www.jetcity.com Business Office: 206-281-1774 Customer Service: 425-820-7006, 1-888-747-6464

On Thu, 16 Jul 1998, Pete Ashdown wrote: > Man, I thought I'd see the millenium before I saw V.90 code for HiPers, but > apparently 3.1.2 is on the TotalService site NOW! > Dont get to excited. As Im trying to verify this with someone at USR the V90 code it works ONLY with the HiPer ARC: Hiper DSP - T1 & T1/PRI (Includes v.90. For use with HiPer ARC only) - TCS 3.1.2 Which is BS if you ask me. Does anyone know IF and WHEN they will have a version out?

At 03:30 PM 7/16/98 -0500, you wrote: >> We have channelized T-1s (ESF b8zs) coming into our usr-tcs. We're trying >> to bring a new chassis online, but we have a problem. When we plug in one >> of the T-1 spans, the first call comes in fine, modem answers and user gets >> authenticated. But after the first one, the box stops answering. No other >> modem picks up. I'm 99% sure that the new box is configured the same as our >> others. Anyone have any idea what I missed? > >I've seen this before when you first turn on a chassis - for some reason, >the telco doesn't release all the trunks. While it is turned on, try >unplugging the T1, leaving it out for 15-30 seconds, and plug it back in. >Sometimes that shocks the switch into re-evaluating what is going on, and >releases the trunks. Alternatively, call the telco and have them take a >look at the trunks to make sure they are all released, and not in a >maintenance mode. I was using a 'live' T-1 from our regular hunt group, moving it from one of the old chassis to the new one. When I move it back again to the old chassis, it works fine. So I don't think its a telco issue. I'll try plugging a T-1 into the new chassis, reseat the T-1, and let you know. LATER: Nope, same behavior. But I will make one amends to my original statement of the problem. Modems on the first card answer, but not the other modems. John John John Powell, President john@jetcity.com Jet City Online http://www.jetcity.com Business Office: 206-281-1774 Customer Service: 425-820-7006, 1-888-747-6464

THIS IS TRUE, THE V.90 CODE FOR THE DSPs ONLY WORK WITH THE HIPER ARC. ____________________Reply Separator____________________ Author: <usr-tc@lists.xmission.com > On Thu, 16 Jul 1998, Pete Ashdown wrote: > Man, I thought I'd see the millenium before I saw V.90 code for HiPers, but > apparently 3.1.2 is on the TotalService site NOW! > Dont get to excited. As Im trying to verify this with someone at USR the V90 code it works ONLY with the HiPer ARC: Hiper DSP - T1 & T1/PRI (Includes v.90. For use with HiPer ARC only) - TCS 3.1.2 Which is BS if you ask me. Does anyone know IF and WHEN they will have a version out? - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

>-----Original Message----- >From: owner-usr-tc@lists.xmission.com >[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Greg Coffey >Sent: Thursday, July 16, 1998 10:37 AM >To: usr-tc@lists.xmission.com >Subject: (usr-tc) Netserver16 > > >How can I tell what firmware ver the modems in my netserver 16 are >currently running? If I telnet in to one of them, is there a command to >check this? > >Thanks, >Greg Coffey CoffeyNet 307-234-5443 >142 S. Center St. www.coffey.com >Casper, WY 82601 > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > "set switched interface mod:1 at_command ati7"

At 03:58 PM 7/16/98 -0500, you wrote: >> Nope, same behavior. But I will make one amends to my original statement of >> the problem. Modems on the first card answer, but not the other modems. > >Have you taken a look at the DS0 --> modem assignment? You can do it at >the console of the T1 card, or via TCM. Checked that, looks alright to me: S1:DS1-1.1 S2:MDM-1 S1:DS1-1.2 S2:MDM-2 S1:DS1-1.3 S2:MDM-3 S1:DS1-1.4 S2:MDM-4 S1:DS1-1.5 S3:MDM-1 S1:DS1-1.6 S3:MDM-2 S1:DS1-1.7 S3:MDM-3 S1:DS1-1.8 S3:MDM-4 S1:DS1-1.9 S4:MDM-1 S1:DS1-1.10 S4:MDM-2 S1:DS1-1.11 S4:MDM-3 S1:DS1-1.12 S4:MDM-4 S1:DS1-1.13 S5:MDM-1 S1:DS1-1.14 S5:MDM-2 S1:DS1-1.15 S5:MDM-3 S1:DS1-1.16 S5:MDM-4 S1:DS1-1.17 S6:MDM-1 S1:DS1-1.18 S6:MDM-2 S1:DS1-1.19 S6:MDM-3 S1:DS1-1.20 S6:MDM-4 S1:DS1-1.21 S7:MDM-1 S1:DS1-1.22 S7:MDM-2 S1:DS1-1.23 S7:MDM-3 S1:DS1-1.24 S7:MDM-4 S1:DS1-2.1 S8:MDM-1 S1:DS1-2.2 S8:MDM-2 S1:DS1-2.3 S8:MDM-3 S1:DS1-2.4 S8:MDM-4 S1:DS1-2.5 S9:MDM-1 S1:DS1-2.6 S9:MDM-2 S1:DS1-2.7 S9:MDM-3 S1:DS1-2.8 S9:MDM-4 S1:DS1-2.9 S10:MDM-1 S1:DS1-2.10 S10:MDM-2 S1:DS1-2.11 S10:MDM-3 S1:DS1-2.12 S10:MDM-4 S1:DS1-2.13 S11:MDM-1 S1:DS1-2.14 S11:MDM-2 S1:DS1-2.15 S11:MDM-3 S1:DS1-2.16 S11:MDM-4 S1:DS1-2.17 S12:MDM-1 S1:DS1-2.18 S12:MDM-2 S1:DS1-2.19 S12:MDM-3 S1:DS1-2.20 S12:MDM-4 S1:DS1-2.21 S13:MDM-1 S1:DS1-2.22 S13:MDM-2 S1:DS1-2.23 S13:MDM-3 S1:DS1-2.24 S13:MDM-4 John John Powell, President john@jetcity.com Jet City Online http://www.jetcity.com Business Office: 206-281-1774 Customer Service: 425-820-7006, 1-888-747-6464

At 04:59 PM 7/16/98 -0400, you wrote: >John Powell <john@jetcity.com> writes: > >> Nope, same behavior. But I will make one amends to my original statement of >> the problem. Modems on the first card answer, but not the other modems. > >What's the status of the modems as viewed from the CT1 card? If they >show up as unavailable, you may want to verify that all the modems >have their line source set to the "t1Tdm" bus rather than the "priTdm" >setting. They are all set the "t1Tdm". John John Powell, President john@jetcity.com Jet City Online http://www.jetcity.com Business Office: 206-281-1774 Customer Service: 425-820-7006, 1-888-747-6464

Using TCM how do you look to see if the modems are "available" according to the T-1 card? John At 05:37 PM 7/16/98 -0400, you wrote: >John Powell <john@jetcity.com> writes: > >> They are all set the "t1Tdm". > >And are they available from the CT1 card perspective? If the line >source had to be changed, it will take a reset to actually make the >setting change. > >If the CT1 card indicates that the modems are in an "available" state, >then I guess the next question is if the calls are even hitting your >equipment. If you have something that can receive SNMP traps, I would >suggest enabling the CT1 traps for DS0 level call arrival and error >events, which if a call is actually arriving, should then give you a >failure to terminate the call successfully on a modem with a reason >code that you can look up in the MIB. > >-- David > >/-----------------------------------------------------------------------\ > \ David Bolen \ Internet: db3l@ans.net / > | ANS Communications, Inc. \ Phone: (914) 701-5327 | > / 100 Manhattanville Rd, Purchase, NY 10577 \ Fax: (914) 701-5310 \ >\-----------------------------------------------------------------------/ > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > John Powell, President john@jetcity.com Jet City Online http://www.jetcity.com Business Office: 206-281-1774 Customer Service: 425-820-7006, 1-888-747-6464

At 05:51 PM 7/16/98 -0400, you wrote: >John Powell <john@jetcity.com> writes: > >> Using TCM how do you look to see if the modems are "available" according to >> the T-1 card? > >Hmm - someone else may have to answer definitively since I don't use >TCM. > >But if you have access to the console, you can use status (main menu >option 1) options 3 and 5 to see DS0/Modem status. From the T-1 console it looks fine: T1 Span Line 1 DS0/Modem Status DS0 DS0 Modem Slot/ DS0 DS0 Modem SLOT/ Status Status Chan Status Status chan 1 CONNECT-IN CONNECT-IN 2\1 13 IDLE IDLE 5\1 2 IDLE IDLE 2\2 14 IDLE IDLE 5\2 3 IDLE IDLE 2\3 15 IDLE IDLE 5\3 4 IDLE IDLE 2\4 16 IDLE IDLE 5\4 5 IDLE IDLE 3\1 17 IDLE IDLE 6\1 6 IDLE IDLE 3\2 18 IDLE IDLE 6\2 7 IDLE IDLE 3\3 19 IDLE IDLE 6\3 8 IDLE IDLE 3\4 20 IDLE IDLE 6\4 9 IDLE IDLE 4\1 21 IDLE IDLE 7\1 10 IDLE IDLE 4\2 22 IDLE IDLE 7\2 11 IDLE IDLE 4\3 23 IDLE IDLE 7\3 12 IDLE IDLE 4\4 24 IDLE IDLE 7\4 > >If you've got a MIB browser or SNMP utility, you can dump the >ds0StatModem object table. > >This information is in the same table as that which holds the current >DS0 status (e.g., busied out, in alarm, etc..) so based on my ancient >recollection of TCM, I'd presume that if you selected the DS0s for a >query, you should find the modem status object available for selection >at the same stage where you'd normally find the DS0 status object. > >-- David I'm stumped. I'm not SNMP savvy. I rely on command line and TCM. If no one else has any ideas, I guess I'm calling USR tech support tomorrow morning... John John Powell, President john@jetcity.com Jet City Online http://www.jetcity.com Business Office: 206-281-1774 Customer Service: 425-820-7006, 1-888-747-6464

> We have channelized T-1s (ESF b8zs) coming into our usr-tcs. We're trying > to bring a new chassis online, but we have a problem. When we plug in one > of the T-1 spans, the first call comes in fine, modem answers and user gets > authenticated. But after the first one, the box stops answering. No other > modem picks up. I'm 99% sure that the new box is configured the same as our > others. Anyone have any idea what I missed? I've seen this before when you first turn on a chassis - for some reason, the telco doesn't release all the trunks. While it is turned on, try unplugging the T1, leaving it out for 15-30 seconds, and plug it back in. Sometimes that shocks the switch into re-evaluating what is going on, and releases the trunks. Alternatively, call the telco and have them take a look at the trunks to make sure they are all released, and not in a maintenance mode. | Curtis V. Shambeau | curt@execpc.com | http://www.execpc.com/~curt | | Executive Vice President - Exec-PC, Inc. |

I'm getting confused now... Which multi-line thingy requires a "server" to sync everything up? What info does it provide/coordinate? Thanks, Charles On Thu, 16 Jul 1998, Jeff Mcadams wrote: > Date: Thu, 16 Jul 1998 12:11:15 -0400 (EDT) > From: Jeff Mcadams <jeffm@iglou.com> > Reply-To: usr-tc@lists.xmission.com > To: usr-tc@lists.xmission.com > Subject: Re: (usr-tc) Multilink PPP and ShotGun > > Thus spake Marcelo Souza > > Does any one here has users trying to use this feature that came > >with Diamond Supra Sonic II modems? > > It intend to use two common telephone lines (not ISDN) to make > >connections up to 112k (2x 56k) using multilink PPP. > > How can set up my TCs (I have both ARC and Netserver) to enable > >that ? > > Same way you would with ISDN...MLPPP is MLPPP, it doesn't care if the > connection is an ISDN line, or a 56k modem, just set their Port-Limit to > 2 and away they go. They may not even need the ShotGun program to do it > as win98 and win nt will both do MLPPP natively. > -- > Jeff McAdams Email: jeffm@iglou.com > Head Network Administrator Voice: (502) 966-3848 > IgLou Internet Services (800) 436-4456 > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > =-----------------= = | Charles Sprickman Internet Channel | | INCH System Administration Team (212)243-5200 | | spork@inch.com access@inch.com | = =----------------=

Thus spake Charles Sprickman >I'm getting confused now... Which multi-line thingy requires a "server" >to sync everything up? What info does it provide/coordinate? Well, if you're dialing in with MP(MLPPP, Multilink, etc.) to a hunt group of equipment, that equipment needs to be able to coordinate between them to "bond" those connections across chassis. USR/3Com's protocol for doing this is called MPIP. If you're only dialing into a single chassis, then you have no need for MPIP. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

> Nope, same behavior. But I will make one amends to my original statement of > the problem. Modems on the first card answer, but not the other modems. Have you taken a look at the DS0 --> modem assignment? You can do it at the console of the T1 card, or via TCM. | Curtis V. Shambeau | curt@execpc.com | http://www.execpc.com/~curt | | Executive Vice President - Exec-PC, Inc. |

> Well, if you're dialing in with MP(MLPPP, Multilink, etc.) to a hunt > group of equipment, that equipment needs to be able to coordinate > between them to "bond" those connections across chassis. USR/3Com's > protocol for doing this is called MPIP. If you're only dialing into a > single chassis, then you have no need for MPIP. Thanks... Are MP,MLPPP,Multilink, and friends all the same thing? Is there an easy way to run the MPIP server off something besides one of your Netservers? And lastly, how do other vendors handle this issue? Thanks again, Charles > -- > Jeff McAdams Email: jeffm@iglou.com > Head Network Administrator Voice: (502) 966-3848 > IgLou Internet Services (800) 436-4456 > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > =-----------------= = | Charles Sprickman Internet Channel | | INCH System Administration Team (212)243-5200 | | spork@inch.com access@inch.com | = =----------------=

Thus spake Charles Sprickman >Thanks... Are MP,MLPPP,Multilink, and friends all the same thing? Yup, all the same thing...if you feel like some really dry reading, you can check out RFC 1990 for the spec. >Is >there an easy way to run the MPIP server off something besides one of your >Netservers? 3Com has made available to a few people code that's written to compile on Solaris, but its really pitiful and its a real resource hog. Ricky Beam was working on cleaning it up...I haven't gotten any word from him in a while concerning it though... <hint> >And lastly, how do other vendors handle this issue? Other vendors have their own protocols, analogous to MPIP (Cisco calls theirs MMP I believe), so (of course) nothing interoperates in this respect. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

John Powell <john@jetcity.com> writes: > Nope, same behavior. But I will make one amends to my original statement of > the problem. Modems on the first card answer, but not the other modems. What's the status of the modems as viewed from the CT1 card? If they show up as unavailable, you may want to verify that all the modems have their line source set to the "t1Tdm" bus rather than the "priTdm" setting. -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | ANS Communications, Inc. \ Phone: (914) 701-5327 | / 100 Manhattanville Rd, Purchase, NY 10577 \ Fax: (914) 701-5310 \ \-----------------------------------------------------------------------/

John Powell <john@jetcity.com> writes: > They are all set the "t1Tdm". And are they available from the CT1 card perspective? If the line source had to be changed, it will take a reset to actually make the setting change. If the CT1 card indicates that the modems are in an "available" state, then I guess the next question is if the calls are even hitting your equipment. If you have something that can receive SNMP traps, I would suggest enabling the CT1 traps for DS0 level call arrival and error events, which if a call is actually arriving, should then give you a failure to terminate the call successfully on a modem with a reason code that you can look up in the MIB. -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | ANS Communications, Inc. \ Phone: (914) 701-5327 | / 100 Manhattanville Rd, Purchase, NY 10577 \ Fax: (914) 701-5310 \ \-----------------------------------------------------------------------/

John Powell <john@jetcity.com> writes: > Using TCM how do you look to see if the modems are "available" according to > the T-1 card? Hmm - someone else may have to answer definitively since I don't use TCM. But if you have access to the console, you can use status (main menu option 1) options 3 and 5 to see DS0/Modem status. If you've got a MIB browser or SNMP utility, you can dump the ds0StatModem object table. This information is in the same table as that which holds the current DS0 status (e.g., busied out, in alarm, etc..) so based on my ancient recollection of TCM, I'd presume that if you selected the DS0s for a query, you should find the modem status object available for selection at the same stage where you'd normally find the DS0 status object. -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | ANS Communications, Inc. \ Phone: (914) 701-5327 | / 100 Manhattanville Rd, Purchase, NY 10577 \ Fax: (914) 701-5310 \ \-----------------------------------------------------------------------/

Hello, Anyone know if you can do NFAS (2 PRI / 1 D) with two HiPerDSPs? If not, will this be supported in the future? -Jason --- Robert J. Adams radams@siscom.net http://www.siscom.net Looking to outsource news? http://www.newshosting.com SISCOM Network Administration - President, SISCOM Inc. Phone: 888-4-SISCOM 937-222-8150 FAX: 937-222-8153

Thus spake Robert Adams > Anyone know if you can do NFAS (2 PRI / 1 D) with two HiPerDSPs? If not, >will this be supported in the future? My understanding is that you cannot do this. Since the cards are independant entities within the chassis, it will be difficult to get them to cooperate to do NFAS. There's been no statement that I've seen from 3Com about possible support for this in the future, but I would hazard a guess that it would be unlikely, or at the very least, in the distant future. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Jeff, Seems like it would be possible, the PM3's are doing NFAS across different chassis.. lol -Jason --- Robert J. Adams radams@siscom.net http://www.siscom.net Looking to outsource news? http://www.newshosting.com SISCOM Network Administration - President, SISCOM Inc. Phone: 888-4-SISCOM 937-222-8150 FAX: 937-222-8153 -----Original Message----- Thus spake Robert Adams > Anyone know if you can do NFAS (2 PRI / 1 D) with two HiPerDSPs? If not, >will this be supported in the future? My understanding is that you cannot do this. Since the cards are independant entities within the chassis, it will be difficult to get them to cooperate to do NFAS. There's been no statement that I've seen from 3Com about possible support for this in the future, but I would hazard a guess that it would be unlikely, or at the very least, in the distant future. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456 - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

It is working fine other than it doesnt send a ppp start message when you do a set ppp session_start_message "PPP session begin from ...." Other than that I haven't had a problem yet. We'll see when it hits the production units tho. Eric T. Billeter Cable One Internet Engineer 1314 North 3rd Street ebilleter@cableone.net Phoenix, AZ 85004 -----Original Message----- [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Jason W Sent: Thursday, July 16, 1998 6:13 PM I have noticed this is out for HiPer DSP's and HiPer arc. I know that it currently does not work with the netserver :-( but has anyone tried this out, and how is it working? Thanks, =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Jason Watkins I-Land Support & NOC Tech jwatkins@iland.net http://www.iland.net =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

I have noticed this is out for HiPer DSP's and HiPer arc. I know that it currently does not work with the netserver :-( but has anyone tried this out, and how is it working? Thanks, =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Jason Watkins I-Land Support & NOC Tech jwatkins@iland.net http://www.iland.net =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

On Thu, 16 Jul 1998, Jason W wrote: > I have noticed this is out for HiPer DSP's and HiPer > arc. I know that it currently does not work with the > netserver :-( but has anyone tried this out, and how > is it working? It is not that the DSP does not work with the netserver. Our STG has not tested and certified this code with the netserver. However the beta code 3.8.x should work with the DSP code. krish > > Thanks, > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Jason Watkins I-Land Support & NOC Tech > jwatkins@iland.net http://www.iland.net > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Yes it is in beta. krish \ T.S.V. Krishnan \ \ Network System Engineer \ ( : - : ) \ 3Com ............ \ ----------------------------------------------/ tkrishna@bubba.ae.usr.com ----------------------------/ http://interproc.ae.usr.com ----/ The Yadda Yadda Search - for simple anwers - http://interproc.ae.usr.com/tkb.html Any Sufficiently advanced bug is indistinguishable for a feature. - Rick Kulawiec On Fri, 17 Jul 1998, Jamie Orzechowski wrote: > is there beta 3.8.X NETServer code??? > > -----Original Message----- > From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com> > To: Jason W <jwatkins@iland.net> > Cc: USRTC <usr-tc@lists.xmission.com> > Date: Friday, July 17, 1998 9:33 AM > Subject: Re: (usr-tc) New V.90 for HiPer > > > > > >On Thu, 16 Jul 1998, Jason W wrote: > > > >> I have noticed this is out for HiPer DSP's and HiPer > >> arc. I know that it currently does not work with the > >> netserver :-( but has anyone tried this out, and how > >> is it working? > > > >It is not that the DSP does not work with the netserver. Our STG has not > >tested and certified this code with the netserver. However the beta code > >3.8.x should work with the DSP code. > > > > > >krish > > > >> > >> Thanks, > >> > >> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > >> Jason Watkins I-Land Support & NOC Tech > >> jwatkins@iland.net http://www.iland.net > >> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > >> > >> > >> - > >> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > >> with "unsubscribe usr-tc" in the body of the message. > >> For information on digests or retrieving files and old messages send > >> "help" to the same address. Do not use quotes in your message. > >> > > > >- > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Set MP on - NETServer set net user default max_cha 2 - Hiper arc krish \ T.S.V. Krishnan \ \ Network System Engineer \ ( : - : ) \ 3Com ............ \ ----------------------------------------------/ tkrishna@bubba.ae.usr.com ----------------------------/ http://interproc.ae.usr.com ----/ The Yadda Yadda Search - for simple anwers - http://interproc.ae.usr.com/tkb.html Any Sufficiently advanced bug is indistinguishable for a feature. - Rick Kulawiec On Fri, 17 Jul 1998, Jason W wrote: > Ahhhh.... I see. Is there any documantation on how to config > this? I have hunted through my USRTC doc's and have come > up empty. I would need information on both Netservers and > HiPer Arc's. Thanks for the info. > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Jason Watkins I-Land Support & NOC Tech > jwatkins@iland.net http://www.iland.net > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > > -----Original Message----- > From: Jeff Mcadams <jeffm@iglou.com> > To: usr-tc@lists.xmission.com <usr-tc@lists.xmission.com> > Date: Friday, July 17, 1998 8:31 AM > Subject: Re: (usr-tc) Multilink PPP and ShotGun > > > >Thus spake Jason W > >>Is it true that MPPP is unavailable to the Quad > >>modem cards? > > > >The Quad modem cards don't have anything to do with it. They just take > >a data stream in from the line source (pri,t1,nic) and demodulate it and > >pass it on to the netserver. The netserver (or HARC) runs MP. > >-- > >Jeff McAdams Email: jeffm@iglou.com > >Head Network Administrator Voice: (502) 966-3848 > >IgLou Internet Services (800) 436-4456 > > > >- > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Loaded it tonight and seems to be working. Haven't tried any actual v.90, but x2 looks ok -----Original Message----- >I have noticed this is out for HiPer DSP's and HiPer >arc. I know that it currently does not work with the >netserver :-( but has anyone tried this out, and how >is it working? > >Thanks, > >=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= >Jason Watkins I-Land Support & NOC Tech >jwatkins@iland.net http://www.iland.net >=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

-> Hi Jeff. Yes, they are configured to hunt. I opened a ticket report with -> the Telco last night. At first they too were unable to get it to hunt from -> the first PRI to the second PRI, it was ringing busy instead of switching -> over. Then they busied out each channel in the second Hiper DSP's PRI and -> put them back in service. Right after taking them off the busy state the -> hunting started to work. Wierd. -> -> Just out of curiosity; how do you issue that "In Service" command you -> mentioned below? They did the equivalent of the same thing. To do this yourself, go to TCM. Then highlight the 4 LEDs above the channels (LED bar graph) and go to Configuration on the menu bar and then action/commands . Select software and then look for the In Service option and execute it. As a general coruse of business I always do this after a T-1 outage since we are connected to a DMS-100. Fortunately we don't have very many T-1 outages. Jeff Binkley ASA Network Computing

On Thu, 16 Jul 1998, Jeff Mcadams wrote: > Thus spake Robert Adams > > Anyone know if you can do NFAS (2 PRI / 1 D) with two HiPerDSPs? If not, > >will this be supported in the future? > > My understanding is that you cannot do this. Since the cards are > independant entities within the chassis, it will be difficult to get > them to cooperate to do NFAS. There's been no statement that I've seen > from 3Com about possible support for this in the future, but I would > hazard a guess that it would be unlikely, or at the very least, in the > distant future. > -- > Jeff McAdams Email: jeffm@iglou.com So what about the Dual T1/PRI? I've been discussing upgrading our CT1s to PRIs with our telco and need to understand the restrictions that exist regarding multi-card and or multi-span NFAS support across multiple TC Hub chassis. ========================================================================= Jeffrey A. Lynch JORSM Internet email: jeff@jorsm.com Northwest Indiana's Full-Service Provider Voice: (219)322-2180 927 Sheffield Avenue, Dyer, IN 46311 Autoresponse: info@jorsm.com http://www.jorsm.com

It BETTER!! I just ordered 2 additional PRIs without D channels. Check out the specs for the Hiper DSP http://www.3com.com/solutions/svprovider/products/hiperdsp/specs.html It says "Supports NonFacility Associated Signaling(NFAS)" There is also another document somewhere on the 3com web site that is for Provisioning of PRI/T1 lines for TC (ironically, I can't find it). But it says the same thing. I was going to ask the list here shortly how to configure my DSPs for NFAS. Someone please clarify. I got a super deal on these PRIs ($350/ea) and it's not to late to cancel my order on another TC rack I just ordered. Scott > My understanding is that you cannot do this. Since the cards are > independant entities within the chassis, it will be difficult to get > them to cooperate to do NFAS. There's been no statement that I've seen > from 3Com about possible support for this in the future, but I would > hazard a guess that it would be unlikely, or at the very least, in the > distant future. > --

> I'm stumped. I'm not SNMP savvy. I rely on command line and TCM. If no one > else has any ideas, I guess I'm calling USR tech support tomorrow morning... Do you have a spare T1 card you could swap in?? Alternatively, physically pull out and reinstall both the front and back of the T1 card. As I remember, I had to do this once. I actually found out by swapping it out, but when I put the old one back in, it worked as well. | Curtis V. Shambeau | curt@execpc.com | http://www.execpc.com/~curt | | Executive Vice President - Exec-PC, Inc. |

On Fri, 17 Jul 1998, Marcelo Souza wrote: > On Thu, 16 Jul 1998, Laszlo Vecsey wrote: > > |For a moment there I thought I was going to read about a user so fed up > |with Multilink PPP and their usr-tc chasis that they had to resort to > |using a shotgun :) > > 8-)) > > |If you're using radius, set Port-Limit to 2 and you should be all set. > > I set the Port-Limit on Radius to 2 but it seems that the TC is > overriding the radius settings. Because, if I set Port-Limit on Radius > users file to 1 for a expecific user (eg. test) and set MAX_CHANELS to 2 > in the ARC for a DEFAULT user, my "test" user will be able to make the > connection in 2 channels. > But if I set the MAX_CHANNEL to 1 for a default user, the "test" > user will be able to make only ONE connection, even if I set its expecific > configuration on Radius Port-Limit to 2. > > What am I doing wrong? Port limit and max_channel are different attributes. By setting max_channel to 1 you are limiting the channels for the users to 1. Port limit just tells the nas that the user has a limit of 2, and currently the user also has the setting to have a max channel of 1. If you set the max channel to any greater number then port limit will make sure that the user has only the set port limit. The other way is to set the max_channels to the users Max-Channels 0x9802 integer vendor specific attribute. krish > > - Marcelo > > > |On Thu, 16 Jul 1998, Marcelo Souza wrote: > | > |> > |> > |> Does any one here has users trying to use this feature that came > |> with Diamond Supra Sonic II modems? > |> It intend to use two common telephone lines (not ISDN) to make > |> connections up to 112k (2x 56k) using multilink PPP. > |> How can set up my TCs (I have both ARC and Netserver) to enable > |> that ? > |> > |> > |> TIA > |> > |> > |> - Marcelo > |> > |> > |> - > |> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > |> with "unsubscribe usr-tc" in the body of the message. > |> For information on digests or retrieving files and old messages send > |> "help" to the same address. Do not use quotes in your message. > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

I thought the netservers (or rather the quad code) had v.90 support for some time now, along with the courier flash updates that were released. Were those not considered 'official' or 'final' at the time, and now this Hyper version is? - lv On Thu, 16 Jul 1998, Jason W wrote: > I have noticed this is out for HiPer DSP's and HiPer > arc. I know that it currently does not work with the > netserver :-( but has anyone tried this out, and how > is it working? > > Thanks, > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Jason Watkins I-Land Support & NOC Tech > jwatkins@iland.net http://www.iland.net > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Yep, all of us Netservers users are getting the shaft.. the official USR plan is going to be they will refund you $3200 for your old netserver card.. so if you buy a hiperarc for say $6k, you get the privelege of paying $2700 to fix your quake lag problems. And bring your own vaseline! Reply-to: usr-tc@lists.xmission.com So far, the HiperARC would be useless to us since we have trouble getting certain ISDN modems (Adtran & 3Com) to connect to the Quad modems. Unless I am mistaken, the HiPerARCS do not have ISDN on-board. Lee Laszlo Vecsey wrote: > Sounds like the incredible deal will have to be a free trade in, because > even then it wont be useful to all of us. > > - lv > > On Sat, 11 Jul 1998, Jamie Orzechowski wrote: > > > well ... I am not kidding .. I was asking about quake lag and he started > > talking about how the ppp stack code was 6 years old and would have to be > > completely redone ... he said NETServers will becom unsupported hardwas this > > christmas and they will FORCE users to upgrade to HiPERARC's by this > > "INCREDIBLE DEAL" and he mention INCREDIBLE many times =) ... but would give > > any prices ... he said they just want everyone to upgrade to HiPER ARC's > > ASAP ... guess that's the reason for the deal ... I don;t remeber his name > > but he was a level 2 support and a team leader also ... > > > > -----Original Message----- > > From: Jeff Mcadams <jeffm@iglou.com> > > To: usr-tc@lists.xmission.com <usr-tc@lists.xmission.com> > > Date: Saturday, July 11, 1998 10:12 PM > > Subject: (usr-tc) Netservers becoming unsupported?! > > > > > > >Thus spake Jamie Orzechowski > > >>BTW: I was talking with a USR Level 2 support guy and he sais NETServers > > >>will become unsupported this christmas ... but they will have an AMAZING > > >>deal on HiPER ARC's because they are going to force the end users to > > upgrade > > >>... so I guess that's a good thing ... =) > > > > > >Say WHAT?! You *are* kidding us, right? I hope? If USR/3Com pulls > > >support for the Netservers by Christmas, I for one will start screaming > > >bloody murder and cozy up really nice with my local Cisco rep. That is > > >unless they make some *phenomenal* improvements to the HiPer equipment > > >from what I've seen. At this point, the HiPer stuff just isn't up to > > >snuff for what we use it for, our setup *requires* some of the protocol > > >support that the netservers have that the HiPer doesn't at this point > > >(yeah, yeah, its in beta, I know) and I have serious doubts that the > > >support for these protocols (MPIP in specific) will be ready for prime > > >time and still leave us enough time to get all of our equipment switched > > >over...This isn't even considering the cost of upgrading (even with an > > >AMAZING deal, it will still cost us money, how much you want to bet?) > > > > > >Someone please tell me that this is a miscommunication somewhere along > > >the way. > > >-- > > >Jeff McAdams Email: jeffm@iglou.com > > >Head Network Administrator Voice: (502) 966-3848 > > >IgLou Internet Services (800) 436-4456 > > > > > >- > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > with "unsubscribe usr-tc" in the body of the message. > > > For information on digests or retrieving files and old messages send > > > "help" to the same address. Do not use quotes in your message. > > > > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message. Digital Service Consultants - Atlanta,GA http://www.dscga.com QUALITY Internet Service Provider (770) 455-9022 Dedicated ISDN 64k-512k, Fractional & Full T1, Frame Relay

Is it true that MPPP is unavailable to the Quad modem cards? =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Jason Watkins I-Land Support & NOC Tech jwatkins@iland.net http://www.iland.net =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= -----Original Message----- >Thus spake Charles Sprickman >>Thanks... Are MP,MLPPP,Multilink, and friends all the same thing? > >Yup, all the same thing...if you feel like some really dry reading, you >can check out RFC 1990 for the spec. > >>Is >>there an easy way to run the MPIP server off something besides one of your >>Netservers? > >3Com has made available to a few people code that's written to compile >on Solaris, but its really pitiful and its a real resource hog. Ricky >Beam was working on cleaning it up...I haven't gotten any word from him >in a while concerning it though... <hint> > >>And lastly, how do other vendors handle this issue? > >Other vendors have their own protocols, analogous to MPIP (Cisco calls >theirs MMP I believe), so (of course) nothing interoperates in this >respect. >-- >Jeff McAdams Email: jeffm@iglou.com >Head Network Administrator Voice: (502) 966-3848 >IgLou Internet Services (800) 436-4456 > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

I just ran across a "for sale" ad for one of these. It looks a lot like a Total Control unit. Is it the same? Randy

Thus spake Jeff Lynch >So what about the Dual T1/PRI? I've been discussing upgrading our >CT1s to PRIs with our telco and need to understand the restrictions >that exist regarding multi-card and or multi-span NFAS support across >multiple TC Hub chassis. The dual t1/pri card will do NFAS between the two spans connected to the card. It will not do NFAS with another PRI card in the same chassis, or one in another chassis. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Ahhhh.... I see. Is there any documantation on how to config this? I have hunted through my USRTC doc's and have come up empty. I would need information on both Netservers and HiPer Arc's. Thanks for the info. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Jason Watkins I-Land Support & NOC Tech jwatkins@iland.net http://www.iland.net =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= -----Original Message----- >Thus spake Jason W >>Is it true that MPPP is unavailable to the Quad >>modem cards? > >The Quad modem cards don't have anything to do with it. They just take >a data stream in from the line source (pri,t1,nic) and demodulate it and >pass it on to the netserver. The netserver (or HARC) runs MP. >-- >Jeff McAdams Email: jeffm@iglou.com >Head Network Administrator Voice: (502) 966-3848 >IgLou Internet Services (800) 436-4456 > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Does anyone have the pinout for the HiPer DSP's console port? Also, does anyone use a Power Sentry in conjunction with their TC rack? I have a slight problem when accessing the Hiper DSP's console port via one of the Power Sentry's passthrus. Eric --- Eric J. Lorenzo Field Engineer v:650.237.1465 f:650.237.1499 Lorenzo@MediaCity.com www.ISPchannel.com

Thus spake Jason W >Is it true that MPPP is unavailable to the Quad >modem cards? The Quad modem cards don't have anything to do with it. They just take a data stream in from the line source (pri,t1,nic) and demodulate it and pass it on to the netserver. The netserver (or HARC) runs MP. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

is there beta 3.8.X NETServer code??? -----Original Message----- Cc: USRTC <usr-tc@lists.xmission.com> > >On Thu, 16 Jul 1998, Jason W wrote: > >> I have noticed this is out for HiPer DSP's and HiPer >> arc. I know that it currently does not work with the >> netserver :-( but has anyone tried this out, and how >> is it working? > >It is not that the DSP does not work with the netserver. Our STG has not >tested and certified this code with the netserver. However the beta code >3.8.x should work with the DSP code. > > >krish > >> >> Thanks, >> >> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= >> Jason Watkins I-Land Support & NOC Tech >> jwatkins@iland.net http://www.iland.net >> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= >> >> >> - >> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" >> with "unsubscribe usr-tc" in the body of the message. >> For information on digests or retrieving files and old messages send >> "help" to the same address. Do not use quotes in your message. >> > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

On Fri, 17 Jul 1998, Jeff Mcadams wrote: > Thus spake Jeff Lynch > >So what about the Dual T1/PRI? I've been discussing upgrading our > >CT1s to PRIs with our telco and need to understand the restrictions > >that exist regarding multi-card and or multi-span NFAS support across > >multiple TC Hub chassis. > > The dual t1/pri card will do NFAS between the two spans connected to the > card. It will not do NFAS with another PRI card in the same chassis, or > one in another chassis. > -- > Jeff McAdams Email: jeffm@iglou.com Ameritech only includes one D-channel per PRI trunk group. They want like $150/mo per additional D channel. The Dual T1/PRI card isn't too bad since I wouldn't want to run more than say 3 or 4 spans from a single D, but the inability of the DSP to support NFAS on at least the same chassis is somewhat rediculous. If D channels were free, it wouldn't matter as much. I wouldn't mind burning a B channel on each span for a D channel to get the independence on each span but at significant telco cost increases, it looks like the PM3s with multichassis NFAS support win again in this round. ========================================================================= Jeffrey A. Lynch JORSM Internet email: jeff@jorsm.com Northwest Indiana's Full-Service Provider Voice: (219)322-2180 927 Sheffield Avenue, Dyer, IN 46311 Autoresponse: info@jorsm.com http://www.jorsm.com

> Ameritech only includes one D-channel per PRI trunk group. They > want like $150/mo per additional D channel. The Dual T1/PRI card Ameritech in your area maybe. Up here in WI they don't do that. | Curtis V. Shambeau | curt@execpc.com | http://www.execpc.com/~curt | | Executive Vice President - Exec-PC, Inc. |

Thus spake Jason W >Ahhhh.... I see. Is there any documantation on how to config >this? I have hunted through my USRTC doc's and have come >up empty. I would need information on both Netservers and >HiPer Arc's. Thanks for the info. Not sure on the HARC's since we don't have any yet, but on the netserver, uhm...I believe they default to having MP enabled, but the command is "set mp on" -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Bill Tidwell wrote: > > Yep, all of us Netservers users are getting the shaft.. the official > USR plan is going to be they will refund you $3200 for your old > netserver card.. so if you buy a hiperarc for say $6k, you get the > privelege of paying $2700 to fix your quake lag problems. And bring > your own vaseline! > Look our Livingston, here I come! They have got to be kidding! Lee

Thus spake Lee >Bill Tidwell wrote: >> Yep, all of us Netservers users are getting the shaft.. the official >> USR plan is going to be they will refund you $3200 for your old >> netserver card.. so if you buy a hiperarc for say $6k, you get the >> privelege of paying $2700 to fix your quake lag problems. And bring >> your own vaseline! >Look our Livingston, here I come! They have got to be kidding! I'm actually looking at the AS5300 from Cisco. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Thus spake Randy Cosby >I just ran across a "for sale" ad for one of these. It looks a lot like >a Total Control unit. Is it the same? Basically, yes...Cisco licensed the Total Control Chassis system from USR for the AS5100. The one caveat is that they didn't get the netserver with it (since the netserver code was itself licensed by USR from Livingston...oh the tangled web we weave), so Cisco made a version of the 2511 that was on a card that slid into the USR Total Control Chassis. The individual card was called the AS51. Quite a nice little idea, I wish they hadn't quit selling it as I'd very much like to buy a few for some of our racks in our remote locations. However, keep in mind that these are some of the older cards here...like, I think they had the 186 based T1 cards in them, but if the price is right, it might be nice to get it just for the AS51 (at least IMHO). -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Thus spake Jeff Lynch >On Fri, 17 Jul 1998, Jeff Mcadams wrote: >> Thus spake Jeff Lynch >> >So what about the Dual T1/PRI? I've been discussing upgrading our >> >CT1s to PRIs with our telco and need to understand the restrictions >> >that exist regarding multi-card and or multi-span NFAS support across >> >multiple TC Hub chassis. >> The dual t1/pri card will do NFAS between the two spans connected to the >> card. It will not do NFAS with another PRI card in the same chassis, or >> one in another chassis. >Ameritech only includes one D-channel per PRI trunk group. They >want like $150/mo per additional D channel. The Dual T1/PRI card >isn't too bad since I wouldn't want to run more than say 3 or 4 >spans from a single D, but the inability of the DSP to support >NFAS on at least the same chassis is somewhat rediculous. If >D channels were free, it wouldn't matter as much. I wouldn't mind >burning a B channel on each span for a D channel to get the independence >on each span but at significant telco cost increases, it looks like >the PM3s with multichassis NFAS support win again in this round. Hrmm...I don't know...I would think a CLEC would win over Ameritech (if available, I know not everyone has CLEC's available everywhere) in this round rather than switching NAS equipment. (I've never been particularly impressed with Ameritech anyway). -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Jeff Mcadams writes: >Other vendors have their own protocols, analogous to MPIP (Cisco calls >theirs MMP I believe), so (of course) nothing interoperates in this >respect. This lack of interoperability may change as vendors start implementing L2TP (Layer Two Tunneling Protocol). Solving the multi-chassis MP problem was not the main motivation behind L2TP, but it does seem like a natural application for it. This is acknowledged in the introduction to the Internet draft, which says: This protocol may solve the "multilink hunt-group splitting" problem. Multilink PPP [9], often used to aggregate ISDN B channels, requires that all channels composing a multilink bundle be grouped at a single NAS. Because L2TP makes a PPP session terminate at a location other than the point at which the session was physically received, it can be used to make all channels terminate at a single NAS, allowing multilink operation even when the physical calls are spread across distinct physical NAS's. See <URL:ftp://ftp.ietf.org/internet-drafts/draft-ietf-pppext-l2tp-11.txt> for the full text of the current L2TP draft. -Mark- -- Mark R. Levinson, Network Engineer Information Systems & Computing University of Pennsylvania mrl@isc.upenn.edu

Thus spake Mark R. Levinson >Jeff Mcadams writes: >>Other vendors have their own protocols, analogous to MPIP (Cisco calls >>theirs MMP I believe), so (of course) nothing interoperates in this >>respect. >This lack of interoperability may change as vendors start implementing >L2TP (Layer Two Tunneling Protocol). Solving the multi-chassis MP problem >was not the main motivation behind L2TP, but it does seem like a natural >application for it. Well...sorta...for example, netservers actually use vtp to tunnel the connections to the NAS that needs them, MPIP is only the *control* protocol for this, l2tp would/could replace vtp in this instance, but you would still need a protocol to control *where* these tunnels are made, at this point, there is no "standard" protocol that I'm aware of either in place or on the horizon that would replace the functionality that MPIP (and other protocols for other vendors) that actually *coordinate* where those tunnels are made. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Total Control Hub : 16-slot chassis single 110v ac 70Amp power supply, fan tray, ethernet network management card 12 Quad v34 Digital Modem NAC (48 ports total, 56k v.90) Netserver PRI Dual PRI/T1 - supports analog/ISDN Asking $7,500 for above bundle. OR separately: Quad v34 Digital Modem NAC $500 Analog/Digital Modem NIC/NAC $1,000 Netserver PRI $900 Dual PRI/T1 $900 USR Courier v.90 ext . modem $150 All products are used and in excellent condition. Buyer is responsible for shipping. Contact brwiser@xmission.com, or call Brian at 801-539-0852, extension 131. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= XMission Internet Access | Save a Tree -- Use Email! 51 E. 400 S, Suite 200 | Salt Lake City, UT 84111 | Hardware & Software Sales: Voice 801.539.0852 | http://www.xmission.com/general/retail.html Fax 801.539.0853 | =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Brian

> >Thus spake Lee >>Bill Tidwell wrote: >>> Yep, all of us Netservers users are getting the shaft.. the official >>> USR plan is going to be they will refund you $3200 for your old >>> netserver card.. so if you buy a hiperarc for say $6k, you get the >>> privelege of paying $2700 to fix your quake lag problems. And bring >>> your own vaseline! > >>Look our Livingston, here I come! They have got to be kidding! > And they want you to pay $3915/year for support on this old chassis that they don't even support! You would expect them to give you a Hyper Arc after paying for the annual support. I have noticed that they now require a support contract for every chassis (which they now track) or they will not allow username/password access to the total service web site. If you have a bunch of chassis it costs a small fortune to support them year after year. And you can't just get support for one or two of them anymore expecting to support all of your chassis. Unless you pay for all chassis then no access. These bundles look cheap in the first year, but after that you are screwed. If you work out the supported price per port over the life of the product you will see that the 3Com product is no >bargain. Lucington is looking good now....

On Fri, 17 Jul 1998, Chris Peltier wrote: > >>Bill Tidwell wrote: > >>> Yep, all of us Netservers users are getting the shaft.. the official > >>> USR plan is going to be they will refund you $3200 for your old > >>> netserver card.. so if you buy a hiperarc for say $6k, you get the > >>> privelege of paying $2700 to fix your quake lag problems. And bring > >>> your own vaseline! > > > >>Look our Livingston, here I come! They have got to be kidding! > > > And they want you to pay $3915/year for support on this old chassis > that they don't even support! You would expect them to give you > a Hyper Arc after paying for the annual support. I have noticed The initial reports that Netserver support was being dropped at the end of the year appear to be incorrect. What they are doing is stopping the sale of any new Netservers after the end of the year. Brian

On Fri, 17 Jul 1998, Jeff Mcadams wrote: > >Look our Livingston, here I come! They have got to be kidding! > > I'm actually looking at the AS5300 from Cisco. Don't forget to ask about their "Take out the Trash" trade-in program after you've received the base pricing... They'll buy up your, erm, "trash" at a pretty decent price. Charles > -- > Jeff McAdams Email: jeffm@iglou.com > Head Network Administrator Voice: (502) 966-3848 > IgLou Internet Services (800) 436-4456 > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > =-----------------= = | Charles Sprickman Internet Channel | | INCH System Administration Team (212)243-5200 | | spork@inch.com access@inch.com | = =----------------=

Eric said once upon a time: > >Does anyone have the pinout for the HiPer DSP's console port? It is in the archives. Go to: http://usr-tc.datasys.net

Is the archive no longer updated? > -----Original Message----- > From: owner-usr-tc@lists.xmission.com > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Pete Ashdown > Sent: Friday, July 17, 1998 12:08 PM > To: usr-tc@lists.xmission.com > Subject: Re: (usr-tc) Pinout for HiPer DSP console port and TC use with > a Power Sentry? > > > Eric said once upon a time: > > > >Does anyone have the pinout for the HiPer DSP's console port? > > It is in the archives. Go to: http://usr-tc.datasys.net > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

> >The initial reports that Netserver support was being dropped at the end >of >the year appear to be incorrect. What they are doing is stopping the >sale >of any new Netservers after the end of the year. > Failure to fix the UDP packet loss in the NetServer is what I consider unacceptable and hence no-support. Are you suggesting that there will be future software release(s) to fix this and other problems? I see no value in any support contracts unless they do continue future software releases for the NetServer. Especially now since this equipment can be had for < 50 cents on the dollar and dropping fast. >

On Thu, 16 Jul 1998, Laszlo Vecsey wrote: |For a moment there I thought I was going to read about a user so fed up |with Multilink PPP and their usr-tc chasis that they had to resort to |using a shotgun :) 8-)) |If you're using radius, set Port-Limit to 2 and you should be all set. I set the Port-Limit on Radius to 2 but it seems that the TC is overriding the radius settings. Because, if I set Port-Limit on Radius users file to 1 for a expecific user (eg. test) and set MAX_CHANELS to 2 in the ARC for a DEFAULT user, my "test" user will be able to make the connection in 2 channels. But if I set the MAX_CHANNEL to 1 for a default user, the "test" user will be able to make only ONE connection, even if I set its expecific configuration on Radius Port-Limit to 2. What am I doing wrong? - Marcelo |On Thu, 16 Jul 1998, Marcelo Souza wrote: | |> |> |> Does any one here has users trying to use this feature that came |> with Diamond Supra Sonic II modems? |> It intend to use two common telephone lines (not ISDN) to make |> connections up to 112k (2x 56k) using multilink PPP. |> How can set up my TCs (I have both ARC and Netserver) to enable |> that ? |> |> |> TIA |> |> |> - Marcelo |> |> |> - |> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" |> with "unsubscribe usr-tc" in the body of the message. |> For information on digests or retrieving files and old messages send |> "help" to the same address. Do not use quotes in your message.

Jeff Mcadams was heard to say: >I'm actually looking at the AS5300 from Cisco. I've been looking at one... If you can figure out how to get the thing to act correctly, then it's not too bad of a box. Of course, it's k56 based (Telebit MICA Modem technology -- personally, I'd take the MICAblazer.) AND, it's got next to no LED status feedback on it. --Ricky

On Fri, 17 Jul 1998, Eric wrote: > Does anyone have the pinout for the HiPer DSP's console port? > > Also, does anyone use a Power Sentry in conjunction with their TC rack? I > have a slight problem when accessing the Hiper DSP's console port via one > of the Power Sentry's passthrus. Maybe this is what you need: I found the secret color scheme for connecting the Sentry R-2000 serial ports to a USR NIC. Use the standard 568B RJ48C color scheme on one end (http://www.ionet.net/~chill/eiatia.html) and do this on the RJ-12 end that plugs into the Sentry: 1 -- Blue 2 -- Green/White 3 -- Green 4 -- Blue/White 5 -- Orange/White 6 -- Blank Cut off the solid orange wire, strip the Brown pair and twist them together and crimp (or just cut them off, too). On the HiPer ARC cards you have to flip dip switch 6 to diable flow control. I'm not sure if it's the same on the HiPer DSP cards. ??? Regards, Charles Hill ioNET Network Specialist work: 405.270.7020 cell: 405.833.5477 pager: 405.559.6697 or 4058335477@mobile.att.net email: chill@ionet.net http://www.ionet.net/~chill ICQ: 4923465@pager.mirabilis.com

Thus spake Ricky Beam >Jeff Mcadams was heard to say: >>I'm actually looking at the AS5300 from Cisco. >I've been looking at one... If you can figure out how to get the thing to >act correctly, then it's not too bad of a box. Of course, it's k56 based >(Telebit MICA Modem technology -- personally, I'd take the MICAblazer.) >AND, it's got next to no LED status feedback on it. Yeah, but its Cisco, you don't *need* LED status feedback on it. You can get feedback from the thing in any other way imaginable, SNMP, telnet, CDP, you name it! :) -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Charles Sprickman was heard to say: >> I'm actually looking at the AS5300 from Cisco. > >Don't forget to ask about their "Take out the Trash" trade-in program >after you've received the base pricing... They'll buy up your, erm, >"trash" at a pretty decent price. I wouldn't exactly call the USR TC hardware "trash" -- the hardware is perfectly ok; it's the software that could use a good bit of GNU engineering. I've been playing with TC hardware of over a year (almost continuously) now, and I like it. They are a little more cumbersome than the Microcom HDMS chassis they replaced -- the Microcom INC (Intellegent Network Controller) has more usable intellegence than the entire TC chassis and it's a 68K based thing. BUT, once you get used to it -- and write your own software for managing them -- the TC hardware is quite usable. It's got its quirks, but everything else does too. As for the AS5300... Cicso will give you a trade-in for the hardware you replace -- most serious hardware vendors will, so that's not a real key motivator. The best thing about the 5300 is the chassis-cost density. It will handle 4 T1/PRI (E1's too) in ~2RU's for ~20-30k$US as opposed to the USR 2 T1/PRI with quads (~10k$US) or 14 T1/PRI with hiperDSP/ARC ($$$) in 6RU. IMHO, if 3com/USR wants to stay in this business, then they need to wise up to the fact that everyone on the planet doesn't have a need for hiperDSP hardware. Interpath is fairly large ISP and we only have maybe 4 locations that could benefit from hiperDSP modem desities. Quad modems and the NetServer are still a *very* good bundle. Maybe the hiperARC works just as well (I'll let ya' know once I get my hands on one) but it seems like an enormous waste of processing power. [I've got 386-40/4MB netblazers that handle things better than the 486dx4-100/32MB netservers which only strengthens my view that the netserver os code is a waste of drive space.] If 3Com doesn't want to fix the netserver os, then give the rest of us enough information to write our own os. --Ricky

--0__=C8ZciNNAGo6H2oqyoinvrOxb8pWgFclzST9tta7wUIZLHwBbsPCQs2Nl Content-type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-transfer-encoding: quoted-printable Randy, Before adopting some other manufacturers like Microcom ( AS5200 ), Tele= bit ( AS5300 )....., Cisco had an OEM contract with USRobotics that we cancelled several years ago. While this phase of agreement, we supplied= our products to Cisco ( Modem Cards ) and Cisco added their routing card ( = IOS on board ). That's the reason for which the AS5100 looks like the TC chassis. Regards. St=E9phane Kerfers Network Consultant - 3Com / USRobotics Carrier Randy Cosby <dcosby@infowest.com> on 17/07/98 15:46:43 Please respond to usr-tc@lists.xmission.com cc: (Stephane Kerfers/FR/3Com) = --0__=C8ZciNNAGo6H2oqyoinvrOxb8pWgFclzST9tta7wUIZLHwBbsPCQs2Nl Content-type: text/plain; charset=us-ascii Content-Disposition: inline I just ran across a "for sale" ad for one of these. It looks a lot like a Total Control unit. Is it the same? Randy - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message. --0__=C8ZciNNAGo6H2oqyoinvrOxb8pWgFclzST9tta7wUIZLHwBbsPCQs2Nl--

Chris Peltier was heard to say: >Failure to fix the UDP packet loss in the NetServer is what I consider >unacceptable and hence no-support. >Are you suggesting that there will be future software release(s) to fix >this and other problems? >I see no value in any support contracts unless they do continue future >software releases for the NetServer. Especially now since this >equipment can be had for < 50 cents on the dollar and dropping fast. The real problem is the amount 3Com wants to support the hardware. The Netserver is not going to get anything but serious bug fixes as they no longer have a license for the ComOS running on it and they are unwilling to write a new OS for it (as I see it, a fairly trivial thing.) 3Com restructured the support offering and seems to have failed to price them based on the cost of the hardware. I was quoted 160k$US for support for our 47 chassis -- I laughed. That's more than 1/4 the original purchase cost of the 47 chassis from last year. At that rate, we could flat out replace 16 chassis. Software support alone is 1800$US per chassis. Why should we paid 85k$US for software support when we aren't being supported? And pretty soon, there will be no more software updates for the hardware we have and use (i.e. Netservers)? Out of 47 chassis', we've had very little hardware break; we have spare hardware on hand so 24hr replacement is not needed -- if you can get it fixed and back to us in 2 weeks, then we're happy. Maybe 3Com should look at how other vendors are doing things... like Ascend and Faralon maybe? There are several versions of the Ascend P50 and Ascend still provides free software updates for all of them despite the fact that some of the older models have not been in production for several years. Look at Cisco... their support is what 15% of the hardware cost? And in some cases, you don't need a support contract to get help or updated code. If you call 3Com support without a valid contract ID, they will hangup on you. (That's just rude. We are, after all, a 3Com customer.) I think the real problem is that 3Com/USR is selling there products well below development and support costs. And now they are trying to make up some of the loses by charging insane amounts for very little support. Just look at how many times *you* have called 3Com for help. Isn't it odd how much 3Com will cosy up to you when they think they are about to lose your business? They need to stop playing these games... this is what it costs - period. If you want a better deal, draw up a contract. (Again, this is the way Cisco works. And it's the way Faralon works.) I also like the way we are their software/hardware testers. Those in the beta program(s) don't get anything out of it. They (we) get early access to software and in some rare cases, hardware. About 75% of the time, the bugs that are reported are ignored. (Every one of the bugs I reported for TCM were ignored.) --Ricky

We use a script which snmpgets all the required info. Here's an example for modem utilization on an ARC. It's a fast hack with a UNIX shell script. Perl would have been better, but heck... it's just a couple lines ;-) mrtg.cfg Replace A.B.C.D in the 1st line by the IP Address of your ARC [snip] Target[arc1.1]: `/opt/mrtg/bin/tclget A.B.C.D` PageTop[arc1.1]: <H1>Total Control 1 ARC 1</H1> MaxBytes[arc1.1]: 420 Title[arc1.1]: Total Control 1 ARC 1 Supress[arc1.1]: ym Options[arc1.1]: gauge, absolute YLegend[arc1.1]: Modems ShortLegend[arc1.1]: Modems [snap] tclget Replace public in line 5 by your RO snmp community string [snip] #!/sbin/sh MIBFILE=/opt/mrtg/bin/mib.txt export MIBFILE mv /tmp/ifspeed.$1 /tmp/ifspeed.$1.old 2>/dev/null /usr/local/shareware/snmp-2.1.2l2/apps/snmpwalk -v 1 $1 public interfaces.ifTable.ifEntry.ifSpeed > /tmp/ifspeed.$1 toto=`wc -l /tmp/ifspeed.$1 | awk ' { print $1}'` if [ "$toto" -lt 10 ] then mv /tmp/ifspeed.$1.old /tmp/ifspeed.$1 2> /dev/null fi cat /tmp/ifspeed.$1 | awk -f /usr/local/shareware/snmp-2.1.2l2/awkf | /bin/head -1 | tee /tmp/tcl.$1.modem [snap] Hope this helps you building nice graphs... Oh yeah, you'll need some kind of SNMP package to get the actual data, we use an old version of snmpwalk we found on the web, but well, any package with the correct MIB should do the trick... Robert von Bismarck Petrel Communications SA PS : comments about the code are welcome.... > -----Original Message----- > From: Chris Peltier [SMTP:CPELTIER@iectech.com] > Sent: mercredi, 15. juillet 1998 17:59 > To: 'rvb@petrel.ch' > Subject: RE: (usr-tc) Possible fix for HiperDSP modem 1 in > down-up state ? > > > What kind of mrtg.cfg entries do you use to get modem > utilization, etc.. from you Hyper ARC/DSP? If you > don't mind me asking. > > Sincerely, > Chris Peltier > > * email: CPeltier@NetCarrier.com > * voice: 215-257-4917 > * FAX: 215-257-4916 > > > > >---------- > >From: Robert von Bismarck[SMTP:rvb@petrel.ch] > >Sent: Wednesday, July 15, 1998 12:04 PM > >To: 'usr-tc@xmission.com' > >Subject: (usr-tc) Possible fix for HiperDSP modem 1 in down-up > state ? > > > > > >Greetings, > > > >We had some trouble for a while with the 1st modem of some HiPerDSP > >cards staying in the down - up state when I did a list conn on the > >associated ARC. We finally solved this problem by making a mistake > (!). > >I had to reset the configuration of several DSP's and forgot to put > the > >modems into Round-Robin. So they stayed in "Fixed Assignment" and, > >POOF, > >the problem went away, my MRTG graphs showed that all my modems went > up > >when I reset all the modems with the new config !!! > >Is this a known fix for this bug ? > > > >Regards, > > > >Robert von Bismarck > > > >PS : I had the telco set my hunt group to cyclic, so that the modems > >get > >picked up in a simili-roundrobin fashion, so as to equalize the load > on > >all the ports... > > > >- > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > >

Jeff Mcadams was heard to say: >>AND, it's got next to no LED status feedback on it. > >Yeah, but its Cisco, you don't *need* LED status feedback on it. You >can get feedback from the thing in any other way imaginable, SNMP, >telnet, CDP, you name it! :) Umm, blinky flashy lights? Nothing impresses customers more than lots of blinkin' lights in the NOC when they get a tour. And the USR hardware is one of the best sellers along side the SMC switches (yeah, it's workgroup device, but them blinkin' lights grabs the eye -- CBS thought it was "impressive") Staring at a 6' rack full of 2RU grey boxes just doesn't do it for me :-) --Ricky PS: have you ever stood infront of a quad modem rack during an SDL? or a chassis wide hardware/software reset? (I thrill the helpdesker's doing that :-))

On Fri, 17 Jul 1998, Jeff Mcadams wrote: > >I've been looking at one... If you can figure out how to get the thing to > >act correctly, then it's not too bad of a box. Of course, it's k56 based > >(Telebit MICA Modem technology -- personally, I'd take the MICAblazer.) > >AND, it's got next to no LED status feedback on it. > > Yeah, but its Cisco, you don't *need* LED status feedback on it. You > can get feedback from the thing in any other way imaginable, SNMP, > telnet, CDP, you name it! :) Some of us happen to *LIKE* LED's which help us diagnose a problem when we have a field tech working on things. Field tech's often don't carry full Win95 machines around with them to run TCM, etc., and are normally not qualified to do all the maintenance that we do from home. It's not that we don't want them to have that knowlege, it's a whole heck of a lot cheaper though, to pay someone who knows how to read LED's than it is to train them to understand complicated settings enough to become a network engineer. Watching lights is boring you say? That's okay. They're also an added plus when showing off equipment. Customers like to see lots of lights and since our network ops room is behind glass, we'd like it to be a good PR thing. Now, if only we can get 3Com to support those NetServers like they're supposed to... Are we looking at Cisco and Ascend? You betcha. Up until recently, we've been basically a USR/3Com house. I guess 3Com hasn't learned not to throw rocks in a glass house yet. Their recent activity with the NetServer has been a huge rock. So much for keeping customers who buy 10+ chassis a year happy... Kevin Benton Network Engineer SOTA Technologies, Inc. E-Mail: s1kevin@tims.net Web: http://users.sota-oh.com/~s1kevin/ Unsolicited advertisements processing fee: $50 subject to change without notice

Thus spake Ricky Beam >Jeff Mcadams was heard to say: >>>AND, it's got next to no LED status feedback on it. >> >>Yeah, but its Cisco, you don't *need* LED status feedback on it. You >>can get feedback from the thing in any other way imaginable, SNMP, >>telnet, CDP, you name it! :) >Umm, blinky flashy lights? Well, yeah, yeah, be pedantic! :) For actual *functionality*, Cisco's do fine with that. Agreed, they are kinda boring to show people. :) But they're also kinda boring to admin since they just work, so I guess that kinda goes hand in hand. >Nothing impresses customers more than lots of blinkin' lights in the NOC >when they get a tour. And the USR hardware is one of the best sellers >along side the SMC switches (yeah, it's workgroup device, but them >blinkin' lights grabs the eye -- CBS thought it was "impressive") >Staring at a 6' rack full of 2RU grey boxes just doesn't do it for me :-) >PS: have you ever stood infront of a quad modem rack during an SDL? or a > chassis wide hardware/software reset? (I thrill the helpdesker's doing > that :-)) Indeed, upgrades are quite impressive to watch. :) -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

-> >Ameritech only includes one D-channel per PRI trunk group. They >want like -> $150/mo per additional D channel. The Dual T1/PRI card >isn't too bad since -> I wouldn't want to run more than say 3 or 4 >spans from a single D, but the -> inability of the DSP to support >NFAS on at least the same chassis is -> somewhat rediculous. If -> >D channels were free, it wouldn't matter as much. I wouldn't mind >burning -> a B channel on each span for a D channel to get the independence >on each -> span but at significant telco cost increases, it looks like >the PM3s with -> multichassis NFAS support win again in this round. -> Hrmm...I don't know...I would think a CLEC would win over Ameritech (if -> available, I know not everyone has CLEC's available everywhere) in this -> round rather than switching NAS equipment. (I've never been -> particularly impressed with Ameritech anyway). We buy Ameritech services from a CLEC at 40% off of Ameritech's prices and there is no extra charge for a D channel on each PRI. Jeff Binkley ASA Network Computing

Number of active modems + 1 krish \ T.S.V. Krishnan \ \ Network System Engineer \ ( : - : ) \ 3Com ............ \ ----------------------------------------------/ tkrishna@bubba.ae.usr.com ----------------------------/ http://interproc.ae.usr.com ----/ The Yadda Yadda Search - for simple anwers - http://interproc.ae.usr.com/tkb.html Any Sufficiently advanced bug is indistinguishable for a feature. - Rick Kulawiec On Fri, 17 Jul 1998, dbaud wrote: > When assigning an address pool on Netserver or even Harc, what is the recomended pool size for a chassis with 2 PRI's? > > Donald Baud > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

When assigning an address pool on Netserver or even Harc, what is the recomended pool size for a chassis with 2 PRI's? Donald Baud

At 11:33 PM 7/17/98 -0400, you wrote: >When assigning an address pool on Netserver or even Harc, what is the recomended pool size for a chassis with 2 PRI's? I went ahead and assigned 96 to mine(HARC), that gives me room to expand to 2 more PRI's without having to worry about juggling numbers. Kirk Kirk Mitchell-General Manager mitch@keyconn.net Keystone Connect http://www.keyconn.net ***** Providing quality internet services in central PA ***** ******* (814)941-5000 We unlock the world ********

On Sat, 18 Jul 1998, Ken Hunter, Aspiring Technologies wrote: > need to be able to do RIP V1 or V2 (prefer V2) between usr netserver 8/16 > and cisco 2501 running 11.xx ios - anyone care to share their setup notes. > Netserver documentation is about as clear as mud. > > P.S. plz hurry, On the NETServer enable rip version 2 and disable rip options - send_compat set ip net ip rip ripv2 set ip net work ip rip_policy no_send_compat This will for the NETServer to use multicast for ripv2 and cisco wil understand this. with send_compa you will be sending rip v 2 with broadcast krish > > Thanks in advance, > > Ken :) > > - > ************************************************************************ > Web Hosting, E-mail addresses, DNS services, Dedicated circuits. > 33.6, X2, V.90, ISDN Dialup available in Prince William County VA. > > Ken Hunter Aspiring Technologies > mailto:ken@aspire.net 9304 Troy Drive > http://www.aspire.net Nokesville, Va 20181 > telnet://sage.aspire.net Try our ISP/Net Guest account > username: ispguest > password: ispguest > ************************************************************************ > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Thus spake dbaud >When assigning an address pool on Netserver or even Harc, what is the recomended pool size for a chassis with 2 PRI's? I use 48 and have had no problems, it is a nice idea to add an extra one or two in there so it doesn't try to assign one to the console port and so use up and extra IP number. Considering that with 2 PRI's, you most likely only have 46 ports that actually get used, 48 should leave you some buffer, but to *really* be safe, make it 49 (48 channels on the PRIs and the console port). -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

need to be able to do RIP V1 or V2 (prefer V2) between usr netserver 8/16 and cisco 2501 running 11.xx ios - anyone care to share their setup notes. Netserver documentation is about as clear as mud. P.S. plz hurry, Thanks in advance, Ken :) - ************************************************************************ Web Hosting, E-mail addresses, DNS services, Dedicated circuits. 33.6, X2, V.90, ISDN Dialup available in Prince William County VA. Ken Hunter Aspiring Technologies mailto:ken@aspire.net 9304 Troy Drive http://www.aspire.net Nokesville, Va 20181 telnet://sage.aspire.net Try our ISP/Net Guest account username: ispguest password: ispguest ************************************************************************

Once upon a time Ricky Beam shaped the electrons to say... >I've been looking at one... If you can figure out how to get the thing to >act correctly, then it's not too bad of a box. Of course, it's k56 based Of course, now that V.90 is appearing that seems to be a moot point. >(Telebit MICA Modem technology -- personally, I'd take the MICAblazer.) Jesus, WHY? The MICABlazer *sucks* from a HW design aspect, as well as OS. The AS5300 is a far superior unit. Besides, Cisco owns MICA now, they dod the development. Besides, the MICABlazer is dead. ITK has all but totally killed it, OS 3.4 is still pending, and after that very little is expected. You should see the Telebit mailing list. >AND, it's got next to no LED status feedback on it. I've never understood the LED thing - but have you seen Lucents PMVision (formerly codenamed 'Amber') and the onscreen backpanel display? :-) -MZ -- <URL:mailto:megazone@megazone.org> Gweep, Discordian, Author, Engineer, me.. Join ISP/C Internet Service Providers' Consortium <URL:http://www.ispc.org/> "A little nonsense now and then, is relished by the wisest men" 781-788-0130 <URL:http://www.gweep.net/> <URL:http://www.megazone.org/> Hail Discordia!

Ken Hunter, Aspiring Technologies was heard to say: >need to be able to do RIP V1 or V2 (prefer V2) between usr netserver 8/16 >and cisco 2501 running 11.xx ios - anyone care to share their setup notes. >Netserver documentation is about as clear as mud. Netserver: set default off set net0 routing broadcast set net0 enabled set proxy on (optional depending on your setup) set ripv2 on save all (wait for the flash write to finish [show flash]) reboot Cicso: (2501 config) (passive-interface means don't transmit on that interface) ! router ospf 1 redistribute static subnets redistribute rip metric-type 1 subnets passive-interface Serial0 passive-interface Serial1 network 0.0.0.0 255.255.255.255 area 0.0.0.0 ! router rip ! the version directive limits to ONE version of rip ! without it, the cisco will process both v1 and v2 version 2 passive-interface Ethernet0 passive-interface Serial0 passive-interface Serial1 network xxx.xxx.xxx.xxx --Ricky

[Quoth dbaud] ] When assigning an address pool on Netserver or even Harc, what is ] the recomended pool size for a chassis with 2 PRI's? If you have IP space to spare: Maximum number of users in box, plus where you might expand to in the next year. Then, round up to the next power of two. That way, even if you're not currently announcing routes via RIP, you will be able to announce a nice big fat aggregate route if you ever decide to go that route. So, if you're at two PRI's, that's 46 potential users. 64 IP's (/26) would do good. Use the second through second-last addresses for the pool, because it's probably not wise to use the network and broadcast addresses. -- Michael Mittelstadt meek@execpc.com VP - Internet Technologies ExecPC Internet http://www.execpc.com/~meek 1-800-ExecPC-1

for some reason I have two quad modems that seem to be hung and co-incidentally my TCM isn't connecting to the chassis. is there any way that I can take the modems "off hook" or busy them out remotely? Leon (trying not to have to drive to the office but it seems inevitable)

What are people's experiences with the new code to allow V.90 on the HiPer DSP? Any major problems? Eric --- Eric J. Lorenzo Field Engineer v:650.237.1465 f:650.237.1499 Lorenzo@MediaCity.com www.ISPchannel.com

To see modem firmware type set imodem interface mod:1 at ati7 Good luck Diarmuid

We have a Total Control unit with 48 digital & analog/digital quad modems. Our NMC has only 4 meg of RAM. Does the v.90 code require 16? We have upgraded the Netserver to 16, but I do not see anything on the NMC. If 16 is required, is it just 72 pin non-parity simms? Russ Miescke Power Web Connect

Thus spake Russ Miescke >We have a Total Control unit with 48 digital & analog/digital quad modems. >Our NMC has only 4 meg of RAM. Does the v.90 code require 16? We have >upgraded the Netserver to 16, but I do not see anything on the NMC. If 16 >is required, is it just 72 pin non-parity simms? No, v.90 does not requite the NMC to be upgraded. Using the HiPer cards is what requires the NMC to get the 16 MB memory upgrade. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

On Tue, 21 Jul 1998, Goemon Ishikawa wrote: > We're having a weird problem with the new HiperARC. The NMC card > configured and came up no problem bringing up its NIC on 10bt ether. We > configured the HiperARC and it refused to bring up the NIC. The ARC would > boot, but 'sh int eth:1' would always show 'Operational Status: Down'. It > would refuse to talk to ethernet. > How are you connecting to a switch or a hub. Is this switch/hub autodetect 100b/10b ? Check the cable - make sure that you have a correct ethernet cable. > We found out that if you booted the ARC with 10bt plugged in, it would > come up 'Down', but if you plugged in 10bt _after_ the ARC was booted, it > works fine, and shows 'Operational Status: Up'. Sounds like the ARC > software has a problem auto-sensing 10/100 on boot? > The arc software will autodetect and also has a periodic function to check for the status and reset the port if there is a link problem. What switch is this attached to? krish > It's not bad hardware as we have had the ARC and NIC replaced. > > The HiperARC is running V4.0.29. > > Any ideas? > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Hi .. ver is the command you need.. cheers vosire Greg Coffey wrote: > How can I tell what firmware ver the modems in my netserver 16 are > currently running? If I telnet in to one of them, is there a command to > check this? > > Thanks, > Greg Coffey CoffeyNet 307-234-5443 > 142 S. Center St. www.coffey.com > Casper, WY 82601 > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. -- \\|// - ? (o o) +==================================oOOo=(_)=oOOo========+ | Richard Bosire rbosire@africaonline.co.ke | | AfricaOnline Ltd | | union towers, 2nd floor | | tel: 254-2-243775 | | .oooO | | http://www.africaonline.co.ke ( ) Oooo. | +===================================\ (==( )==========+ \_) ) / (_/

>-----Original Message----- >From: owner-usr-tc@lists.xmission.com >[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Robert von Bismarck >Sent: Monday, July 20, 1998 3:52 AM >To: 'usr-tc@xmission.com' >Subject: (usr-tc) MIB's for the HiperARC ? > > >Just a thought, > >I was moving through the MIB's, and found some interesting details, >among which TCS 3.1 does not seem to have a MIB for the ARC. >Is there such an thing ? > >Thanks for any pointers, hints and others opinions are welcome... Since TCM does not control the HARC, its mibs are not included with TCM.. ARC mibs are distributed with the HARC software.

On Tue, 21 Jul 1998, Goemon Ishikawa wrote: > On Mon, 20 Jul 1998, Tatai SV Krishnan wrote: > > On Tue, 21 Jul 1998, Goemon Ishikawa wrote: > > > We're having a weird problem with the new HiperARC. The NMC card > > > configured and came up no problem bringing up its NIC on 10bt ether. We > > > configured the HiperARC and it refused to bring up the NIC. The ARC would > > > boot, but 'sh int eth:1' would always show 'Operational Status: Down'. It > > > would refuse to talk to ethernet. > > How are you connecting to a switch or a hub. > > SMC Elite 3512TP hub. > > > Is this switch/hub autodetect 100b/10b ? > > It is 10mb hub only, not switch. > > > Check the cable - make sure that you have a correct ethernet cable. > > This cable is correct, it works on the NIC of the NMC card perfectly, and > on other computers. We have checked with other cables too. They also work > on NMC card fine, but not NAC. > > > > We found out that if you booted the ARC with 10bt plugged in, it would > > > come up 'Down', but if you plugged in 10bt _after_ the ARC was booted, it > > > works fine, and shows 'Operational Status: Up'. Sounds like the ARC > > > software has a problem auto-sensing 10/100 on boot? > > The arc software will autodetect and also has a periodic function to > > check for the status and reset the port if there is a link problem. > > It seems that if the NIC is plugged into ethernet on bootup, it fails. But > if you plug in ethernet _after_ bootup, it works. > > This sounds to me like it's a software bug in ARC. This is not a software bug. It looks more like the way the ethernet hub interface / communication problem. When you say that you boot Hiper arc and plug in the cable everything works, that tell me that the hub is looking for signal to send any port signals back. So now once you get the hiper arc up like this and if you power off the hub and power it on back does the link die? In my opinion it should, tells me something is wrong with the hub. In the arc software there is a reset mechanism, if the link does not come up then the ethernet port will be reset - it is same as you disconnecting the cable and inserting it on back. krish > > > What switch is this attached to? > > It is SMC 3512TP hub, not switch. Everything on the LAN is 10mb. No other > devices (cisco, computers, etc) have any problems. Only the TC HiperARC > NIC has problems. > > -Dan > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

On Tue, 21 Jul 1998, Goemon Ishikawa wrote: > On Mon, 20 Jul 1998, Mike Wronski wrote: > > >It's not bad hardware as we have had the ARC and NIC replaced. > > >The HiperARC is running V4.0.29. > > >Any ideas? > > What kind of 10/100 Hub are you using? > > We determined the problem. > > HiperNMC NIC likes SMC 3512TP hub. > HiperARC NIC does not like SMC 3512TP hub. But works with any other hub. > What is different between these two hubs? apart from cost? > No other equipment has problem with SMC 3512TP hub. Cisco, X-Terminals, > PC, Mac, Terminal Servers, work fine. HiperARC NIC does not :-( > Have not seen any problems with with smc tiger hubs, if hiper arc has a problem so should most of the ethernet devices using digital 100/10 chip... Well any way its nice to see your problem go away - but still would like to test what happens if the hub is power off during operations with the hiper arc? krish > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

On Mon, 20 Jul 1998, Robert von Bismarck wrote: >[munch] > So the point is, NT sucks on bad hardware, if you need NT, buy > computers from a known brand like HP (no I don't work for them, they jut > build great PC's) and it'll do okay. Not to drift any farther off topic, but... To be fair, Unix sucks just as bad on bad hardware. I've run into many a machine that will run Windows 95/98 seemingly fine, but will keel over dead very quickly when presented with either NT Workstation or FreeBSD. In fact, my hardware burn-in test for any machine suspected of hardware problems is to install the FreeBSD source tree on it and do a "make world" to recompile the entire operating system. (It's also a cool benchmark. :) On a P-200 or a P2-233 this takes just under 2 hours; on a P-75 it takes about 19 hours... and it's very intensive on disk, memory, and CPU all at once for the entire duration. If it survives three successive "make world"s without gcc dumping core, it's assumed that the hardware will not die. We had a Win95 machine (an IBM Aptiva) that GPFed a slight bit more than usual, but otherwise ran fine. We swapped in a drive with FreeBSD on it and did the make world test. It flunked within 10 minutes. FWIW, we don't use any name-brand machines here, save one old Dell and some very very old DEC Venturis machines that was donated... We do use name brand *components* though, like Asus and Abit motherboards, Enlight cases, parity/ECC memory... As long as you don't use bargain-basement stuff, you can do just as good or better building your own. Mike Andrews (MA12) icq 6602506 -------------- mandrews@dcr.net Senior Systems/Network Administrator --- mandrews@termfrost.org Digital Crescent, Frankfort, KY ----- http://www.termfrost.org/ "Eagles may soar, but weasels don't get sucked into jet engines." -----BEGIN GEEK CODE BLOCK----- Version: 3.1 GCS/MU d- s: a- C++ UBX++++ P++ L+ !E W+++ N++ K++ w--- O+ M+ V+++ PS+++ PE- Y+ !t !5 !X !R tv- b+ DI++ D++ e++ h++ r++ y++*@ -----END GEEK CODE BLOCK-----

Look for usr_hiper.mib. It's in one of the MIB zipfiles, I think. It definitely exists somewhere. If you can't find it, snmpwalk 1.3.6.1.4.1.429.4 and make wild guesses as to what everything is. :) Mike Andrews (MA12) icq 6602506 -------------- mandrews@dcr.net Senior Systems/Network Administrator --- mandrews@termfrost.org Digital Crescent, Frankfort, KY ----- http://www.termfrost.org/ "Eagles may soar, but weasels don't get sucked into jet engines." -----BEGIN GEEK CODE BLOCK----- Version: 3.1 GCS/MU d- s: a- C++ UBX++++ P++ L+ !E W+++ N++ K++ w--- O+ M+ V+++ PS+++ PE- Y+ !t !5 !X !R tv- b+ DI++ D++ e++ h++ r++ y++*@ -----END GEEK CODE BLOCK----- On Mon, 20 Jul 1998, Robert von Bismarck wrote: > Just a thought, > > I was moving through the MIB's, and found some interesting details, > among which TCS 3.1 does not seem to have a MIB for the ARC. > Is there such an thing ? > > Thanks for any pointers, hints and others opinions are welcome... > > Robert von Bismarck > Petrel Communications SA > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Just a thought, I was moving through the MIB's, and found some interesting details, among which TCS 3.1 does not seem to have a MIB for the ARC. Is there such an thing ? Thanks for any pointers, hints and others opinions are welcome... Robert von Bismarck Petrel Communications SA

OK, enough is enough. I have been patiently letting these messages go and deleting them, but no more. It is bad enough wading through the actually legimate messages that do not pertain to me or my configuration. I don't need these tantrums clogging up my e-mail. This is not the forum for a UNIX vs. NT spitting contest. (I am trying to be polite) So, for the last time........ DROP IT!!!!!!!!!!!! rod rvb@petrel.ch on 07/20/98 04:25:29 AM Please respond to usr-tc@lists.xmission.com cc: (bcc: Roderick S Lambes/TMG/CSC) [snip] > > BTW, I have many WindowsNT mission critical machines here running > from SQL Server to RadiusNT and DNS that haven't been rebooted > in months. These are heavily used machines built correctly and > work. This is NOT an exception as most of out customer can atest > to this as well. > This is interesting, You speak of "correctly built machines". We had some troubles with NT machines (built with discount hardware), then moved over to monsters built by HP (which I can only recommend) and it's been stable since then. Performance is still worth shit, for the same price I get about 50% more TPS on a Sparc Ultra-2 with Sybase than NT and MSSQL. Price-performance ratio is definitely in favor of UNIX, stability is par. What's left ? The GUI looks better on NT... (just kidding) Some apps only run on NT like Merchant Server...and visual interdev... So the point is, NT sucks on bad hardware, if you need NT, buy computers from a known brand like HP (no I don't work for them, they jut build great PC's) and it'll do okay. Just my 0.02$ worth Cheers, Robert von Bismarck Petrel Communications SA > -- > Dale E. Reed Jr. (daler@iea-software.com) > _________________________________________________________________ > IEA Software, Inc. | RadiusNT, Emerald, and NT FAQs > Internet Solutions for Today | http://www.iea-software.com > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

[snip] > > BTW, I have many WindowsNT mission critical machines here running > from SQL Server to RadiusNT and DNS that haven't been rebooted > in months. These are heavily used machines built correctly and > work. This is NOT an exception as most of out customer can atest > to this as well. > This is interesting, You speak of "correctly built machines". We had some troubles with NT machines (built with discount hardware), then moved over to monsters built by HP (which I can only recommend) and it's been stable since then. Performance is still worth shit, for the same price I get about 50% more TPS on a Sparc Ultra-2 with Sybase than NT and MSSQL. Price-performance ratio is definitely in favor of UNIX, stability is par. What's left ? The GUI looks better on NT... (just kidding) Some apps only run on NT like Merchant Server...and visual interdev... So the point is, NT sucks on bad hardware, if you need NT, buy computers from a known brand like HP (no I don't work for them, they jut build great PC's) and it'll do okay. Just my 0.02$ worth Cheers, Robert von Bismarck Petrel Communications SA > -- > Dale E. Reed Jr. (daler@iea-software.com) > _________________________________________________________________ > IEA Software, Inc. | RadiusNT, Emerald, and NT FAQs > Internet Solutions for Today | http://www.iea-software.com > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message.

Ricky Beam said once upon a time: >The real problem is the amount 3Com wants to support the hardware. The >Netserver is not going to get anything but serious bug fixes as they no >longer have a license for the ComOS running on it and they are unwilling >to write a new OS for it (as I see it, a fairly trivial thing.) There was talk about backporting the ARC OS to the Netserver in the early days of the ARC. I wonder what ever happened to that?

On Fri, 17 Jul 1998, Jeff Mcadams wrote: > Hrmm...I don't know...I would think a CLEC would win over Ameritech (if > available, I know not everyone has CLEC's available everywhere) in this > round rather than switching NAS equipment. (I've never been > particularly impressed with Ameritech anyway). > -- > Jeff McAdams Email: jeffm@iglou.com Several factors at work here, current negotiations preclude me from disclosing, but now that TC limitations are better understood, looks like the scales are tipped once again. ========================================================================= Jeffrey A. Lynch JORSM Internet email: jeff@jorsm.com Northwest Indiana's Full-Service Provider Voice: (219)322-2180 927 Sheffield Avenue, Dyer, IN 46311 Autoresponse: info@jorsm.com http://www.jorsm.com

On Fri, 17 Jul 1998, Curt Shambeau wrote: > > Ameritech only includes one D-channel per PRI trunk group. They > > want like $150/mo per additional D channel. The Dual T1/PRI card > > Ameritech in your area maybe. Up here in WI they don't do that. > > -------------------------------------------------------------------------- > | Curtis V. Shambeau | curt@execpc.com | http://www.execpc.com/~curt | Right, state regulatory issue. They get away with what ever the individual state regulatory commission will allow. Indiana sucks. ========================================================================= Jeffrey A. Lynch JORSM Internet email: jeff@jorsm.com Northwest Indiana's Full-Service Provider Voice: (219)322-2180 927 Sheffield Avenue, Dyer, IN 46311 Autoresponse: info@jorsm.com http://www.jorsm.com

On Mon, 20 Jul 1998, Pete Ashdown wrote: > Ricky Beam said once upon a time: > > >The real problem is the amount 3Com wants to support the hardware. The > >Netserver is not going to get anything but serious bug fixes as they no > >longer have a license for the ComOS running on it and they are unwilling > >to write a new OS for it (as I see it, a fairly trivial thing.) > > There was talk about backporting the ARC OS to the Netserver in the early > days of the ARC. I wonder what ever happened to that? That was my question a little while back, and nobody ever answered it. They obviously have it running on the 486 platform -- witness the Netserver 8/16/8I/16I Plus, or the Viper DSL. Maybe not robust in their current state, but it's at least somewhat there. In theory the packet bus code wouldn't be too hard to rip out of their other codebases (Edgeserver, NETserver, whatever). What's left? Mike Andrews (MA12) icq 6602506 -------------- mandrews@dcr.net Senior Systems/Network Administrator --- mandrews@termfrost.org Digital Crescent, Frankfort, KY ----- http://www.termfrost.org/ "Eagles may soar, but weasels don't get sucked into jet engines." -----BEGIN GEEK CODE BLOCK----- Version: 3.1 GCS/MU d- s: a- C++ UBX++++ P++ L+ !E W+++ N++ K++ w--- O+ M+ V+++ PS+++ PE- Y+ !t !5 !X !R tv- b+ DI++ D++ e++ h++ r++ y++*@ -----END GEEK CODE BLOCK-----

Where can I find a syslog utility for nt to grap the stuff from a netserver 16? Any help would be appreciated. Tony

I have a HiPer chassis with PRIs coming into HiPer DSPs in slots 14 and 15. Calling the lead phone # for the PRI in slot 15 accesses a modem in slot 14. Bell Atlantic reports that there is no problem with the 2nd PRI. As far as I can tell, there is nothing wrong with the DSP in 15, even a <List available interfaces> shows all of the modems in slot 15 up. Is there something I'm missing? Thanks, Kirk Kirk Mitchell-General Manager mitch@keyconn.net Keystone Connect http://www.keyconn.net ***** Providing quality internet services in central PA ***** ******* (814)941-5000 We unlock the world ********

-> I have a HiPer chassis with PRIs coming into HiPer DSPs in slots 14 and 15. -> Calling the lead phone # for the PRI in slot 15 accesses a modem in slot 14. -> Bell Atlantic reports that there is no problem with the 2nd PRI. As far as I -> can tell, there is nothing wrong with the DSP in 15, even a <List available -> interfaces> shows all of the modems in slot 15 up. Is there something I'm -> missing? Issue an In Service command from TCM against the PRI in slot 14. Jeff Binkley ASA Network Computing

>-----Original Message----- >From: owner-usr-tc@lists.xmission.com >[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Goemon Ishikawa >Sent: Monday, July 20, 1998 3:21 PM >To: usr-tc@lists.xmission.com >Subject: (usr-tc) Problems with HiperARC 10/100 card? > > >We're having a weird problem with the new HiperARC. The NMC card >configured and came up no problem bringing up its NIC on 10bt ether. We >configured the HiperARC and it refused to bring up the NIC. The ARC would >boot, but 'sh int eth:1' would always show 'Operational Status: Down'. It >would refuse to talk to ethernet. > >We found out that if you booted the ARC with 10bt plugged in, it would >come up 'Down', but if you plugged in 10bt _after_ the ARC was booted, it >works fine, and shows 'Operational Status: Up'. Sounds like the ARC >software has a problem auto-sensing 10/100 on boot? > >It's not bad hardware as we have had the ARC and NIC replaced. > >The HiperARC is running V4.0.29. > >Any ideas? What kind of 10/100 Hub are you using?

On Tue, 21 Jul 1998, Rob Bankoski wrote: > Could anyone help us on this problem. When we use our dial up connection to > connect to our lan, we can only ping one of our 2 main servers. We can ping > one server from the other but can only ping one once we dial into either of > our chassis. We have spent numerous hours on hold with 3COM tech support to > no avail. We haven't even heard a human voice yet. > What are you using Hiper ARc or NETServer? What is the IP address of the dialup user and Netmask? what is the route that you see in your NAS? krish > Rob Bankoski > Triangle MLS > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

We're having a weird problem with the new HiperARC. The NMC card configured and came up no problem bringing up its NIC on 10bt ether. We configured the HiperARC and it refused to bring up the NIC. The ARC would boot, but 'sh int eth:1' would always show 'Operational Status: Down'. It would refuse to talk to ethernet. We found out that if you booted the ARC with 10bt plugged in, it would come up 'Down', but if you plugged in 10bt _after_ the ARC was booted, it works fine, and shows 'Operational Status: Up'. Sounds like the ARC software has a problem auto-sensing 10/100 on boot? It's not bad hardware as we have had the ARC and NIC replaced. The HiperARC is running V4.0.29. Any ideas?

On Mon, 20 Jul 1998, Tatai SV Krishnan wrote: > On Tue, 21 Jul 1998, Goemon Ishikawa wrote: > > We're having a weird problem with the new HiperARC. The NMC card > > configured and came up no problem bringing up its NIC on 10bt ether. We > > configured the HiperARC and it refused to bring up the NIC. The ARC would > > boot, but 'sh int eth:1' would always show 'Operational Status: Down'. It > > would refuse to talk to ethernet. > How are you connecting to a switch or a hub. SMC Elite 3512TP hub. > Is this switch/hub autodetect 100b/10b ? It is 10mb hub only, not switch. > Check the cable - make sure that you have a correct ethernet cable. This cable is correct, it works on the NIC of the NMC card perfectly, and on other computers. We have checked with other cables too. They also work on NMC card fine, but not NAC. > > We found out that if you booted the ARC with 10bt plugged in, it would > > come up 'Down', but if you plugged in 10bt _after_ the ARC was booted, it > > works fine, and shows 'Operational Status: Up'. Sounds like the ARC > > software has a problem auto-sensing 10/100 on boot? > The arc software will autodetect and also has a periodic function to > check for the status and reset the port if there is a link problem. It seems that if the NIC is plugged into ethernet on bootup, it fails. But if you plug in ethernet _after_ bootup, it works. This sounds to me like it's a software bug in ARC. > What switch is this attached to? It is SMC 3512TP hub, not switch. Everything on the LAN is 10mb. No other devices (cisco, computers, etc) have any problems. Only the TC HiperARC NIC has problems. -Dan

Could anyone help us on this problem. When we use our dial up connection to connect to our lan, we can only ping one of our 2 main servers. We can ping one server from the other but can only ping one once we dial into either of our chassis. We have spent numerous hours on hold with 3COM tech support to no avail. We haven't even heard a human voice yet. Rob Bankoski Triangle MLS

On Mon, 20 Jul 1998, Mike Wronski wrote: > >It's not bad hardware as we have had the ARC and NIC replaced. > >The HiperARC is running V4.0.29. > >Any ideas? > What kind of 10/100 Hub are you using? We determined the problem. HiperNMC NIC likes SMC 3512TP hub. HiperARC NIC does not like SMC 3512TP hub. But works with any other hub. No other equipment has problem with SMC 3512TP hub. Cisco, X-Terminals, PC, Mac, Terminal Servers, work fine. HiperARC NIC does not :-(

If you really enjoy Fleetwood Mac its not so bad. Are all the devices on the same IP subnet? Can you ping other devices on the same subnets as the servers? Do both the servers have defined routes back to the chassis. What is the default gateway of the HiPer ARC or NetServer? Can you ping the ethernet interface of the HiPer ARC or NetServer and NMC when dialing in? robb@triangle-mls.com on 07/21/98 11:36:16 AM Please respond to usr-tc@lists.xmission.com cc: (bcc: Roderick S Lambes/TMG/CSC) Could anyone help us on this problem. When we use our dial up connection to connect to our lan, we can only ping one of our 2 main servers. We can ping one server from the other but can only ping one once we dial into either of our chassis. We have spent numerous hours on hold with 3COM tech support to no avail. We haven't even heard a human voice yet. Rob Bankoski Triangle MLS - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

Has anyone on this list had any experience (positive or negative) with running the v.90 hiper code on a non-ARC TC? (i.e. Netserver) I understand it's not "approved", but our customers are really screaming for it. Many thanks, -- Jesse Sipprell Technical Operations Director Evolution Communications, Inc. * Finger sysadmin@evcom.net for my PGP Public Key *

On 20 Jul 98, at 9:29, Tatai SV Krishnan <usr-tc@lists.xmission.com> wrote: > On Tue, 21 Jul 1998, Goemon Ishikawa wrote: > > > On Mon, 20 Jul 1998, Mike Wronski wrote: > > > >It's not bad hardware as we have had the ARC and NIC replaced. > > > >The HiperARC is running V4.0.29. > > > >Any ideas? > > > What kind of 10/100 Hub are you using? > > > > We determined the problem. > > > > HiperNMC NIC likes SMC 3512TP hub. > > HiperARC NIC does not like SMC 3512TP hub. But works with any other hub. > > > > No other equipment has problem with SMC 3512TP hub. Cisco, X-Terminals, > > PC, Mac, Terminal Servers, work fine. HiperARC NIC does not :-( > > Have not seen any problems with with smc tiger hubs, if hiper arc has a > problem so should most of the ethernet devices using digital 100/10 chip... > > Well any way its nice to see your problem go away - but still would like > to test what happens if the hub is power off during operations with the > hiper arc? Perfaps it has to do with timing? If hub detects dead port-link, it might partition the port for some time. ARC detects link down, resets the port. Now if ARC resets the port more often than HUB's partition-time is, link never comes up. ---------------------------------------------------------------------- Andres Kroonmaa mail: andre@online.ee Network Manager Organization: MicroLink Online Tel: 6308 909 Tallinn, Sakala 19 Pho: +372 6308 909 Estonia, EE0001 http://www.online.ee Fax: +372 6308 901 ----------------------------------------------------------------------

Had the same problem here. needed to flush the arp cache on the routers to get this to work. -----Original Message----- >If you really enjoy Fleetwood Mac its not so bad. > >Are all the devices on the same IP subnet? > >Can you ping other devices on the same subnets as the servers? > >Do both the servers have defined routes back to the chassis. > >What is the default gateway of the HiPer ARC or NetServer? > >Can you ping the ethernet interface of the HiPer ARC or NetServer and NMC >when dialing in? > > > > >robb@triangle-mls.com on 07/21/98 11:36:16 AM > >Please respond to usr-tc@lists.xmission.com > >To: usr-tc@lists.xmission.com >cc: (bcc: Roderick S Lambes/TMG/CSC) >Subject: (usr-tc) Problems pinging > > > > >Could anyone help us on this problem. When we use our dial up connection >to >connect to our lan, we can only ping one of our 2 main servers. We can >ping >one server from the other but can only ping one once we dial into either of >our chassis. We have spent numerous hours on hold with 3COM tech support >to >no avail. We haven't even heard a human voice yet. >Rob Bankoski >Triangle MLS > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > > > > > > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

I am running it on NETServer's and haven't seen any problems yet ... although some people are reporting they cannot stay online for long before getting disconnected without reason .. ______________________________________________________ Jamie Orzechowski System Administrator The Brockville Recorder and Times RipNET Internet Services division 31 Broad Street Brockville ON, Canada K6V 4T9 Tel: 613-342-3946 EXT 293 Tel: 888-509-6677 EXT 293 Fax: 613-342-8672 Pager: 613-341-0883 EMail: mhz@recorder.ca Website: http://www.recorder.ca Personal: http://www.moonchilli.com "When you choke a Smurf, what color does it turn?" ______________________________________________________ -----Original Message----- >Has anyone on this list had any experience (positive or negative) with >running the v.90 hiper code on a non-ARC TC? (i.e. Netserver) > >I understand it's not "approved", but our customers are really screaming >for it. > > >Many thanks, > >-- >Jesse Sipprell >Technical Operations Director >Evolution Communications, Inc. > >* Finger sysadmin@evcom.net for my PGP Public Key * > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Quick Recap: Bought a HiPer bundle about 2 months ago. Spent weeks with tech support to see why "list int" showed all modems down/up. Took ARC and DSPs to an old 45 Amp chassis, problem went away. Waited for new chassis, and installed it yesterday. Same problem. The T1 lines work fine if I move them to an old Dual T1 chassis. Have triple-quadruple checked line settings, as have at least half a dozen people at 3Com. Have set "chassis awareness" on and off, moved cards, pulled cards, rearranged cards, rebooted, power-cycled, and kicked. Two months is too long... What are my options? Can I even return this thing so late? Why can't anyone troubleshoot this? Blah. Charles -Who's thinking "Shouldn't *I* be getting paid something for beta testing this stuff? Isn't my time money? When's the last time it took more than two months to get a piece of equipment working?" =-----------------== | Charles Sprickman Internet Channel | | INCH System Administration Team (212)243-5200 | | spork@inch.com access@inch.com | = =----------------=

Rod are you the listowner? If not I, in fact even if you are I take exception to the inappropriatness of the NT vs Unix debate on the list. The things I read in today's digest were in my mind constructive. We run 5 racks and we are contemplating on switching to radius from tacacs the platform we are going to run it on is very critical and other peoples experiences are just what I need. I'm in agreement with you when it just turns into a Unix vs NT or any platform bashing without anything to back it up. That is useless. When it is backed up with such things as how a high quality frame for either improve performance, decrease crashing and other types of factual compares. I find that useful and will take that into account when we make a decision. So just because it isn't important to you, please don't assume it's not pertinent to any of us! Thanks, Ray Kopp Syracuse University Computing and Media Services Network Systems rjkopp@mailbox.syr.edu Syracuse, New York 13244

On Tue, 21 Jul 1998, Ray Kopp wrote: > So just because it isn't important to you, please don't assume it's not > pertinent to any of us! [Qualification - Please put on your humor hat first... soapbox mode on] Imagine if we started discussing the idea of what snacks went along well with the hold music on 3Com's support page. It could turn into a discussion of whether or not chilli really should have meat or beans. Imagine that we allow it to take up half the discussion bandwidth. People will stop reading this mailing list because they're seeing a lot of messages fly by that are not pertinent to what they're looking for. At that point, the list becomes less valuable because participation drops and noise filtering becomes more a problem than an occasional bother. While it's true that food is pertinent to all of us, and sometimes, snacking while on hold with 3Com is done, the discussion of foods really doesn't belong in this list. After all, we're professionals, aren't we? Who needs a food fight this list? I believe the same is true of Unix vs NT discussions when it becomes which is the best platform to run under. I think that it's really not an issue for this group to deal with since there are vast number of both out there and both should be supported well regardless of how we feel about NT or Unix. If we get into the "Under Solaris x.x.x running TCM x.x.x, I have the following problem" or "Under NT x.x..." and those problems don't appear in their counterparts, then we have something to discuss, but not because it's OS1 vs OS2 (no pun intended). What do we run? 6 NT's, 10 Linux boxes, many Win95's, and one MacOS. Each serves its own purposes and each does things differently than the other in different areas. This doesn't make one better than the other, only by preference, more suitable for certain tasks than the other. Which should you use? That is a discussion that I feel is beyond the scope of this list. [soapbox mode off] FYI - no I don't own the list. Kevin Benton Network Engineer SOTA Technologies, Inc. E-Mail: s1kevin@tims.net Web: http://users.sota-oh.com/~s1kevin/ Unsolicited advertisements processing fee: $50 subject to change without notice

On Tue, 21 Jul 1998, Jamie Orzechowski wrote: > I am running it on NETServer's and haven't seen any problems yet ... > although some people are reporting they cannot stay online for long before > getting disconnected without reason .. I'm seeing the same problem with our NetServers and v.90. Random disconnections with no real reason. The radius logs are reading "Lost-Carrier" for those who get disconnected randomly. About a week ago, the frequency of these drops increased to a drop every 5 minutes. I rebooted the Netserver and reset all the cards. The frequency of the drops returned to normal, about 2 per hour. Any idea of what could be causing the problems? I checked for error seconds on our channelized t1's and see none. I'm running the latest code on everything. By the way, does anyone know when the next Netserver code will be out? On the website it says "NRY" (not released yet) for the 3.1.2 series. Have any beta testers gotten their hands on it yet? I hope 3com continues to support, and update the netserver code. I know a lot of people are angry with 3com, because of problems with their software. I strongly encourage 3com to continue working on stablizing their code. The hardware is good, the design seems good, now if we can just get rid of some bugs! :-) ps. Testing v.90 hiper....so far, so good... - andy

HiPer DSP 1.2.5 code is not for use with the Total Control NETServer CARD. Please view our note where you downloaded the code. It stated "Includes v.90. For use with HiPer ARC only". It has little to do with issues with the HiPer DSP's. The NETServer code needs to be updated to support the HiPer DSP's with v.90. Once we have thoroughly tested and released NETServer 3.8.x most of your HiPer DSP to NETServer issues will go away. andy <smitha@mach3ww.com> on 07/21/98 01:23:18 PM Please respond to usr-tc@lists.xmission.com cc: (Adrian Salas/PA/3Com) On Tue, 21 Jul 1998, Jamie Orzechowski wrote: > I am running it on NETServer's and haven't seen any problems yet ... > although some people are reporting they cannot stay online for long before > getting disconnected without reason .. I'm seeing the same problem with our NetServers and v.90. Random disconnections with no real reason. The radius logs are reading "Lost-Carrier" for those who get disconnected randomly. About a week ago, the frequency of these drops increased to a drop every 5 minutes. I rebooted the Netserver and reset all the cards. The frequency of the drops returned to normal, about 2 per hour. Any idea of what could be causing the problems? I checked for error seconds on our channelized t1's and see none. I'm running the latest code on everything. By the way, does anyone know when the next Netserver code will be out? On the website it says "NRY" (not released yet) for the 3.1.2 series. Have any beta testers gotten their hands on it yet? I hope 3com continues to support, and update the netserver code. I know a lot of people are angry with 3com, because of problems with their software. I strongly encourage 3com to continue working on stablizing their code. The hardware is good, the design seems good, now if we can just get rid of some bugs! :-) ps. Testing v.90 hiper....so far, so good... - andy - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

The NMC does not require 16 MB of DRAM for v.90 on quads. If you do wish to upgrade anyway you should have 8 MB of flash as well. It's 72 pin none edo, non-parity, 70 NS ram. The flash will probably have to special ordered. "Russ Miescke" <russm@powerweb.net> on 07/19/98 08:08:59 PM Please respond to usr-tc@lists.xmission.com cc: (Adrian Salas/PA/3Com) We have a Total Control unit with 48 digital & analog/digital quad modems. Our NMC has only 4 meg of RAM. Does the v.90 code require 16? We have upgraded the Netserver to 16, but I do not see anything on the NMC. If 16 is required, is it just 72 pin non-parity simms? Russ Miescke Power Web Connect - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

I was on 3com's beta server and I noticed that there is a BUG in the HiPER DSP code 1.2.5 which says disconnections for no reason. and it's Priority 1 to be fixed in the next version ... thanks 3com ... I would think that is a fairly serious bug and wouldn;t release code when that broken ... ______________________________________________________ Jamie Orzechowski System Administrator The Brockville Recorder and Times RipNET Internet Services division 31 Broad Street Brockville ON, Canada K6V 4T9 Tel: 613-342-3946 EXT 293 Tel: 888-509-6677 EXT 293 Fax: 613-342-8672 Pager: 613-341-0883 EMail: mhz@recorder.ca Website: http://www.recorder.ca Personal: http://www.moonchilli.com "When you choke a Smurf, what color does it turn?" ______________________________________________________ -----Original Message----- >On Tue, 21 Jul 1998, Jamie Orzechowski wrote: > >> I am running it on NETServer's and haven't seen any problems yet ... >> although some people are reporting they cannot stay online for long before >> getting disconnected without reason .. > >I'm seeing the same problem with our NetServers and v.90. Random >disconnections with no real reason. The radius logs are reading >"Lost-Carrier" for those who get disconnected randomly. About a week ago, >the frequency of these drops increased to a drop every 5 minutes. I >rebooted the Netserver and reset all the cards. The frequency of the drops >returned to normal, about 2 per hour. > >Any idea of what could be causing the problems? I checked for error >seconds on our channelized t1's and see none. I'm running the latest code >on everything. > >By the way, does anyone know when the next Netserver code will be out? >On the website it says "NRY" (not released yet) for the 3.1.2 series. Have >any beta testers gotten their hands on it yet? > >I hope 3com continues to support, and update the netserver code. I know >a lot of people are angry with 3com, because of problems with their >software. I strongly encourage 3com to continue working on stablizing >their code. The hardware is good, the design seems good, now if we >can just get rid of some bugs! :-) > >ps. Testing v.90 hiper....so far, so good... > >- > andy > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

> Where can I find a syslog utility for nt to grap the stuff from a netserver 16? > > Any help would be appreciated. In my never ending searches for utilities that emulate Unix services on NT, I've encountered two versions of Syslog daemons: CLS-Syslogdaemon and SL4NT. SL4NT v0.3 - 05/06/96 is Freeware. SL4NT is Copyright (c) 1996 Franz Krainer. All Rights Reserved. You can find it on ftp.cdrom.com, or I can email it to you because it's only 32k. CLS is also freeware but it's more complicated, as it works on 3.11, 95 and NT. Generally it does the same thing as SL4NT, but it's bigger (257K). Search on ftp.cdrom.com for this too. I'm using SL4NT and it works just fine. Contact me if you need extra help with this. Bogdan Bogdan Pelinescu <bpelin@itcnet.ro> | R&D Engineer | Tel: (401) 232 2770 Institute for Computers | Networks & Communications Dept. | Fax: (401) 230 7845 Bucharest, Romania |

On Tue, 21 Jul 1998 Adrian_Salas@3com.com wrote: > HiPer DSP 1.2.5 code is not for use with the Total Control NETServer CARD. > Please view our note where you downloaded the code. I saw the note. I'm getting the random disconnects using the NetServer Card (3.7.24) with the v.90 quad modem cards (5.10.9). Not Hiper DSP. I was also informed that on the beta server? there is a listing of a bug with similar symptoms for the hiperdsp (1.2.5). I don't go to the beta site, so I haven't checked it out myself. - andy

Hi, General question to 3com guys. Looking at description of Affinity DSL chassis and cards, Cable Access solution chassis, Hiper DSP/ARC, Quad/Netserver, Wireless, EdgePro, etc. I get impression that all these cards can be used in the same chassis, and although nowhere mentioned, I can't see any reason why not at the same time in a mixed configuration. So, here's a question - can all those TC solutions be used in the same chassis at the same time? This would really give a reason to put Hiper DSP/ARC chassis to even such locations that would never need full chassis of DSP cards. Instead, you could use the same box to terminate DSL, cable and any future services. ---------------------------------------------------------------------- Andres Kroonmaa mail: andre@online.ee Network Manager Organization: MicroLink Online Tel: 6308 909 Tallinn, Sakala 19 Pho: +372 6308 909 Estonia, EE0001 http://www.online.ee Fax: +372 6308 901 ----------------------------------------------------------------------

The nmc communicates with the Hiper arc and the HDM using chassis awarness. The information the NMC sends is as follows: It communicates with each card finds out the information and tells the hiper arc or the netserver who the cards and and what type of cards they are and if they are alive or dead. If the NMC sense the cards to be bad or not active it is capable of telling the HiPer arc or any gateway ard to remove the card from teh packet bus. One other thing the NMC does is that it also checks for the clock on the chassis. If the chassis back plane clock fail then the NMC will take over. Now removing the NMC if the hiper arc sees every card and everything is fine, then take a look at the HiPer arc and see what it says for this comand show nmc if it shows that the nmc chassis awarness is enabled, then disable nmc chassis awarens, set every card in the chassis as a static configuration and then put the nmc back and see if the problem returns. If it does you have a bad NMC card. If it does not then there is something wrong with the chassis awarness that is causing the NMC to tell the HIPer arc thto disable the cards. krish \ T.S.V. Krishnan \ \ Network System Engineer \ ( : - : ) \ 3Com ............ \ ----------------------------------------------/ tkrishna@bubba.ae.usr.com ----------------------------/ http://interproc.ae.usr.com ----/ The Yadda Yadda Search - for simple anwers - http://interproc.ae.usr.com/tkb.html Any Sufficiently advanced bug is indistinguishable for a feature. - Rick Kulawiec On Wed, 22 Jul 1998, Charles Sprickman wrote: > Hi, > > This is probably annoying by now, but it will make it to the archives... > > Problem with all HDMs showing "down/up" in a "list int". Problem went > away in an old 45A chassis, still occurred with the replacement chassis. > On a whim, I booted with the NMC removed today, and guess what? "list > int" showed up/up, and it took it's first call!!! Reinserting the NMC > brought all interfaces back to "down/up". Removing NMC and rebooting was > the only way to get "up/up" again. Inserting an NMC from a random non-ARC > chassis did not cause HDMs to go to "down/up". > > So my question is, what does the NMC do that prevents the ARC from seeing > the HDMs properly? Is it a bad card or is there some weird > misconfiguration that everyone missed? > > Thanks, > > Charles > > =-----------------= = > | Charles Sprickman Internet Channel | > | INCH System Administration Team (212)243-5200 | > | spork@inch.com access@inch.com | > = =----------------= > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

On Tue, 21 Jul 1998 Adrian_Salas@3com.com wrote: > HiPer DSP 1.2.5 code is not for use with the Total Control NETServer CARD. > Please view our note where you downloaded the code. It stated "Includes > v.90. For use with HiPer ARC only". It has little to do with issues with > the HiPer DSP's. The NETServer code needs to be updated to support the > HiPer DSP's with v.90. Once we have thoroughly tested and released > NETServer 3.8.x most of your HiPer DSP to NETServer issues will go away. ok when will this code upgrade be done? John Timon: Network Administrator Execulink Internet Services timon@execulink.com Eagles may soar, but weasels don't get sucked into jet engines.

We have several customers who are attempting to connect to our total control chassis with Farallon Netopias. They are having problems bonding the second channel. The first channel comes up fine but we never see any sign of the second channel trying to be authenticated by the radius server. The second channel times out on the Netopia and it disconnects. We have a netserver and are using Merit radius 3.5.6. Has anyone else seen this or have any ideas to help us? Thanks, Bob

If this is a Hiper DSP then load the V.90 code, it seems to fix the seconds channel bonding and Auth failure issues. -Frank -----Original Message----- Cc: thughes@ice.net <thughes@ice.net> >We have several customers who are attempting to connect to our total >control chassis with Farallon Netopias. They are having problems bonding >the second channel. The first channel comes up fine but we never see any >sign of the second channel trying to be authenticated by the radius >server. The second channel times out on the Netopia and it disconnects. >We have a netserver and are using Merit radius 3.5.6. Has anyone else >seen this or have any ideas to help us? > >Thanks, >Bob > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Hi all. I just received a HiPer ARC bundle and I am having a little trouble configuring it. DSP 1.2.5 ARC 4.0.30 NMC 5.5.2 The modems answer and users can telnet via text mode with no problem. PPP does not negotiate properly because the ARC is not handing out IP addresses. I configured an IP pool... name usrtc2-ppp-pool begin 134.117.237.2 netmask 255.255.255.0 size 60 state public route aggregate I figured that since the state was PUBLIC, that PPP users would be assigned an address from that pool. Did I miss anything? Also, I connected using a RADIUS assigned IP address and PPP negotiated just fine. Problem here was that the ARC did not broadcast the route. Any help would br greatly appreciated. Colin McFadyen Carleton University Computing and Communications Services (613) 520-2600 x3721 fax: (613) 520-4448

On Thu, 23 Jul 1998, Charles Sprickman wrote: > > On Wed, 22 Jul 1998, Tatai SV Krishnan wrote: > > > Now removing the NMC if the hiper arc sees every card and everything is > > fine, then take a look at the HiPer arc and see what it says for this comand > > > > show nmc > > It was enabled... We'd turned this on and off in past troubleshooting > after setting the cards up as static (set chas slot 14 etc..). > > > > > if it shows that the nmc chassis awarness is enabled, then disable nmc > > chassis awarens, set every card in the chassis as a static configuration > > and then put the nmc back and see if the problem returns. If it does you > > have a bad NMC card. If it does not then there is something wrong with > > the chassis awarness that is causing the NMC to tell the HIPer arc thto > > disable the cards. > > I disable nmc chassis awareness again, saved all after setting the static > config, and got the same result. Since this is a new chassis, it has to > be the NMC, right? Is this a typical failure mode for the NMC? What > results would you see in a Netserver/quad setup? > OK, let me understand - You were sent a new chassis, and this new chassis does not have a NMC. You remove the NMC everything is fine, you put it in even with chassis awarness disabled you run into problems. That clearly means that the NMC has a problem. You want to send the NMC back to 3com for hardware analysis and get a new NMC in its place. The new NMC should not have this problem. The bad NMC that you have currently should be able to reproduced this problem with that NMC on any chassis. Yes you will run into AIP problem using this NMC with netserver. krish > Thanks, > > Charles > > > krish > > > > ----------------------------------------- > > \ T.S.V. Krishnan \ > > \ Network System Engineer \ ( : - : ) > > \ 3Com ............ \ > > ----------------------------------------------/ > > tkrishna@bubba.ae.usr.com > > ----------------------------/ http://interproc.ae.usr.com ----/ > > The Yadda Yadda Search - for simple anwers - http://interproc.ae.usr.com/tkb.html > > -------------------------------------------------------------------------\ > > Any Sufficiently advanced bug is indistinguishable for a feature. > > - Rick Kulawiec > > -------------------------------------------------------------------------/ > > > > On Wed, 22 Jul 1998, Charles Sprickman wrote: > > > > > Hi, > > > > > > This is probably annoying by now, but it will make it to the archives... > > > > > > Problem with all HDMs showing "down/up" in a "list int". Problem went > > > away in an old 45A chassis, still occurred with the replacement chassis. > > > On a whim, I booted with the NMC removed today, and guess what? "list > > > int" showed up/up, and it took it's first call!!! Reinserting the NMC > > > brought all interfaces back to "down/up". Removing NMC and rebooting was > > > the only way to get "up/up" again. Inserting an NMC from a random non-ARC > > > chassis did not cause HDMs to go to "down/up". > > > > > > So my question is, what does the NMC do that prevents the ARC from seeing > > > the HDMs properly? Is it a bad card or is there some weird > > > misconfiguration that everyone missed? > > > > > > Thanks, > > > > > > Charles > > > > > > =-----------------= = > > > | Charles Sprickman Internet Channel | > > > | INCH System Administration Team (212)243-5200 | > > > | spork@inch.com access@inch.com | > > > = =----------------= > > > > > > > > > - > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > with "unsubscribe usr-tc" in the body of the message. > > > For information on digests or retrieving files and old messages send > > > "help" to the same address. Do not use quotes in your message. > > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > =-----------------= = > | Charles Sprickman Internet Channel | > | INCH System Administration Team (212)243-5200 | > | spork@inch.com access@inch.com | > = =----------------= > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

come and get your cisco 2511 boards! :)) /-------------------------- signal@shreve.net -----------------------------\ | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | | Network Administrator | Perl, Linux | Web hosting, online stores, | | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | | 89 CRX DX w/MPFI, lots of |-=*:Quake:*=-| http://www.shreve.net/ | | mods/Homepage coming soon |LordSignal/SN| Quake server: 208.206.76.47 | \-------------------------- 318-222-2638 x109 -----------------------------/ ---------- Forwarded message ---------- Cc: isp-equipment@isp-equipment.com FOR SALE: Qty 60 USR V.34 Digital Modem NAC's (Upgradeable, Double Sided) $300/ea Qty 10 USR/Cisco 2511 Boards with NIC's and Cables $750/ea Qty 2 USR NetServer PRI Boards $1000/ea Qty 30 USR V.34 Modem NIC's (Analog) $50/ea Qty 6 70A DC Power Supplies (NIC/NAC) $400/ea Buyer pays shipping, terms are COD (certified funds) or Credit card -Scott --- GSTek Corporation *Kenneth Scott Bethke* Ezy.Net Corporation Sun/Networking/ISP Stuff -- BUY/SELL/TRADE -- FAX: 410-742-1381 Email:kbethke@ezy.net Voice:410-742-1610 Web:http://www.ezy.net/gstek To unsubscribe, e-mail: isp-services-unsubscribe@ispc.org For additional commands, e-mail: isp-services-help@ispc.org

Hi, This is probably annoying by now, but it will make it to the archives... Problem with all HDMs showing "down/up" in a "list int". Problem went away in an old 45A chassis, still occurred with the replacement chassis. On a whim, I booted with the NMC removed today, and guess what? "list int" showed up/up, and it took it's first call!!! Reinserting the NMC brought all interfaces back to "down/up". Removing NMC and rebooting was the only way to get "up/up" again. Inserting an NMC from a random non-ARC chassis did not cause HDMs to go to "down/up". So my question is, what does the NMC do that prevents the ARC from seeing the HDMs properly? Is it a bad card or is there some weird misconfiguration that everyone missed? Thanks, Charles =-----------------= = | Charles Sprickman Internet Channel | | INCH System Administration Team (212)243-5200 | | spork@inch.com access@inch.com | = =----------------=

Has anybody setup a MP8i in Australia using Telstras OnRamp service (Supposedly the same as ETSI). We are having lots of problems with garbage after connection. We think this is due to some type of speed missmatch in the serial interface but locking the serial port rate has not helped. Would anybody be willing to share their initialisation string with us? Thanks Jason

On Wed, 22 Jul 1998, Tatai SV Krishnan wrote: > Now removing the NMC if the hiper arc sees every card and everything is > fine, then take a look at the HiPer arc and see what it says for this comand > > show nmc It was enabled... We'd turned this on and off in past troubleshooting after setting the cards up as static (set chas slot 14 etc..). > > if it shows that the nmc chassis awarness is enabled, then disable nmc > chassis awarens, set every card in the chassis as a static configuration > and then put the nmc back and see if the problem returns. If it does you > have a bad NMC card. If it does not then there is something wrong with > the chassis awarness that is causing the NMC to tell the HIPer arc thto > disable the cards. I disable nmc chassis awareness again, saved all after setting the static config, and got the same result. Since this is a new chassis, it has to be the NMC, right? Is this a typical failure mode for the NMC? What results would you see in a Netserver/quad setup? Thanks, Charles > krish > > ----------------------------------------- > \ T.S.V. Krishnan \ > \ Network System Engineer \ ( : - : ) > \ 3Com ............ \ > ----------------------------------------------/ > tkrishna@bubba.ae.usr.com > ----------------------------/ http://interproc.ae.usr.com ----/ > The Yadda Yadda Search - for simple anwers - http://interproc.ae.usr.com/tkb.html > -------------------------------------------------------------------------\ > Any Sufficiently advanced bug is indistinguishable for a feature. > - Rick Kulawiec > -------------------------------------------------------------------------/ > > On Wed, 22 Jul 1998, Charles Sprickman wrote: > > > Hi, > > > > This is probably annoying by now, but it will make it to the archives... > > > > Problem with all HDMs showing "down/up" in a "list int". Problem went > > away in an old 45A chassis, still occurred with the replacement chassis. > > On a whim, I booted with the NMC removed today, and guess what? "list > > int" showed up/up, and it took it's first call!!! Reinserting the NMC > > brought all interfaces back to "down/up". Removing NMC and rebooting was > > the only way to get "up/up" again. Inserting an NMC from a random non-ARC > > chassis did not cause HDMs to go to "down/up". > > > > So my question is, what does the NMC do that prevents the ARC from seeing > > the HDMs properly? Is it a bad card or is there some weird > > misconfiguration that everyone missed? > > > > Thanks, > > > > Charles > > > > =-----------------= = > > | Charles Sprickman Internet Channel | > > | INCH System Administration Team (212)243-5200 | > > | spork@inch.com access@inch.com | > > = =----------------= > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > =-----------------= = | Charles Sprickman Internet Channel | | INCH System Administration Team (212)243-5200 | | spork@inch.com access@inch.com | = =----------------=

On Wed, 22 Jul 1998, Charles Sprickman wrote: > Hi, > > This is probably annoying by now, but it will make it to the archives... > > Problem with all HDMs showing "down/up" in a "list int". Problem went > away in an old 45A chassis, still occurred with the replacement chassis. > On a whim, I booted with the NMC removed today, and guess what? "list > int" showed up/up, and it took it's first call!!! Reinserting the NMC > brought all interfaces back to "down/up". Removing NMC and rebooting was > the only way to get "up/up" again. Inserting an NMC from a random non-ARC > chassis did not cause HDMs to go to "down/up". > > So my question is, what does the NMC do that prevents the ARC from seeing > the HDMs properly? Is it a bad card or is there some weird > misconfiguration that everyone missed? Your relying on NMC discovery to setup your interfaces. don't. disable nmc CHASSIS_AWARENESS then setup all your cards manually set chassis slot 1 card_type hdm_24 owner yes ports 23 type static Brian > > Thanks, > > Charles > > =-----------------= = > | Charles Sprickman Internet Channel | > | INCH System Administration Team (212)243-5200 | > | spork@inch.com access@inch.com | > = =----------------= > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > /-------------------------- signal@shreve.net -----------------------------\ | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | | Network Administrator | Perl, Linux | Web hosting, online stores, | | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | | 89 CRX DX w/MPFI, lots of |-=*:Quake:*=-| http://www.shreve.net/ | | mods/Homepage coming soon |LordSignal/SN| Quake server: 208.206.76.47 | \-------------------------- 318-222-2638 x109 -----------------------------/

On the 486 PRI/T1 card there use to be feature `CTRL D` that displayed a menu of debug options. Does the HiperDSP card have this "debug menu" or something like this? Thanks. Henry

It looks like one of our Netserver cards was used as an intermediary in a SMURF attack. It was suggested that we turn off "directed-broadcasts" on this router (the Netserver). How is this done? Thanks! John John Powell, President john@jetcity.com Jet City Online http://www.jetcity.com Business Office: 206-281-1774 Customer Service: 425-820-7006, 1-888-747-6464

Colin_McFadyen said once upon a time: >I figured that since the state was PUBLIC, that PPP users would be assigned >an address from that pool. Did I miss anything? > >Also, I connected using a RADIUS assigned IP address and PPP negotiated just >fine. Problem here was that the ARC did not broadcast the route. What IP address is being assigned when the RADIUS server doesn't send an address? If it isn't from you pool, what is it? How do you have your routing set up? Do a "show network ip".

Sorry if this is a FAQ, but I couldn't find anything on the 3Com web site. Are there any versions of the NetServer and/or HyperArc software that support Diamon/Supra's "Shotgun" protocol? The Diamond web site says: "Shotgun technology is simple for ISPs to implement at the central site because ot fully supports both the MP+ and MLPPP protocols found on the majority of central site equipment. Successful tests of Shotgun have already been completed on Ascend, Cisco, 3Com and Livingston equipment." ^^^^ Our TCS boxes use T1 rather than PRI, if that makes a difference... Dave Martin Netcetera, Inc. dpm@netcetera.com "Infinity Welcomes Careful Drivers"

No address is assigned. When the PPP session starts using a radius address, the 'PPP session....' message is displayed. Without a radius address, no PPP message is shown. The logfile shows the address as 0.0.0.0. HiPer>> sh network ip SHOW IP NETWORK ip SETTINGS: Interface: eth:1 Network Address: 134.117.xxx.xxx/B Frame Type: ETHERNET_II Status: ENABLED Reconfigure Needed: FALSE Mask: 255.255.0.0 Station: 134.117.xxx.xxx Broadcast Algorithm: IETF Max Reassembly Size: 3464 IP Routing Protocol: NONE IP RIP Routing Policies: SEND_ROUTES IP RIP Authentication Key: HiPer>> Colin McFadyen Carleton University Computing and Communications Services (613) 520-2600 x3721 fax: (613) 520-4448 > -----Original Message----- > From: Pete Ashdown [SMTP:pashdown@xmission.com] > Sent: Thursday, July 23, 1998 2:52 PM > To: usr-tc@lists.xmission.com > Subject: Re: (usr-tc) ARC IP pool and PPP route broadcast > > Colin_McFadyen said once upon a time: > > >I figured that since the state was PUBLIC, that PPP users would be > assigned > >an address from that pool. Did I miss anything? > > > >Also, I connected using a RADIUS assigned IP address and PPP negotiated > just > >fine. Problem here was that the ARC did not broadcast the route. > > What IP address is being assigned when the RADIUS server doesn't send an > address? If it isn't from you pool, what is it? > > How do you have your routing set up? Do a "show network ip". > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message.

I have been on hold with 3Com Tech Support for around 2 hours for info on t= he Diamon Shotgun=2E When I find out more info, I'll send it to all of you unless someone else can help us out? ____________________Reply Separator____________________ Author: MIME:dpm@netcetera=2Ecom Sorry if this is a FAQ, but I couldn't find anything on the 3Com web site=2E Are there any versions of the NetServer and/or HyperArc software that support Diamon/Supra's "Shotgun" protocol? The Diamond web site says: "Shotgun technology is simple for ISPs to implement at the central site because ot fully supports both the MP+ and MLPPP protocols found on the majority of central site equipment=2E Successful tests of Shotgun have already been completed on Ascend, Cisco, 3Com and Livingston equipment=2E" ^^^^ Our TCS boxes use T1 rather than PRI, if that makes a difference=2E=2E=2E Dave Martin Netcetera, Inc=2E dpm@netcetera=2Ecom "Infinity Welcomes Careful Drivers" - To unsubscribe to usr-tc, send an email to "majordomo@xmission=2Ecom" with "unsubscribe usr-tc" in the body of the message=2E For information on digests or retrieving files and old messages send "help" to the same address=2E Do not use quotes in your message=2E

: It looks like one of our Netserver cards was used as an intermediary in a : SMURF attack. It was suggested that we turn off "directed-broadcasts" on : this router (the Netserver). How is this done? I've never seen that feature implemented directly as such on the Netserver. If your border router knows about internal subnets, then you might be able to handle it there; that's more typical. If you have a non-modular Cisco with one ethernet port, you can probably accomplish this by logging into the router, enabling the priviledged EXEC mode (with `enable'), then doing something like this: configure terminal ! Go into config mode interface ethernet 0 ! Talk about the first enet interface no ip directed-broadcast ! Disable directed broadcasts on eth 0 exit ! Exit the configure mode For more information about Smurf and the similar attack, Fraggle, see http://www.quadrunner.com/~chuegen/smurf.cgi

ahhh.. what a long day. I just upgraded to TCS 3.1.1 hiperarc v. 4.0.29... now all of a sudden none of my radius routing is working.. Here is a sample of my radius file; ppunk Password ="UNIX" Framed-Address = 208.6.184.41, Framed-Netmask = 255.255.255.248, arrghhh. no change to anything but updating the code. I even tried to add; Framed-Route = "208.6.184.40/32 208.6.184.41 1" to no avail. anyone have any clues????? I can't even downgrade to the old code since I don't have it, and have never been able to get the appropriate permissions to USRs totalservice page. HELP! Scott

Ahhh. It looks as though for some reason unknown to me it is not sending the RIP packets out when we are using subnets. If I manually add a /h route however it get sent out via RIP. anyone? anyone? I do have that RIP Policy "SEND_SUBNETS" enabled too.. Scott > ahhh.. what a long day. I just upgraded to TCS 3.1.1 > hiperarc v. 4.0.29... now all of a sudden none of my > radius routing is working.. Here is a sample of my radius > file; > > ppunk Password ="UNIX" > Framed-Address = 208.6.184.41, > Framed-Netmask = 255.255.255.248, > > arrghhh. no change to anything but updating the code. I > even tried to add; > > Framed-Route = "208.6.184.40/32 208.6.184.41 1" > > to no avail. > > anyone have any clues????? > > I can't even downgrade to the old code since I don't have it, > and have never been able to get the appropriate permissions > to USRs totalservice page. > > HELP! > > Scott

On Thu, 23 Jul 1998, Scott Kreuser wrote: > ahhh.. what a long day. I just upgraded to TCS 3.1.1 > hiperarc v. 4.0.29... now all of a sudden none of my > radius routing is working.. Here is a sample of my radius > file; > > ppunk Password ="UNIX" > Framed-Address = 208.6.184.41, > Framed-Netmask = 255.255.255.248, > > arrghhh. no change to anything but updating the code. I > even tried to add; > > Framed-Route = "208.6.184.40/32 208.6.184.41 1" > > to no avail. > > anyone have any clues????? > > I can't even downgrade to the old code since I don't have it, > and have never been able to get the appropriate permissions > to USRs totalservice page. > > HELP! radius debug, radius logfile would help. check the secret's to make sure they are correct. brian > > Scott > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > /-------------------------- signal@shreve.net -----------------------------\ | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | | Network Administrator | Perl, Linux | Web hosting, online stores, | | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | | 89 CRX DX w/MPFI, lots of |-=*:Quake:*=-| http://www.shreve.net/ | | mods/Homepage coming soon |LordSignal/SN| Quake server: 208.206.76.47 | \-------------------------- 318-222-2638 x109 -----------------------------/

Set the Framed-Netmask to 255.255.255.255 Brian wrote: > > On Thu, 23 Jul 1998, Scott Kreuser wrote: > > > ahhh.. what a long day. I just upgraded to TCS 3.1.1 > > hiperarc v. 4.0.29... now all of a sudden none of my > > radius routing is working.. Here is a sample of my radius > > file; > > > > ppunk Password ="UNIX" > > Framed-Address = 208.6.184.41, > > Framed-Netmask = 255.255.255.248, > > > > arrghhh. no change to anything but updating the code. I > > even tried to add; > > > > Framed-Route = "208.6.184.40/32 208.6.184.41 1" > > > > to no avail. > > > > anyone have any clues????? > > > > I can't even downgrade to the old code since I don't have it, > > and have never been able to get the appropriate permissions > > to USRs totalservice page. > > > > HELP! > > radius debug, radius logfile would help. > > check the secret's to make sure they are correct. > > brian > > > > > Scott > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > /-------------------------- signal@shreve.net -----------------------------\ > | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | > | Network Administrator | Perl, Linux | Web hosting, online stores, | > | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | > | 89 CRX DX w/MPFI, lots of |-=*:Quake:*=-| http://www.shreve.net/ | > | mods/Homepage coming soon |LordSignal/SN| Quake server: 208.206.76.47 | > \-------------------------- 318-222-2638 x109 -----------------------------/ > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. -- ======================================================= =========== Andrew Aken - President ========= ====== GlobalEyes Communications, Inc. ====== =Southern Illinois' Fastest Connection to the Internet= ========== http://www.GlobalEyes.net ======== =======================================================

How can I disable modems on DSP (best using ARC commands) for receive connections, without force disconnections. I mean, I want to free up one board to make a code upgrade but want to wait the customers to disconnect and then disable the port until all ports are free. - Marcelo

Hmm, Tried calling out to Xmissions today and said it was a state Holiday, anyway, I've also got a USR TC Problem. We have a unit that had Dual Pri Card that went 'out of service' (TCM won't even see it any longer, nor will a PC Hooked up to the RS232 Port). So I put in some spare T1 and T1 Net Card that I had laying around. To make a long story shorter, I switched all the Modem Cards to Apprpriate T1tdm settings, and can 'connect' all the modems so they show up available. Why then when I'm looking at the (with the PC on the RS232) show as such? How do I get them to not say "call ignore" Busy Out?? (I have an Ascend Unit here with DSS service, so I'm using Span 2 of that for testing with this TC Unit) T1 Span 1 DSO/Modem Status DSO Status Modem Status Slot/Chan 1 Call-Ignore Busy-Out 2/1 2 Call-Ignore Busy-Out 2/2 3 Call-Ignore Busy-Out 2/3 etc, thru all 1st 24 Channels of T1 Span 1 Any Ideas? Also something I've been curious about (where to set). Ascend units 'require' on DSS (not required on Pri) that the phone number be entered for answering purpose on every channel. Is this related to above mentioned problem, something to do with DNIS Tables? or not required at all for a T1 Equiped TC Unit? Thanks for comments or suggestions ***** Top Net InterNet Services ***** Omaha, Nebraska Husker Heaven www.top.net (402) 291-1542 Visit Our BBS at: www.hawgwild.com

Once upon a time Brian shaped the electrons to say... >Would a DEFAULT entry of the following allow a user to set there own IP >address (vs. being forced to take what the NAS assigns you) >Framed-Protocol = "PPP", >Framed-Netmask = "255.255.255.255", >able to pick any ip they want. I had been using this for sometime, and >just noticed my netmask. Shouldn't it be 255.255.255.254? Hell no. Your netmask is correct. You're thinking of Framed-Address = 255.255.255.254 - which means "Assign one from the pool." -MZ -- <URL:mailto:megazone@megazone.org> Gweep, Discordian, Author, Engineer, me.. Join ISP/C Internet Service Providers' Consortium <URL:http://www.ispc.org/> "A little nonsense now and then, is relished by the wisest men" 781-788-0130 <URL:http://www.gweep.net/> <URL:http://www.megazone.org/> Hail Discordia!

Another question to anyone that knows - Is the Dual Pri NIC Card the same as the Dual T1 Nic? Or do the NAC's have to be move with Appropriate NIC's when moving them from one TC Unit to another? If they aren't the same, how can I tell if my Failure of the TCM to recognize the card in Slot 1 is related to the NIC or NAC Card? (I know - you all have Hiper Units - I'll be there one of these days!) ***** Top Net InterNet Services ***** Omaha, Nebraska Husker Heaven www.top.net (402) 291-1542 Visit Our BBS at: www.hawgwild.com

I've started to get a weird error in my extended RADIUS log files for our TC chassis. Does anyone know what a terminate code 9 is? ie: ( 49) Acct-Terminate-Cause = 9 NAS-Error Dave... Dave Berzins (berzins@nucleus.com) President, Nucleus Information Service Inc. 1835B 10 Avenue S.W., Calgary, Alberta, Canada, T3C 0K2 Phone: (403)209-0000 Fax: (403)541-9474 Modem: (403)541-9400 www: http://www.nucleus.com Nucleus is ... Everything Internet!

Would a DEFAULT entry of the following allow a user to set there own IP address (vs. being forced to take what the NAS assigns you) User-Service-Type = "Framed-User", Framed-Protocol = "PPP", Framed-Netmask = "255.255.255.255", Framed-MTU = "1500", Port-Limit = "2", Framed-Compression = "Van-Jacobson-TCP-IP" I want the user to be forced an IP from the NAS (dynamic) and not to be able to pick any ip they want. I had been using this for sometime, and just noticed my netmask. Shouldn't it be 255.255.255.254? Brian

At 02:48 PM 7/24/98 -0500, you wrote: > > > Another question to anyone that knows - Is the Dual Pri NIC Card the same >as the Dual T1 Nic? Or do the NAC's have to be move with Appropriate NIC's >when moving them from one TC Unit to another? > > If they aren't the same, how can I tell if my Failure of the TCM to >recognize the card in Slot 1 is related to the NIC or NAC Card? > > (I know - you all have Hiper Units - I'll be there one of these days!) > I think I answered this myself - Since the Part Number for the NIC's, regardless if you use Dual PRI or Dual T-1 card NAC's is the same, and I can access a Dual T-1 Card in Slot 1, obviously the NIC card is fine. Also didn't know that the Dual PRI Card is warranty'd for 2 years, so USR/3Com now has a box headed their direction. Still would like to know the answer to my Dual T-1 Configuration problem, and all the DSO Setting show normal, and with Modems all showing connected, the settings (and calls to unit) using the RS232 side of things show all DS0 as "call-ignore" and modems "call-busy". ***** Top Net InterNet Services ***** Omaha, Nebraska Husker Heaven www.top.net (402) 291-1542 Visit Our BBS at: www.hawgwild.com

Is there a way to disable the mppp feature on the netserver card? Is there a radius attribute to allow it for certain users or connections, that is, ISDN vs analog? Thanks in advance. | Cassandra M. Perkins | People usually get what's coming to | | Network Operations | them... unless it's been mailed. | | The Loop Internet Switch Co., LLC | -fortune |

After de upgrade of DSP code, I got the following error: SCB Country Code Error Country code invalid, please program What must be done to correct it? - Marcelo

Just a quick question on MLPPP. We can successfully connect and maintain a MLPPP connection (analog) if the two connections are on the same chasis. It will not work if the connections are on separate chasis. Can you have a MLPPP connection across chasis? How? Thanks Walt Walter N. Gnann ISLC, Manager 843.770.1000 843.770.1002 (fax) wgnann@islc.net http://www.islc.net http://www.beaufortcomputerclub.org

Are you using NETServer or HiPer aRC. HiPer arc this feature is supported in 4.1 - which currently is in beta for info on NETServer do a serarch on http://interproc.ae.usr.com search for mpip krish \ T.S.V. Krishnan \ \ Network System Engineer \ ( : - : ) \ 3Com ............ \ ----------------------------------------------/ tkrishna@bubba.ae.usr.com ----------------------------/ http://interproc.ae.usr.com ----/ The Yadda Yadda Search - for simple anwers - http://interproc.ae.usr.com/tkb.html Any Sufficiently advanced bug is indistinguishable for a feature. - Rick Kulawiec On Fri, 24 Jul 1998, Walt Gnann wrote: > Just a quick question on MLPPP. We can successfully connect and maintain a > MLPPP connection (analog) if the two connections are on the same chasis. It > will not work if the connections are on separate chasis. Can you have a > MLPPP connection across chasis? How? > > Thanks > > Walt > ----------------------------------------------------- > Walter N. Gnann > ISLC, Manager > 843.770.1000 > 843.770.1002 (fax) > wgnann@islc.net > http://www.islc.net > http://www.beaufortcomputerclub.org > ----------------------------------------------------- > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

On Fri, 24 Jul 1998, MegaZone wrote: > Once upon a time Brian shaped the electrons to say... > >Would a DEFAULT entry of the following allow a user to set there own IP > >address (vs. being forced to take what the NAS assigns you) > >Framed-Protocol = "PPP", > >Framed-Netmask = "255.255.255.255", > >able to pick any ip they want. I had been using this for sometime, and > >just noticed my netmask. Shouldn't it be 255.255.255.254? > > Hell no. Your netmask is correct. You're thinking of > Framed-Address = 255.255.255.254 - which means "Assign one from the pool." Your right :) so I just need to make sure that the default entry has something like: Framed-Address = "255.255.255.254", Framed-Netmask = "255.255.255.255" thanks > > -MZ > -- > <URL:mailto:megazone@megazone.org> Gweep, Discordian, Author, Engineer, me.. > Join ISP/C Internet Service Providers' Consortium <URL:http://www.ispc.org/> > "A little nonsense now and then, is relished by the wisest men" 781-788-0130 > <URL:http://www.gweep.net/> <URL:http://www.megazone.org/> Hail Discordia! > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > /-------------------------- signal@shreve.net -----------------------------\ | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | | Network Administrator | Perl, Linux | Web hosting, online stores, | | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | | 89 CRX DX w/MPFI, lots of |-=*:Quake:*=-| http://www.shreve.net/ | | mods/Homepage coming soon |LordSignal/SN| Quake server: 208.206.76.47 | \-------------------------- 318-222-2638 x109 -----------------------------/

Everyone, On one of our HiPerDSP's modem 12 will answer, but with a wable to the tone.. which keeps people from connecting. We have went through every setting and this modem is identical to all the other 23... Is there a way to turn 12 off and replace it w/ 24 (since we have PRI) ? Has anyone else had a "bad" modem in one of these? -Jason --- Robert J. Adams radams@siscom.net http://www.siscom.net Looking to outsource news? http://www.newshosting.com SISCOM Network Administration - President, SISCOM Inc. Phone: 888-4-SISCOM 937-222-8150 FAX: 937-222-8153

On Sat, 25 Jul 1998, Jason W wrote: > I guess since we are all on this discussion I can ask > a quick question. We are using both HiPer and Netserver > chassis, and MPPP does not work in the Netserver > chassis. We have configured Radius to allow multiple On the NETServer both Multi-link PPP and MPIP ( multilink ppp ovr ip ) does work. On the NETServer there is only one switch for MPPP that is set mp on. krish > logins, and I have set MP on in the netserver, still no go. > Users will connect with the first analog modem and the > second will not connect. The HiPer arc works fine. Are > there any other variables to look at on the Netserver? > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Jason Watkins I-Land Support & NOC Tech > jwatkins@iland.net http://www.iland.net > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > -----Original Message----- > From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com> > To: Walt Gnann <wgnann@islc.net> > Cc: TC List <usr-tc@lists.xmission.com> > Date: Saturday, July 25, 1998 7:45 AM > Subject: Re: (usr-tc) MLPPP > > > >Are you using NETServer or HiPer aRC. > > > >HiPer arc this feature is supported in 4.1 - which currently is in beta > >for info on NETServer do a serarch on http://interproc.ae.usr.com > > > >search for mpip > > > >krish > > > >----------------------------------------- > > \ T.S.V. Krishnan \ > > \ Network System Engineer \ ( : - : ) > > \ 3Com ............ \ > > ----------------------------------------------/ > >tkrishna@bubba.ae.usr.com > >----------------------------/ http://interproc.ae.usr.com ----/ > >The Yadda Yadda Search - for simple anwers - > http://interproc.ae.usr.com/tkb.html > >-------------------------------------------------------------------------\ > > Any Sufficiently advanced bug is indistinguishable for a feature. > > - Rick Kulawiec > >-------------------------------------------------------------------------/ > > > >On Fri, 24 Jul 1998, Walt Gnann wrote: > > > >> Just a quick question on MLPPP. We can successfully connect and maintain > a > >> MLPPP connection (analog) if the two connections are on the same chasis. > It > >> will not work if the connections are on separate chasis. Can you have a > >> MLPPP connection across chasis? How? > >> > >> Thanks > >> > >> Walt > >> ----------------------------------------------------- > >> Walter N. Gnann > >> ISLC, Manager > >> 843.770.1000 > >> 843.770.1002 (fax) > >> wgnann@islc.net > >> http://www.islc.net > >> http://www.beaufortcomputerclub.org > >> ----------------------------------------------------- > >> > >> > >> > >> - > >> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > >> with "unsubscribe usr-tc" in the body of the message. > >> For information on digests or retrieving files and old messages send > >> "help" to the same address. Do not use quotes in your message. > >> > > > >- > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

On Sat, 25 Jul 1998, Mark R. Lindsey wrote: > Does USR's MLPPP implementation work with Linux' serial load balancing? > > Linux Serial load balancing is load balancing based on some high water mark over serial lines. In NETserver as well as the HiPer arc, when you start ppp two variable are taken into consideration for MLPPP. The first one is the username and the second one is multilink end point id. So to answer your question - yes If the second call is made and if it has the same username and if the multilink end point id match then you will have a MLPPP connections. krish > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Does anyone have the cables that will go from a PM25 to the USR MP/8's with RJ45 connectors? I need to get two sets of them as soon as yesterday :) Jim

Thus spake Walt Gnann >Just a quick question on MLPPP. We can successfully connect and maintain a >MLPPP connection (analog) if the two connections are on the same chasis. It >will not work if the connections are on separate chasis. Can you have a >MLPPP connection across chasis? How? On, the netservers, yes, on the HARC's, not yet. You need to use MPIP to control the bundling of channels between different systems/chassis'. It mostly works anyway...not the most reliable protocol I've seen. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Does USR's MLPPP implementation work with Linux' serial load balancing?

I guess since we are all on this discussion I can ask a quick question. We are using both HiPer and Netserver chassis, and MPPP does not work in the Netserver chassis. We have configured Radius to allow multiple logins, and I have set MP on in the netserver, still no go. Users will connect with the first analog modem and the second will not connect. The HiPer arc works fine. Are there any other variables to look at on the Netserver? =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Jason Watkins I-Land Support & NOC Tech jwatkins@iland.net http://www.iland.net =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= -----Original Message----- Cc: TC List <usr-tc@lists.xmission.com> >Are you using NETServer or HiPer aRC. > >HiPer arc this feature is supported in 4.1 - which currently is in beta >for info on NETServer do a serarch on http://interproc.ae.usr.com > >search for mpip > >krish > >----------------------------------------- > \ T.S.V. Krishnan \ > \ Network System Engineer \ ( : - : ) > \ 3Com ............ \ > ----------------------------------------------/ >tkrishna@bubba.ae.usr.com >----------------------------/ http://interproc.ae.usr.com ----/ >The Yadda Yadda Search - for simple anwers - http://interproc.ae.usr.com/tkb.html >-------------------------------------------------------------------------\ > Any Sufficiently advanced bug is indistinguishable for a feature. > - Rick Kulawiec >-------------------------------------------------------------------------/ > >On Fri, 24 Jul 1998, Walt Gnann wrote: > >> Just a quick question on MLPPP. We can successfully connect and maintain a >> MLPPP connection (analog) if the two connections are on the same chasis. It >> will not work if the connections are on separate chasis. Can you have a >> MLPPP connection across chasis? How? >> >> Thanks >> >> Walt >> ----------------------------------------------------- >> Walter N. Gnann >> ISLC, Manager >> 843.770.1000 >> 843.770.1002 (fax) >> wgnann@islc.net >> http://www.islc.net >> http://www.beaufortcomputerclub.org >> ----------------------------------------------------- >> >> >> >> - >> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" >> with "unsubscribe usr-tc" in the body of the message. >> For information on digests or retrieving files and old messages send >> "help" to the same address. Do not use quotes in your message. >> > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

On 24 Jul 98, at 17:27, Jim Logan <usr-tc@lists.xmission.com> wrote: > At 02:48 PM 7/24/98 -0500, you wrote: > > > > > > Another question to anyone that knows - Is the Dual Pri NIC Card the same > >as the Dual T1 Nic? Or do the NAC's have to be move with Appropriate NIC's > >when moving them from one TC Unit to another? > > > > If they aren't the same, how can I tell if my Failure of the TCM to > >recognize the card in Slot 1 is related to the NIC or NAC Card? > > > > (I know - you all have Hiper Units - I'll be there one of these days!) > > > > I think I answered this myself - Since the Part Number for the NIC's, > regardless if you use Dual PRI or Dual T-1 card NAC's is the same, and I > can access a Dual T-1 Card in Slot 1, obviously the NIC card is fine. Also > didn't know that the Dual PRI Card is warranty'd for 2 years, so USR/3Com > now has a box headed their direction. Still would like to know the answer > to my Dual T-1 Configuration problem, and all the DSO Setting show normal, > and with Modems all showing connected, the settings (and calls to unit) > using the RS232 side of things show all DS0 as "call-ignore" and modems > "call-busy". Although i don't have T1's, just few thoughts: 1) In modem config (TCM), DTE Interface Settings, there are items "DTE Interface slot" and "Busy Out", check these. 2) for T1 Trunk, there is setting of "Idle byte pattern", this might cause troubles. (It must match all - modems, T1, and Telco) 3) make sure that Netserver has modems activated, try: 1. set modem Sx-Sy inactive 2. reset Sx-Sy 3. set modem Sx-Sy active 4. reset Sx-Sy 4) Hardware reset modems, 5) check for chassis clocks. ... ---------------------------------------------------------------------- Andres Kroonmaa mail: andre@online.ee Network Manager Organization: MicroLink Online Tel: 6308 909 Tallinn, Sakala 19 Pho: +372 6308 909 Estonia, EE0001 http://www.online.ee Fax: +372 6308 901 ----------------------------------------------------------------------

At 02:13 PM 7/25/98 +0300, you wrote: >On 24 Jul 98, at 17:27, Jim Logan <usr-tc@lists.xmission.com> wrote: > >> At 02:48 PM 7/24/98 -0500, you wrote: >> > Thanks for the assist... > Although i don't have T1's, just few thoughts: > 1) In modem config (TCM), DTE Interface Settings, there are items > "DTE Interface slot" and "Busy Out", check these. DTE Interface Source says "nic" Only other choice is 'packet bus' ours are set for nic Busy Out is set for 'ext clock 1' other choice is just plain 'busy out' > 2) for T1 Trunk, there is setting of "Idle byte pattern", this might > cause troubles. (It must match all - modems, T1, and Telco) Not sure where this Idle Byte Pattern is? Lines are set Idle Byte Pattern 254 on the 2 T-1 Spans inthe configuration of the DS Trunk Settings. Where is this settable on modems, etc? > 3) make sure that Netserver has modems activated, try: > 1. set modem Sx-Sy inactive > 2. reset Sx-Sy > 3. set modem Sx-Sy active > 4. reset Sx-Sy > 4) Hardware reset modems, Tried all the resets after 1st saving to NVRam on all modems - Hardware and soft resets > 5) check for chassis clocks. This is the funny part - TCM Reports on T1 Tests, that TDM Bus Timing Souce Test Pass, yet still using TCM, the T1 Programmed setings show Internal Timing Source - Not allowed, TDM Bus Timing Source - Not allowed, and lastly, T1 Idle Disconnect Pattern - 1 (is this same as Byte pattern 254 above??). Tried to go by USR.3Com to get a Install manual for configuration for Dual T1 Card, all I could find is the Book on how to Plug the Nic/Nac in... Nothing much about the settings at all of any significance relative to the manual I have for DualPri Nac Card... ***** Top Net InterNet Services ***** Omaha, Nebraska Husker Heaven www.top.net (402) 291-1542 Visit Our BBS at: www.hawgwild.com

On Sat, 25 Jul 1998, Jim Logan wrote: > At 02:13 PM 7/25/98 +0300, you wrote: > >On 24 Jul 98, at 17:27, Jim Logan <usr-tc@lists.xmission.com> wrote: > > > >> At 02:48 PM 7/24/98 -0500, you wrote: > >> > > > Thanks for the assist... > > > Although i don't have T1's, just few thoughts: > > 1) In modem config (TCM), DTE Interface Settings, there are items > > "DTE Interface slot" and "Busy Out", check these. > > DTE Interface Source says "nic" Only other choice is 'packet bus' ours > are set for nic > Busy Out is set for 'ext clock 1' other choice is just plain 'busy out' nic is for analog lines, it should be packetbus for t1's/pri's > > > 2) for T1 Trunk, there is setting of "Idle byte pattern", this might > > cause troubles. (It must match all - modems, T1, and Telco) > Not sure where this Idle Byte Pattern is? Lines are set Idle Byte > Pattern 254 on the 2 T-1 Spans inthe configuration of the DS Trunk > Settings. Where is this settable on modems, etc? > > > 3) make sure that Netserver has modems activated, try: > > 1. set modem Sx-Sy inactive > > 2. reset Sx-Sy > > 3. set modem Sx-Sy active > > 4. reset Sx-Sy > > 4) Hardware reset modems, > > Tried all the resets after 1st saving to NVRam on all modems - Hardware > and soft resets > > > 5) check for chassis clocks. > > This is the funny part - TCM Reports on T1 Tests, that TDM Bus Timing > Souce Test Pass, yet still using TCM, the T1 Programmed setings show > Internal Timing Source - Not allowed, TDM Bus Timing Source - Not allowed, > and lastly, T1 Idle Disconnect Pattern - 1 (is this same as Byte pattern > 254 above??). > > Tried to go by USR.3Com to get a Install manual for configuration for Dual > T1 Card, all I could find is the Book on how to Plug the Nic/Nac in... > Nothing much about the settings at all of any significance relative to the > manual I have for DualPri Nac Card... > > > ***** Top Net InterNet Services ***** > Omaha, Nebraska Husker Heaven > www.top.net (402) 291-1542 > Visit Our BBS at: www.hawgwild.com > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > /-------------------------- signal@shreve.net -----------------------------\ | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | | Network Administrator | Perl, Linux | Web hosting, online stores, | | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | | 89 CRX DX w/MPFI, lots of |-=*:Quake:*=-| http://www.shreve.net/ | | mods/Homepage coming soon |LordSignal/SN| Quake server: 208.206.76.47 | \-------------------------- 318-222-2638 x109 -----------------------------/

Dear List, Can anyone kindly shed some light on this. I have a trunk T-1 when connected to a dual T-1, Quad modems and netserver bundle, I get X2 and V.90, 56K. When I move the T-1 to a DSP on a hyper bundle chassis, only V.34, 33.6bps. The client end is a Courier Imodem with ISDN connection. Liping Chen -- Netsol Internet Service

At 03:54 PM 7/25/98 -0500, you wrote: >On Sat, 25 Jul 1998, Jim Logan wrote: > >> At 02:13 PM 7/25/98 +0300, you wrote: >> >On 24 Jul 98, at 17:27, Jim Logan <usr-tc@lists.xmission.com> wrote: >> > >> >> At 02:48 PM 7/24/98 -0500, you wrote: >> >> > >> >> Thanks for the assist... >> >> > Although i don't have T1's, just few thoughts: >> > 1) In modem config (TCM), DTE Interface Settings, there are items >> > "DTE Interface slot" and "Busy Out", check these. >> >> DTE Interface Source says "nic" Only other choice is 'packet bus' ours >> are set for nic >> Busy Out is set for 'ext clock 1' other choice is just plain 'busy out' > >nic is for analog lines, it should be packetbus for t1's/pri's And each time I might try to change to packetbus, it toggles, "set" , save to NVRam, Go back and look on the modem card DTE Settings - It's back to NIC as the selection, DTE Interface Slot 16 on next line down. ***** Top Net InterNet Services ***** Omaha, Nebraska Husker Heaven www.top.net (402) 291-1542 Visit Our BBS at: www.hawgwild.com

Tatai SV Krishnan was heard to say: >On Sat, 25 Jul 1998, Mark R. Lindsey wrote: >> Does USR's MLPPP implementation work with Linux' serial load balancing? >> >Linux Serial load balancing is load balancing based on some high water >mark over serial lines. In NETserver as well as the HiPer arc, when you >start ppp two variable are taken into consideration for MLPPP. The first >one is the username and the second one is multilink end point id. So to >answer your question - yes If the second call is made and if it has the >same username and if the multilink end point id match then you will have >a MLPPP connections. Umm, the simple answer is no. There should be a way to get EQL to work for the Netserver as I've heard reports that EQL works for portmasters which the Netserver OS is based on. As far as the above statements... EQL builds its "bundle" ahead of pppd. So, unless pppd understands this and can issue MLPPP setup info, then you will not be able to bond channels, i.e. if MP is not part of the initial linkup protocols, then MLPPP will not work. EQL is a character based load balancing. MLPPP is a packet based load balancing. (I think you can set EQL for n*character blocks, but it's still a fixed byte size.) --Ricky

I've asked if anyone uses the TC rack for cable modems and usually get one or two responses... Is anyone having client diconnect problems with CARCs loaded with firmware 1.3.6? Problems with client v1.76? Get in touch if you are or are not. I'd love to discuss this. I'm pursuing this with 3Com's R&D, but it would be great to know if anyone is experiencing. Eric --- Eric J. Lorenzo Field Engineer v:650.237.1465 f:650.237.1499 Lorenzo@MediaCity.com www.ISPchannel.com

On Fri, 24 Jul 1998, Marcelo Souza wrote: After RTFM a could fix this. No reply needed! Thanks! - Marcelo | After de upgrade of DSP code, I got the following error: | |SCB Country Code Error |Country code invalid, please program | | What must be done to correct it? | | |- Marcelo | | |- | To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" | with "unsubscribe usr-tc" in the body of the message. | For information on digests or retrieving files and old messages send | "help" to the same address. Do not use quotes in your message. | - Marcelo

In case of the arc the command is set chass slot "modem slot" owner "yes/no" krish \ T.S.V. Krishnan \ \ Network System Engineer \ ( : - : ) \ 3Com ............ \ ----------------------------------------------/ tkrishna@bubba.ae.usr.com ----------------------------/ http://interproc.ae.usr.com ----/ The Yadda Yadda Search - for simple anwers - http://interproc.ae.usr.com/tkb.html Any Sufficiently advanced bug is indistinguishable for a feature. - Rick Kulawiec On Sat, 25 Jul 1998, Jeff Mcadams wrote: > Thus spake Jim Logan > > And each time I might try to change to packetbus, it toggles, "set" , save > >to NVRam, Go back and look on the modem card DTE Settings - It's back to > >NIC as the selection, DTE Interface Slot 16 on next line down. > > You're trying to set DTE source to packetbus? (Sorry, just picked up on > this thread) Don't try to do it from the modem, it won't work. Go into > the Netserver (don't know the commands for the ARC) and say "set modem > s5-s52 active" (this is just an example, set's quad modem cards in slots > 2-13 active). Then, save all, reset all. Then when you look at DTE > settings on the modem, it should say packetbus. > -- > Jeff McAdams Email: jeffm@iglou.com > Head Network Administrator Voice: (502) 966-3848 > IgLou Internet Services (800) 436-4456 > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Has anyone heard anything about whether 3Com is going to port TCM to Solaris 2.6? Does anyone know what the hold up is? Surely this is a trivial task for those that wrote the program. What do you all think of a JAVA based TCM, that way it wont be so damn platform dependant. JAVA JAVA JAVA!! Brian /-------------------------- signal@shreve.net -----------------------------\ | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | | Network Administrator | Perl, Linux | Web hosting, online stores, | | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | | 89 CRX DX w/MPFI, lots of |-=*:Quake:*=-| http://www.shreve.net/ | | mods/Homepage coming soon |LordSignal/SN| Quake server: 208.206.76.47 | \-------------------------- 318-222-2638 x109 -----------------------------/

Thus spake Jim Logan > And each time I might try to change to packetbus, it toggles, "set" , save >to NVRam, Go back and look on the modem card DTE Settings - It's back to >NIC as the selection, DTE Interface Slot 16 on next line down. You're trying to set DTE source to packetbus? (Sorry, just picked up on this thread) Don't try to do it from the modem, it won't work. Go into the Netserver (don't know the commands for the ARC) and say "set modem s5-s52 active" (this is just an example, set's quad modem cards in slots 2-13 active). Then, save all, reset all. Then when you look at DTE settings on the modem, it should say packetbus. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

We've upgraded several of our HiPer's the the V.90 code, and they're working great... for x2/v90 customers. However they appear to really _BITE_ for folks using v.34. Most of them get really shoddy connection speeds (we've personally seen as low as 9600bd) and get booted randomly with 'lost carrier'. Has anyone else seen this? USR is there is fix for this? -- GigaNews.Com The Spot for News http://www.giganews.com Making UseNet a Global Priority

On Sat, 25 Jul 1998, Brett Hawn wrote: > We've upgraded several of our HiPer's the the V.90 code, and they're working > great... for x2/v90 customers. However they appear to really _BITE_ for > folks using v.34. Most of them get really shoddy connection speeds (we've > personally seen as low as 9600bd) and get booted randomly with 'lost > carrier'. Has anyone else seen this? USR is there is fix for this? Me, and several others are seeing "random" lost-carrier disconnects with HiperDSP v.90 code with the HiperArc, AND with the v.90 code for the quads working with the netserver card. I've been told there are "no current issues (bugs) with the v.90 code". So who knows.... it could be my fault (eg. some telco setting not configured right), or it could be a BUG. :( I'm thinking that if it was a bug it would have at least been discovered and fixed by now in the quad's.... Has anyone been able to run v.90 successfully with the netserver and quad's? or with the hiperDSP/hiperarc? You might want to check your radius log's and see just how many lost carrier's you are getting a day.... I didn't notice this problem right away because for us its been completely random. Because of that not many users complained right away.... I'm considering downgrading to older code that just supports X2 and seeing if that is somewhat stable....I tried turning off v.90 in my current code but it didn't help. Obviously I won't be happy if I have to downgrade. Let's hope I'm just missing a small telco setting or soemthing. - andy

Heh. I've got at least some of its functionality reimplemented in Perl; never quite got around to finishing it though. What I've got is at http://www.dcr.net/~mandrews/usrtoys if anyone cares. It's not Java, but it's not really wired to one platform either... Mike Andrews (MA12) icq 6602506 -------------- mandrews@dcr.net Senior Systems/Network Administrator --- mandrews@termfrost.org Digital Crescent, Frankfort, KY ----- http://www.termfrost.org/ "If Barbie is so popular, why do you have to buy her friends?..." On Sat, 25 Jul 1998, Brian wrote: > Has anyone heard anything about whether 3Com is going to port TCM to > Solaris 2.6? Does anyone know what the hold up is? Surely this is a > trivial task for those that wrote the program. > > What do you all think of a JAVA based TCM, that way it wont be so damn > platform dependant. > > JAVA JAVA JAVA!! > > Brian

On Sun, 26 Jul 1998, andy wrote: > On Sat, 25 Jul 1998, Brett Hawn wrote: > > > We've upgraded several of our HiPer's the the V.90 code, and they're working > > great... for x2/v90 customers. However they appear to really _BITE_ for > > folks using v.34. Most of them get really shoddy connection speeds (we've > > personally seen as low as 9600bd) and get booted randomly with 'lost > > carrier'. Has anyone else seen this? USR is there is fix for this? > > Me, and several others are seeing "random" lost-carrier disconnects with > HiperDSP v.90 code with the HiperArc, AND with the v.90 code for the quads > working with the netserver card. I've been told there are "no current > issues (bugs) with the v.90 code". So who knows.... it could be my fault I don't believe that for a second, at least for the quads. We very definitely have a major issue with the Quad v.90 code, and it's starting to cost us customers. Quite a few people with Rockwell 33.6K modems can't reliably connect unless they manually step down to 31200 or lower (using AT+MS=11,1,300,31200 in their init strings). I've even got one guy with a Sportster having the same problem. With the older Quad code this was not a problem. With the non-v.90 DSP code this was not a problem. (Don't know about the v.90 DSP code; we don't have any of the afflicted client modems in-house and I haven't had the opportunity to call anyone to test.) I verified this by downgrading, but then all the v.90 users complained even louder than the 28.8K Rockwell people so I had to put it back. Just can't make everyone happy with this code... We don't seem to have a chronic disconnect problem though... a few people here and there. I haven't done any detailed log analysis though. While I'm at it, other annoying bugs I've found in everything: 1) The ARC has no apparent way to get the idle time of a session like the NETserver does. 2) The DSP's don't record the v.34 frequency probe information -- the SNMP objects mdmCsFreqProbeData and mdmCsLevelProbeData always return 0. We use this to let users check the condition of their line (to see if a v.90/x2 modem is usable on their line)... and it doesn't work on the HDM's. 3) There's a weird "off-by-one" error in some of the DSP SNMP trap settings. If you try to set mdmTeConnAttemptFailure or mdmTeNoLoopCurrent to 3 on a DSP card, it will work on all BUT the rightmost card. It will appear to set, but if you then re-read the value two seconds later, it will have reverted to 2 on the rightmost card. i.e. put 3 DSP's in a chassis, in slots 1 to 3. The setting will stick on cards 1 and 2, but not on 3. Plug a 4th in, and card 3 will start to stick but card 4 won't. One last thing... Is Quake 2 even more sensitive to UDP latency than Quake 1 is? We have one guy who says that he's getting unusable lag on our NETservers, but not on our ARC's, and not on any of our competitors (who all use Ascend or Livingston; maybe all Ascend now)... Unfortunately moving completely to ARCs isn't really an option for us right now (we need memory upgrades for our NMC's, not to mention MPIP)... and we don't have a separate number for our ARCs as Bellsouth didn't think they could make their DMS100 do that. (I'll ask them again.) OK, enough ranting for tonight... Mike Andrews (MA12) icq 6602506 -------------- mandrews@dcr.net Senior Systems/Network Administrator --- mandrews@termfrost.org Digital Crescent, Frankfort, KY ----- http://www.termfrost.org/ "If Barbie is so popular, why do you have to buy her friends?..." -----BEGIN GEEK CODE BLOCK----- Version: 3.1 GCS/MU d- s: a- C++ UBX++++ P++ L+ !E W+++ N++ K++ w--- O+ M+ V+++ PS+++ PE- Y+ !t !5 !X !R tv- b+ DI++ D++ e++ h++ r++ y++*@ -----END GEEK CODE BLOCK-----

At 08:55 PM 7/25/98 -0500, you wrote: >In case of the arc the command is > >set chass slot "modem slot" owner "yes/no" > >krish > Don't have Arc Cards (Must be Hyper stuff) as we haven't progessed that far yet. Just a Unit that was Dual PRI, PRI Card is on it's way back to USR since it was under warranty. Had a spare USR TC here with Dual T1 rather than PRI and was trying to get it set up on a line that we do have 2 DSS CT-1 Circuits on... The unit Syncs up fine to the line, just this DNIS stuff, or whatever, is driving me crazy. Ascend Units you have specify the dial-in number on each of the modems for T1 service (Vs PRI you never have to show any dial-in number)... The USR TC shows all modems in normal state, hooked up to TDM Bus fine, but in looking via RS232 Port all show "call-ignore" and "busy-out" on the modems... They are all Connected fine via TCM Screens, so I'm wondering why these modems always show "call-ignore", etc.. There is no where in TCM that I can even see that same screen scenario.. ***** Top Net InterNet Services ***** Omaha, Nebraska Husker Heaven www.top.net (402) 291-1542 Visit Our BBS at: www.hawgwild.com

: (Don't know about the v.90 DSP code; we don't have any of the : afflicted client modems in-house and I haven't had the opportunity to : call anyone to test.) There's an interesting statement; here's a thought: keep some good modems in house, and when you're having a chronic weird problem, offer to trade one of your modems for the one having trouble. Voila: you have test equipment and one happier customer. Bad idea?

On Sun, 26 Jul 1998, Mark R. Lindsey wrote: > : (Don't know about the v.90 DSP code; we don't have any of the > : afflicted client modems in-house and I haven't had the opportunity to > : call anyone to test.) > > There's an interesting statement; here's a thought: keep some good > modems in house, and when you're having a chronic weird problem, offer > to trade one of your modems for the one having trouble. Voila: you have > test equipment and one happier customer. > > > Bad idea? Only if you trade, say, your Courier for their LT Winmodem, and your definition of "trade" includes the word "free". That could get a bit financially lopsided. :) Still, not a bad idea. Maybe we should stockpile some Sportsters. We occasionally do house calls, and for the *really* tough cases, I haul an old decrepit 486 subnotebook with a Megahertz v.90 in it, and plug it into their line. That's pretty much how I discovered the aforementioned bug. User had some no-name 33.6K modem. It started to connect, then at the end of the handshake, just stopped and went to a steady high-pitched tone. Every 5th or 6th try it would get it, but most of the time it wouldn't. My laptop modem got a solid 46K connect every time, whether x2 or v.90 (tried both). I even stepped my modem back to v.34, and it was still solid. I busied out all the quads, and his modem started connecting perfectly when it was hitting only DSP's. (This was 2 months ago, before v.90 was available for DSP's.) For the week or so that I had downgraded the quads to non-v.90 code, the users with these types of modem problems said that things had cleared up. Mike Andrews (MA12) icq 6602506 -------------- mandrews@dcr.net Senior Systems/Network Administrator --- mandrews@termfrost.org Digital Crescent, Frankfort, KY ----- http://www.termfrost.org/ "If Barbie is so popular, why do you have to buy her friends?..." -----BEGIN GEEK CODE BLOCK----- Version: 3.1 GCS/MU d- s: a- C++ UBX++++ P++ L+ !E W+++ N++ K++ w--- O+ M+ V+++ PS+++ PE- Y+ !t !5 !X !R tv- b+ DI++ D++ e++ h++ r++ y++*@ -----END GEEK CODE BLOCK-----

While we're on v.90 problems, another situation that renders the connection useless is using v.90 (in our case a new Courier with the latest v.90 code dialing into a quad) through an SLC. Our office lines are delivered through these things, and v.90 is unusable. Connects fine, but the number of CRCs makes the data go at about 100 Bytes/sec. Turn off v.90, and all is well. X2 tops out at the high 30's, and v.34 at 26,400. And for the record, we've been seeing many of the same problems everyone else is reporting for months. It's cost us a number of subscribers... We have an alternate dialup that terminates in 33.6 Couriers on an Annex, but that just doesn't cut it for some people... Charles On Sun, 26 Jul 1998, Mike Andrews wrote: > Date: Sun, 26 Jul 1998 14:21:10 -0400 (EDT) > From: Mike Andrews <mandrews@termfrost.org> > Reply-To: usr-tc@lists.xmission.com > To: usr-tc@lists.xmission.com > Subject: Re: (usr-tc) ``Afflicted clients'' > > On Sun, 26 Jul 1998, Mark R. Lindsey wrote: > > > : (Don't know about the v.90 DSP code; we don't have any of the > > : afflicted client modems in-house and I haven't had the opportunity to > > : call anyone to test.) > > > > There's an interesting statement; here's a thought: keep some good > > modems in house, and when you're having a chronic weird problem, offer > > to trade one of your modems for the one having trouble. Voila: you have > > test equipment and one happier customer. > > > > > > Bad idea? > > Only if you trade, say, your Courier for their LT Winmodem, and your > definition of "trade" includes the word "free". That could get a bit > financially lopsided. :) > > Still, not a bad idea. Maybe we should stockpile some Sportsters. > > We occasionally do house calls, and for the *really* tough cases, I haul > an old decrepit 486 subnotebook with a Megahertz v.90 in it, and plug it > into their line. That's pretty much how I discovered the aforementioned > bug. User had some no-name 33.6K modem. It started to connect, then at > the end of the handshake, just stopped and went to a steady high-pitched > tone. Every 5th or 6th try it would get it, but most of the time it > wouldn't. My laptop modem got a solid 46K connect every time, whether x2 > or v.90 (tried both). I even stepped my modem back to v.34, and it was > still solid. I busied out all the quads, and his modem started connecting > perfectly when it was hitting only DSP's. (This was 2 months ago, before > v.90 was available for DSP's.) For the week or so that I had downgraded > the quads to non-v.90 code, the users with these types of modem problems > said that things had cleared up. > > > Mike Andrews (MA12) icq 6602506 -------------- mandrews@dcr.net > Senior Systems/Network Administrator --- mandrews@termfrost.org > Digital Crescent, Frankfort, KY ----- http://www.termfrost.org/ > "If Barbie is so popular, why do you have to buy her friends?..." > > -----BEGIN GEEK CODE BLOCK----- > Version: 3.1 > GCS/MU d- s: a- C++ UBX++++ P++ L+ !E W+++ N++ K++ w--- O+ M+ V+++ PS+++ > PE- Y+ !t !5 !X !R tv- b+ DI++ D++ e++ h++ r++ y++*@ > -----END GEEK CODE BLOCK----- > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > =-----------------= = | Charles Sprickman Internet Channel | | INCH System Administration Team (212)243-5200 | | spork@inch.com access@inch.com | = =----------------=

On Sun, 26 Jul 1998, Ricky Beam wrote: > Brian was heard to say: > >Has anyone heard anything about whether 3Com is going to port TCM to > >Solaris 2.6? Does anyone know what the hold up is? Surely this is a > >trivial task for those that wrote the program. > > It's just a matter of building it on a 2.6 machine, I think. If you're right (and I think you are), thats @#$@ing pathetic that it hasn't been released yet. I mean we are talking about typing "make" and waiting maybe a short while. > > >What do you all think of a JAVA based TCM, that way it wont be so damn > >platform dependant. > > Gez, it ain't slow enough for you already? Don't make me hurt you! > (They cannot write good C/C++ code and you expect them to do a better job > with JAVA?) get out of my dream! out! out! > > --Ricky > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > /-------------------------- signal@shreve.net -----------------------------\ | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | | Network Administrator | Perl, Linux | Web hosting, online stores, | | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | | 89 CRX DX w/MPFI, lots of |-=*:Quake:*=-| http://www.shreve.net/ | | mods/Homepage coming soon |LordSignal/SN| Quake server: 208.206.76.47 | \-------------------------- 318-222-2638 x109 -----------------------------/

Brian was heard to say: >Has anyone heard anything about whether 3Com is going to port TCM to >Solaris 2.6? Does anyone know what the hold up is? Surely this is a >trivial task for those that wrote the program. It's just a matter of building it on a 2.6 machine, I think. >What do you all think of a JAVA based TCM, that way it wont be so damn >platform dependant. Gez, it ain't slow enough for you already? Don't make me hurt you! (They cannot write good C/C++ code and you expect them to do a better job with JAVA?) --Ricky

Brian was heard to say: >Has anyone heard anything about whether 3Com is going to port TCM to >Solaris 2.6? Does anyone know what the hold up is? Surely this is a >trivial task for those that wrote the program. It's just a matter of building it on a 2.6 machine, I think. >What do you all think of a JAVA based TCM, that way it wont be so damn >platform dependant. Gez, it ain't slow enough for you already? Don't make me hurt you! (They cannot write good C/C++ code and you expect them to do a better job with JAVA?) --Ricky

: > Brian was heard to say: : > >Has anyone heard anything about whether 3Com is going to port TCM to : > >Solaris 2.6? Does anyone know what the hold up is? Surely this is a : > >trivial task for those that wrote the program. : > : > It's just a matter of building it on a 2.6 machine, I think. : : If you're right (and I think you are), thats @#$@ing pathetic that it : hasn't been released yet. I mean we are talking about typing "make" and : waiting maybe a short while. I believe that [I've heard that] they outsourced the development of TCM, and have it produced for certain platforms. A level-two tech support guy told me over 10 months ago that a Linux version was in the works, but I guess that never made it into the contract. I'm not sure who actually makes the decision about what platforms are included, but we would do well to find him, and encourage some clear thinking.

Yes there is a default user on the hiper arc where you can set the idle and session timeout set net user default idle " " krish \ T.S.V. Krishnan \ \ Network System Engineer \ ( : - : ) \ 3Com ............ \ ----------------------------------------------/ tkrishna@bubba.ae.usr.com ----------------------------/ http://interproc.ae.usr.com ----/ The Yadda Yadda Search - for simple anwers - http://interproc.ae.usr.com/tkb.html Any Sufficiently advanced bug is indistinguishable for a feature. - Rick Kulawiec On Mon, 27 Jul 1998, Randy Cosby wrote: > Is anyone applying Session-Timeout and Idle-Timeout's with TC racks > (netserver or > HiperArc) via Radius? Mine seem to be ignored. Is there a default user > timeout/idle timeout that can be set on the HiperARC? > > thanks, > > Randy Cosby <dcosby@infowest.com> > Vice President > InfoWest Global Internet Services, Inc. > (435)674-0165 http://www.infowest.com >

On Sun, 26 Jul 1998, Brian wrote: > On Sun, 26 Jul 1998, Ricky Beam wrote: > > > Brian was heard to say: > > >Has anyone heard anything about whether 3Com is going to port TCM to > > >Solaris 2.6? Does anyone know what the hold up is? Surely this is a > > >trivial task for those that wrote the program. > > > > It's just a matter of building it on a 2.6 machine, I think. > > If you're right (and I think you are), thats @#$@ing pathetic that it > hasn't been released yet. I mean we are talking about typing "make" and > waiting maybe a short while. Wasn't TCM for Solaris written by a third party for USR/3Com? Maybe 3Com doesn't have rights to the code, and they can't get the third party to recompile it? Brian

I have been having reports of customers having problems with their E-mail .. both sending and recieving. I have an automated poller that has no problems either sending or recieving. When the problem occurs they can do a telnet session to the SMTP or POP3 server and it responds ok, however their email software won't connect. Nothing has been changed on the servers, the only change has been to upgrade the TCHs (netserver/quad combo) to v.90 This is happening mostly for ISDN customers but I also have 1 analog customer who has reported the same problem. I don't know if the problem could be in the TCH, but I haven't been able to recreate the problem here. I am putting in a new ARC chassis and will see if the problem continues or resolves itself. Any ideas?? Eric T. Billeter Cable One Internet Engineer 1314 North 3rd Street ebilleter@cableone.net Phoenix, AZ 85004 -----Original Message----- [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of -=X=- Sent: Monday, July 27, 1998 7:27 AM Hello! > Has anyone been able to run v.90 successfully with the netserver and > quad's? or with the hiperDSP/hiperarc? You might want to check your radius > log's and see just how many lost carrier's you are getting a day.... I > didn't notice this problem right away because for us its been completely > random. Because of that not many users complained right away.... We have 2 PRI's into our box with Quads and our speeds seem to be fine. I am not positive if some of the lower speeds are due to crappy modems or lines, but here is a sample of what we got after upgrading to v.90: TX Mod. Type x2 Status bps28K(21) v34(20) x2notDetectedFromRemote(8) bps26K(20) v34(20) x2notDetectedFromRemote(8) bps29333(28) x2server(23) x2Operational(2) bps32000(30) x2server(23) x2Operational(2) bps14K(10) v32Terbo(19) v8notDetectedFromRemote(7) bps28K(21) v34(20) x2notDetectedFromRemote(8) bps29333(28) x2server(23) x2Operational(2) bps31K(23) v34(20) x2notDetectedFromRemote(8) bps48000(42) v90Digital(34) v90Operational(15) bps31K(23) v34(20) x2notDetectedFromRemote(8) bps29333(28) x2server(23) x2Operational(2) bps29333(28) x2server(23) x2Operational(2) bps26K(20) v34(20) x2notDetectedFromRemote(8) bps28K(21) v34(20) x2notDetectedFromRemote(8) bps28K(21) v34(20) x2notDetectedFromRemote(8) bps29333(28) x2server(23) x2Operational(2) bps28K(21) v34(20) excessiveHFAttenuation(12) bps26K(20) v34(20) excessiveHFAttenuation(12) bps32000(30) x2server(23) x2Operational(2) bps29333(28) x2server(23) x2Operational(2) bps14K(10) v32Terbo(19) v8notDetectedFromRemote(7) bps14K(10) v32Terbo(19) v8notDetectedFromRemote(7) bps28K(21) v34(20) x2notDetectedFromRemote(8) bps16K(11) v34(20) excessiveHFAttenuation(12) bps49333(43) v90Digital(34) v90Operational(15) bps29333(28) x2server(23) x2Operational(2) bps28K(21) v34(20) x2notDetectedFromRemote(8) bps52000(45) v90Digital(34) v90Operational(15) bps49333(43) v90Digital(34) v90Operational(15) bps48000(42) x2server(23) x2Operational(2) bps28K(21) v34(20) x2notDetectedFromRemote(8) bps29333(28) x2server(23) x2Operational(2) bps52000(45) v90Digital(34) v90Operational(15) bps29333(28) x2server(23) x2Operational(2) bps28K(21) v34(20) x2notDetectedFromRemote(8) bps28K(21) v34(20) x2notDetectedFromRemote(8) bps29333(28) x2server(23) x2Operational(2) bps29333(28) x2server(23) x2Operational(2) bps32000(30) x2server(23) x2Operational(2) bps28K(21) v34(20) x2notDetectedFromRemote(8) bps28K(21) v34(20) x2notDetectedFromRemote(8) bps28K(21) v34(20) excessiveHFAttenuation(12) bps28K(21) v34(20) x2notDetectedFromRemote(8) bps29333(28) x2server(23) x2Operational(2) bps29333(28) x2server(23) x2Operational(2) bps26K(20) v34(20) excessiveHFAttenuation(12) bps26K(20) v34(20) excessiveHFAttenuation(12) bps26K(20) v34(20) x2notDetectedFromRemote(8) I see that excessiveHFAttenuation on a few lines, but most of the speeds are decent. We do have some folks dialed up who are out in BFE, however, so I am pretty sure that most of the slower speeds are due to that reason. FYI Dan Allen - System Admin. -Novagate Communications Corp.- > > I'm considering downgrading to older code that just supports X2 and seeing > if that is somewhat stable....I tried turning off v.90 in > my current code but it didn't help. Obviously I won't be happy if I have > to downgrade. Let's hope I'm just missing a small telco setting or > soemthing. > > - > andy > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > Dan Allen - System Admin. -Novagate Communications Corp.- - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

Hello! > Has anyone been able to run v.90 successfully with the netserver and > quad's? or with the hiperDSP/hiperarc? You might want to check your radius > log's and see just how many lost carrier's you are getting a day.... I > didn't notice this problem right away because for us its been completely > random. Because of that not many users complained right away.... We have 2 PRI's into our box with Quads and our speeds seem to be fine. I am not positive if some of the lower speeds are due to crappy modems or lines, but here is a sample of what we got after upgrading to v.90: TX Mod. Type x2 Status bps28K(21) v34(20) x2notDetectedFromRemote(8) bps26K(20) v34(20) x2notDetectedFromRemote(8) bps29333(28) x2server(23) x2Operational(2) bps32000(30) x2server(23) x2Operational(2) bps14K(10) v32Terbo(19) v8notDetectedFromRemote(7) bps28K(21) v34(20) x2notDetectedFromRemote(8) bps29333(28) x2server(23) x2Operational(2) bps31K(23) v34(20) x2notDetectedFromRemote(8) bps48000(42) v90Digital(34) v90Operational(15) bps31K(23) v34(20) x2notDetectedFromRemote(8) bps29333(28) x2server(23) x2Operational(2) bps29333(28) x2server(23) x2Operational(2) bps26K(20) v34(20) x2notDetectedFromRemote(8) bps28K(21) v34(20) x2notDetectedFromRemote(8) bps28K(21) v34(20) x2notDetectedFromRemote(8) bps29333(28) x2server(23) x2Operational(2) bps28K(21) v34(20) excessiveHFAttenuation(12) bps26K(20) v34(20) excessiveHFAttenuation(12) bps32000(30) x2server(23) x2Operational(2) bps29333(28) x2server(23) x2Operational(2) bps14K(10) v32Terbo(19) v8notDetectedFromRemote(7) bps14K(10) v32Terbo(19) v8notDetectedFromRemote(7) bps28K(21) v34(20) x2notDetectedFromRemote(8) bps16K(11) v34(20) excessiveHFAttenuation(12) bps49333(43) v90Digital(34) v90Operational(15) bps29333(28) x2server(23) x2Operational(2) bps28K(21) v34(20) x2notDetectedFromRemote(8) bps52000(45) v90Digital(34) v90Operational(15) bps49333(43) v90Digital(34) v90Operational(15) bps48000(42) x2server(23) x2Operational(2) bps28K(21) v34(20) x2notDetectedFromRemote(8) bps29333(28) x2server(23) x2Operational(2) bps52000(45) v90Digital(34) v90Operational(15) bps29333(28) x2server(23) x2Operational(2) bps28K(21) v34(20) x2notDetectedFromRemote(8) bps28K(21) v34(20) x2notDetectedFromRemote(8) bps29333(28) x2server(23) x2Operational(2) bps29333(28) x2server(23) x2Operational(2) bps32000(30) x2server(23) x2Operational(2) bps28K(21) v34(20) x2notDetectedFromRemote(8) bps28K(21) v34(20) x2notDetectedFromRemote(8) bps28K(21) v34(20) excessiveHFAttenuation(12) bps28K(21) v34(20) x2notDetectedFromRemote(8) bps29333(28) x2server(23) x2Operational(2) bps29333(28) x2server(23) x2Operational(2) bps26K(20) v34(20) excessiveHFAttenuation(12) bps26K(20) v34(20) excessiveHFAttenuation(12) bps26K(20) v34(20) x2notDetectedFromRemote(8) I see that excessiveHFAttenuation on a few lines, but most of the speeds are decent. We do have some folks dialed up who are out in BFE, however, so I am pretty sure that most of the slower speeds are due to that reason. FYI Dan Allen - System Admin. -Novagate Communications Corp.- > > I'm considering downgrading to older code that just supports X2 and seeing > if that is somewhat stable....I tried turning off v.90 in > my current code but it didn't help. Obviously I won't be happy if I have > to downgrade. Let's hope I'm just missing a small telco setting or > soemthing. > > - > andy > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > Dan Allen - System Admin. -Novagate Communications Corp.-

This is a multi-part message in MIME format. ------=_NextPart_000_00A8_01BDB953.BEBB4510 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Before I dive head-in to filters, I'm wondering if anyone else is using filters on the ARC to block Windows file sharing? Could you post some example filters? From what I understand, I need to block IP ports 137,138 and 139. Anything else? Thanks! Randy Cosby <dcosby@infowest.com> Vice President InfoWest Global Internet Services, Inc. (435)674-0165 http://www.infowest.com ------=_NextPart_000_00A8_01BDB953.BEBB4510 Content-Type: application/octet-stream; name="Randy Cosby.vcf" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="Randy Cosby.vcf" BEGIN:VCARD VERSION:2.1 N:Cosby;Randy FN:Randy Cosby ORG:InfoWest Global Internet Services, Inc. TITLE:Vice President NOTE;ENCODING=3DQUOTED-PRINTABLE:What do I do? =3D0D=3D0A=3D0D=3D0AVice = President, InfoWest =3D0D=3D0AAreas of responsib=3D ility include: Research, Development, communications services = http://www.inf=3D owest.com=3D0D=3D0A=3D0D=3D0AWeb Site = Manager=3D0D=3D0Ahttp://www.devshed.com=3D0D=3D0Ahttp:=3D //www.32bit.com=3D0D=3D0A=3D0D=3D0AUtah's first Internet-over-cable: = iCable=3D0D=3D0Ahtt=3D p://www.icable.net=3D0D=3D0A=3D0D=3D0AWhat can I do for you? TEL;WORK;VOICE:(435) 674-0165 TEL;WORK;FAX:(435) 674-9734 ADR;WORK:;;1845 West Sunset Boulevard;St. George;UT;84770;United States = of America LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:1845 West Sunset = Boulevard=3D0D=3D0ASt. George, UT 84770=3D0D=3D0AUnited States of A=3D merica URL: URL:http://www.infowest.com EMAIL;PREF;INTERNET:dcosby@infowest.com REV:19980630T225731Z END:VCARD ------=_NextPart_000_00A8_01BDB953.BEBB4510--

This is a multi-part message in MIME format. ------=_NextPart_000_00B9_01BDB955.80196AB0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Is anyone applying Session-Timeout and Idle-Timeout's with TC racks (netserver or HiperArc) via Radius? Mine seem to be ignored. Is there a default user timeout/idle timeout that can be set on the HiperARC? thanks, Randy Cosby <dcosby@infowest.com> Vice President InfoWest Global Internet Services, Inc. (435)674-0165 http://www.infowest.com ------=_NextPart_000_00B9_01BDB955.80196AB0 Content-Type: application/octet-stream; name="Randy Cosby.vcf" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="Randy Cosby.vcf" BEGIN:VCARD VERSION:2.1 N:Cosby;Randy FN:Randy Cosby ORG:InfoWest Global Internet Services, Inc. TITLE:Vice President NOTE;ENCODING=3DQUOTED-PRINTABLE:What do I do? =3D0D=3D0A=3D0D=3D0AVice = President, InfoWest =3D0D=3D0AAreas of responsib=3D ility include: Research, Development, communications services = http://www.inf=3D owest.com=3D0D=3D0A=3D0D=3D0AWeb Site = Manager=3D0D=3D0Ahttp://www.devshed.com=3D0D=3D0Ahttp:=3D //www.32bit.com=3D0D=3D0A=3D0D=3D0AUtah's first Internet-over-cable: = iCable=3D0D=3D0Ahtt=3D p://www.icable.net=3D0D=3D0A=3D0D=3D0AWhat can I do for you? TEL;WORK;VOICE:(435) 674-0165 TEL;WORK;FAX:(435) 674-9734 ADR;WORK:;;1845 West Sunset Boulevard;St. George;UT;84770;United States = of America LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:1845 West Sunset = Boulevard=3D0D=3D0ASt. George, UT 84770=3D0D=3D0AUnited States of A=3D merica URL: URL:http://www.infowest.com EMAIL;PREF;INTERNET:dcosby@infowest.com REV:19980630T225731Z END:VCARD ------=_NextPart_000_00B9_01BDB955.80196AB0--

On Mon, 27 Jul 1998, Brian Elfert wrote: > > > On Sun, 26 Jul 1998, Brian wrote: > > > On Sun, 26 Jul 1998, Ricky Beam wrote: > > > > > Brian was heard to say: > > > >Has anyone heard anything about whether 3Com is going to port TCM to > > > >Solaris 2.6? Does anyone know what the hold up is? Surely this is a > > > >trivial task for those that wrote the program. > > > > > > It's just a matter of building it on a 2.6 machine, I think. > > > > If you're right (and I think you are), thats @#$@ing pathetic that it > > hasn't been released yet. I mean we are talking about typing "make" and > > waiting maybe a short while. > > Wasn't TCM for Solaris written by a third party for USR/3Com? Maybe 3Com > doesn't have rights to the code, and they can't get the third party to > recompile it? As far as I know, All of TCM was outsourced. Brian > > Brian > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > Brian Feeny (BF304) | ShreveNet Inc. - Premium Internet Service Provider Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1

Thanks. Are the radius reply attributes being ignored? > -----Original Message----- > From: owner-usr-tc@lists.xmission.com > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Marcelo Souza > Sent: Monday, July 27, 1998 12:12 PM > To: usr-tc@lists.xmission.com > Subject: Re: (usr-tc) Timeouts.. > > > > On ARC you can do: > > HiPer>> set usER default idLE_TIMEOUT > or > HiPer>> set useR default seSSION_TIMEOUT > > Here by safe I also put in the modem string S19=30. > > - Marcelo > > On Mon, 27 Jul 1998, Randy Cosby wrote: > > |Is anyone applying Session-Timeout and Idle-Timeout's with TC racks > |(netserver or > |HiperArc) via Radius? Mine seem to be ignored. Is there a default user > |timeout/idle timeout that can be set on the HiperARC? > | > |thanks, > | > |Randy Cosby <dcosby@infowest.com> > |Vice President > |InfoWest Global Internet Services, Inc. > |(435)674-0165 http://www.infowest.com > | > > - Marcelo > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

In texasnet.usr-tc, you wrote: >Yes there is a default user on the hiper arc where you can set the idle >and session timeout > >set net user default idle " " > >krish My question is why do the HiPer's not accept the standard radius attribute of Idle-Timeout ? -- GigaNews.Com The Spot for News http://www.giganews.com Making UseNet a Global Priority

I'm testing on Radiator. > -----Original Message----- > From: owner-usr-tc@lists.xmission.com > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Marcelo Souza > Sent: Monday, July 27, 1998 2:31 PM > To: usr-tc@lists.xmission.com > Subject: RE: (usr-tc) Timeouts.. > > > On Mon, 27 Jul 1998, Randy Cosby wrote: > > |Thanks. Are the radius reply attributes being ignored? > > I had not tested. But you give a good ideia. I will test it here. > > BTW, witch radius are you using? > > - Marcelo > | > | > |> -----Original Message----- > |> From: owner-usr-tc@lists.xmission.com > |> [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Marcelo Souza > |> Sent: Monday, July 27, 1998 12:12 PM > |> To: usr-tc@lists.xmission.com > |> Subject: Re: (usr-tc) Timeouts.. > |> > |> > |> > |> On ARC you can do: > |> > |> HiPer>> set usER default idLE_TIMEOUT > |> or > |> HiPer>> set useR default seSSION_TIMEOUT > |> > |> Here by safe I also put in the modem string S19=30. > |> > |> - Marcelo > |> > |> On Mon, 27 Jul 1998, Randy Cosby wrote: > |> > |> |Is anyone applying Session-Timeout and Idle-Timeout's with TC racks > |> |(netserver or > |> |HiperArc) via Radius? Mine seem to be ignored. Is there a > default user > |> |timeout/idle timeout that can be set on the HiperARC? > |> | > |> |thanks, > |> | > |> |Randy Cosby <dcosby@infowest.com> > |> |Vice President > |> |InfoWest Global Internet Services, Inc. > |> |(435)674-0165 http://www.infowest.com > |> | > |> > |> - Marcelo > |> > |> > |> - > |> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > |> with "unsubscribe usr-tc" in the body of the message. > |> For information on digests or retrieving files and old messages send > |> "help" to the same address. Do not use quotes in your message. > |> > | > |- > | To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > | with "unsubscribe usr-tc" in the body of the message. > | For information on digests or retrieving files and old messages send > | "help" to the same address. Do not use quotes in your message. > | > > - Marcelo > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

On ARC you can do: HiPer>> set usER default idLE_TIMEOUT or HiPer>> set useR default seSSION_TIMEOUT Here by safe I also put in the modem string S19=30. - Marcelo On Mon, 27 Jul 1998, Randy Cosby wrote: |Is anyone applying Session-Timeout and Idle-Timeout's with TC racks |(netserver or |HiperArc) via Radius? Mine seem to be ignored. Is there a default user |timeout/idle timeout that can be set on the HiperARC? | |thanks, | |Randy Cosby <dcosby@infowest.com> |Vice President |InfoWest Global Internet Services, Inc. |(435)674-0165 http://www.infowest.com | - Marcelo

Once upon a time Walt Gnann shaped the electrons to say... >Just a quick question on MLPPP. We can successfully connect and maintain a That's "MP" - please don't call it MLPPP, it gets confused with all of the private acronyms like MCPPP, MMP, MPIP, MCMP, etc. Per RFC it is MP. >will not work if the connections are on separate chasis. Can you have a >MLPPP connection across chasis? How? That is where 3Com/USR/s 'MPIP' protocol comes in - it allows MP connections to bundle across chasis. Most vendors have something along these lines - Lucent has MCPPP, Ascend has MaxStack, etc. -MZ -- <URL:mailto:megazone@megazone.org> Gweep, Discordian, Author, Engineer, me.. Join ISP/C Internet Service Providers' Consortium <URL:http://www.ispc.org/> "A little nonsense now and then, is relished by the wisest men" 781-788-0130 <URL:http://www.gweep.net/> <URL:http://www.megazone.org/> Hail Discordia!

Once upon a time Mark R. Lindsey shaped the electrons to say... >Does USR's MLPPP implementation work with Linux' serial load balancing? That's MP - not MLPPP. And no. MP is a specific protocol, RFC 1990. Linux's EQL is NOT MP, and is NOT MP compatible. It is basically a round robin packet distribution based on multiple physical links having the same IP endpoints. It was developed to be compatable with Livingston's Multiline Load Balancing. But it should work with any product that can aggregate multiple lines based on IP endpoint. I've been told 3Com routers can do this, but I don't know about the TC or HiPer. -MZ -- <URL:mailto:megazone@megazone.org> Gweep, Discordian, Author, Engineer, me.. Join ISP/C Internet Service Providers' Consortium <URL:http://www.ispc.org/> "A little nonsense now and then, is relished by the wisest men" 781-788-0130 <URL:http://www.gweep.net/> <URL:http://www.megazone.org/> Hail Discordia!

Once upon a time Brian shaped the electrons to say... >What do you all think of a JAVA based TCM, that way it wont be so damn >platform dependant. I think it sounds like Lucent's PMVision (the product formerly codenamed as Amber). -MZ -- <URL:mailto:megazone@megazone.org> Gweep, Discordian, Author, Engineer, me.. Join ISP/C Internet Service Providers' Consortium <URL:http://www.ispc.org/> "A little nonsense now and then, is relished by the wisest men" 781-788-0130 <URL:http://www.gweep.net/> <URL:http://www.megazone.org/> Hail Discordia!

Jeff Binkley wrote: > > As promised I completed testing the upsizing of 3Com's RADIUS software > to SQL Server 6.5 from MS Accessover this past weekend. While the actual > upsizing of the database from Access to SQL Server went much better than > my attempts at Sybase 11.5, the end results were still a failure. It > appears 3Com has hard coded some MS Access specific routines into > their radius.exe executable file, which are not SQL 92 compliant > calls. Thus it can see the tables (I changed the ODBC pointer to > the new SQL database and added the appropriate security fields) but > it fials trying some SQLexec calls. I'd sure like to see more info > on this from 3Com. 3rd party RADIUS solutions are looking better > all of the time. Now if they'd offer a competitive upgrade, I > might bite... If the 3Com liscense is transferable, send me Email and we'll discuss options. I know RadiusNT works on MS Access, SQL Server, Sybase and Oracle. It is funny how different MS Access and SQL Server are from a client's perspetive. Some people just assume that if its works with ODBC and Access it work work with all of them. :( -- Dale E. Reed Jr. (daler@iea-software.com) _________________________________________________________________ IEA Software, Inc. | RadiusNT, Emerald, and NT FAQs Internet Solutions for Today | http://www.iea-software.com

Howdy, If a service were created to do regression testing on USR-TC equipment, would your firm subscribe? I'm imagining that such a group might try to procure a variety of equipment, then test the equipment and new firmware upgrades against older versions. Subscribers would get tech support, and regular updates on firmware releases (e.g., what each works with, what it won't work with, how much memory you need, problems with different modem brands, potential problems, &c.). So, would you subscribe? If so, how much could you afford to pay for it? --- Mark R. Lindsey, mark@datasys.net Internet Engineering, DSS Online LLC Voice: 912.241.0607; Fax: 912.241.0190

On Mon, 27 Jul 1998, Randy Cosby wrote: |Thanks. Are the radius reply attributes being ignored? I had not tested. But you give a good ideia. I will test it here. BTW, witch radius are you using? - Marcelo | | |> -----Original Message----- |> From: owner-usr-tc@lists.xmission.com |> [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Marcelo Souza |> Sent: Monday, July 27, 1998 12:12 PM |> To: usr-tc@lists.xmission.com |> Subject: Re: (usr-tc) Timeouts.. |> |> |> |> On ARC you can do: |> |> HiPer>> set usER default idLE_TIMEOUT |> or |> HiPer>> set useR default seSSION_TIMEOUT |> |> Here by safe I also put in the modem string S19=30. |> |> - Marcelo |> |> On Mon, 27 Jul 1998, Randy Cosby wrote: |> |> |Is anyone applying Session-Timeout and Idle-Timeout's with TC racks |> |(netserver or |> |HiperArc) via Radius? Mine seem to be ignored. Is there a default user |> |timeout/idle timeout that can be set on the HiperARC? |> | |> |thanks, |> | |> |Randy Cosby <dcosby@infowest.com> |> |Vice President |> |InfoWest Global Internet Services, Inc. |> |(435)674-0165 http://www.infowest.com |> | |> |> - Marcelo |> |> |> - |> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" |> with "unsubscribe usr-tc" in the body of the message. |> For information on digests or retrieving files and old messages send |> "help" to the same address. Do not use quotes in your message. |> | |- | To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" | with "unsubscribe usr-tc" in the body of the message. | For information on digests or retrieving files and old messages send | "help" to the same address. Do not use quotes in your message. | - Marcelo

As promised I completed testing the upsizing of 3Com's RADIUS software to SQL Server 6.5 from MS Accessover this past weekend. While the actual upsizing of the database from Access to SQL Server went much better than my attempts at Sybase 11.5, the end results were still a failure. It appears 3Com has hard coded some MS Access specific routines into their radius.exe executable file, which are not SQL 92 compliant calls. Thus it can see the tables (I changed the ODBC pointer to the new SQL database and added the appropriate security fields) but it fials trying some SQLexec calls. I'd sure like to see more info on this from 3Com. 3rd party RADIUS solutions are looking better all of the time. Now if they'd offer a competitive upgrade, I might bite... Jeff Binkley ASA Network Computing

> I have a trunk T-1 when connected to a dual T-1, Quad modems and netserver > bundle, > I get X2 and V.90, 56K. > > When I move the T-1 to a DSP on a hyper bundle chassis, only V.34, 33.6bps. Probably need to restore defaults on the HDM. I have had similar instances when flashing new code will put the settings for v.90, x2, etc in a disable mode. Check the 'modulation settings' or something like that via TCM on the modems of the HDM. You'll probably see a whole bunch of disabled features. A full "restore from defaults" on the HDM should fix it. | Curtis V. Shambeau | curt@execpc.com | http://www.execpc.com/~curt | | Executive Vice President - Exec-PC, Inc. |

I've got the HiPer starter bundle (2 dsp & 1 arc), and have upgraded the new code. I got a Diamond SupraSonic II dual-line shotgun modem. It worked out of the box; I didn't have to do anything special to either. Lon Stockton MoonStar On Thu, 23 Jul 1998 jcusmano@westcon.com wrote: > I have been on hold with 3Com Tech Support for around 2 hours for info on the > Diamon Shotgun. When I find out more info, I'll send it to all of you unless > someone else can help us out? > > > ____________________Reply Separator____________________ > Subject: (usr-tc) Support for "Shotgun" technology? > Author: MIME:dpm@netcetera.com > Date: 7/23/98 4:23 PM > > Sorry if this is a FAQ, but I couldn't find anything on the 3Com web site. > > Are there any versions of the NetServer and/or HyperArc software that > support Diamon/Supra's "Shotgun" protocol? > > The Diamond web site says: > > "Shotgun technology is simple for ISPs to implement at the central site > because ot fully supports both the MP+ and MLPPP protocols found on the > majority of central site equipment. Successful tests of Shotgun have > already been completed on Ascend, Cisco, 3Com and Livingston equipment." > ^^^^ > > Our TCS boxes use T1 rather than PRI, if that makes a difference... > > > ------------------------------------------------------------------------ > Dave Martin Netcetera, Inc. dpm@netcetera.com > "Infinity Welcomes Careful Drivers" > ------------------------------------------------------------------------ > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Idle time out does work with the radius server. If for any reason it is not working for you, let me know the version of the hiper arc code and if possible get me a snoop trace of the authentication. krish \ T.S.V. Krishnan \ \ Network System Engineer \ ( : - : ) \ 3Com ............ \ ----------------------------------------------/ tkrishna@bubba.ae.usr.com ----------------------------/ http://interproc.ae.usr.com ----/ The Yadda Yadda Search - for simple anwers - http://interproc.ae.usr.com/tkb.html Any Sufficiently advanced bug is indistinguishable for a feature. - Rick Kulawiec On Mon, 27 Jul 1998 blh@texas.net wrote: > In texasnet.usr-tc, you wrote: > >Yes there is a default user on the hiper arc where you can set the idle > >and session timeout > > > >set net user default idle " " > > > >krish > > My question is why do the HiPer's not accept the standard radius attribute > of Idle-Timeout ? > > -- > GigaNews.Com > The Spot for News > http://www.giganews.com > Making UseNet a Global Priority > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

On Tue, 28 Jul 1998, Mark Pansing wrote: > > Having some problems with the HiperArc and retrieval of certain websites. > If our users call in and are dynamically assigned a ip address from the > HiperArcs pool they are not able to access certain websites, however if I > assign them an ip address from the dial up pool (that noone is using) in > radius(Framed-Address = ###.###.###.###), they can access the website > without a problem. > What is the mtu of these users? make sure the mtu is set to 1500 krish > The HiperArc is running V4.0.29 with RIP off. The websites that we are > having problems with are: > yp.ameritech.com, www.compaq.com, and www.schwab.com. > > Has anyone got any ideas or has heard of this? > > Mark Pansing > Infinet Engineering Staff > (614) 848-4638 x203 > markp@infinet.com > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

On Tue, 28 Jul 1998, Walt Gnann wrote: > Thanks for the correction, MZ. I followed the instructions at > http://interproc.ae.usr.com (thanks Tatai) and we're in the process of > testing it now. Part of the instructions indicated that the Netserver > should be at the same software revision. Is that necessary? What problems > can I expect? I have two Netservers at 3.5.34 and three at 3.6.28 with the > MPIP server on 3.6.28. > Yes it is necessary that you have your NETServer running the same version of code. 3.5.x and 3.6.x have some changes in the MPIP code. This changes may cause the NETServer not to accept MPIP calls during load and may also experience some crash. So we do advice you to have the same version of the code. >Any idea on when the HyperArc is going to be able to > create MP links across the Netsevers? Kinda defeats the purpose of MP if > you have mixed situation like myself. HiPer arc will support MPIP in version 4.1 - This code is in beta currently krish > > Thanks, > > Walt > ----------------------------------------------------- > Walter N. Gnann > ISLC, Manager > 843.770.1000 > 843.770.1002 (fax) > wgnann@islc.net > http://www.islc.net > http://www.beaufortcomputerclub.org > ----------------------------------------------------- > > -----Original Message----- > From: MegaZone <megazone@megazone.org> > To: usr-tc@lists.xmission.com <usr-tc@lists.xmission.com> > Date: Monday, July 27, 1998 7:11 PM > Subject: Re: (usr-tc) MLPPP > > > >Once upon a time Walt Gnann shaped the electrons to say... > >>Just a quick question on MLPPP. We can successfully connect and maintain > a > > > >That's "MP" - please don't call it MLPPP, it gets confused with all of the > >private acronyms like MCPPP, MMP, MPIP, MCMP, etc. Per RFC it is MP. > > > >>will not work if the connections are on separate chasis. Can you have a > >>MLPPP connection across chasis? How? > > > >That is where 3Com/USR/s 'MPIP' protocol comes in - it allows MP > connections > >to bundle across chasis. Most vendors have something along these lines - > >Lucent has MCPPP, Ascend has MaxStack, etc. > > > >-MZ > >-- > ><URL:mailto:megazone@megazone.org> Gweep, Discordian, Author, Engineer, > me.. > >Join ISP/C Internet Service Providers' Consortium > <URL:http://www.ispc.org/> > >"A little nonsense now and then, is relished by the wisest men" > 781-788-0130 > ><URL:http://www.gweep.net/> <URL:http://www.megazone.org/> Hail > Discordia! > > > >- > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

If you can get it out of them, get it. This brings me to another question with the Netserver... Does anyone know about a bug in the Netserver in which if you have over 23 analog and digital connections on a chassis (Latest Firmware on 2059 Bundle) the ISDN connectivity becomes unstable? Someone told me about this a week ago. We were having problems with ISDN Connections on our TC chassis, so we unplugged one PRI from the main chassis and the problem apparently went away. No complaints from ISDN Customers in a week. Lee Reese FBSD wrote: > > After months of continuous problems with our two NETServerI/16, our 3Com > vendor has agreed to replace them with: > > 1. TC Hub > 2. Quad modems, > 3. dual PRI card > 4. Netserver card. > > I've read in this list that people should be purchasing HiperARC (?) > instead of the Netserver card. Is this correct? All we want is a stable > dial-up pool of modems. Should we request a HiperARC card from our vendor > instead of a Netserver card? Thanx in advance for any pointers. > > fbsd > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message.

If you can get it out of them, get it. This brings me to another question with the Netserver... Does anyone know about a bug in the Netserver in which if you have over 23 analog and digital connections on a chassis (Latest Firmware on 2059 Bundle) the ISDN connectivity becomes unstable? Someone told me about this a week ago. We were having problems with ISDN Connections on our TC chassis, so we unplugged one PRI from the main chassis and the problem apparently went away. No complaints from ISDN Customers in a week. Lee Reese FBSD wrote: > > After months of continuous problems with our two NETServerI/16, our 3Com > vendor has agreed to replace them with: > > 1. TC Hub > 2. Quad modems, > 3. dual PRI card > 4. Netserver card. > > I've read in this list that people should be purchasing HiperARC (?) > instead of the Netserver card. Is this correct? All we want is a stable > dial-up pool of modems. Should we request a HiperARC card from our vendor > instead of a Netserver card? Thanx in advance for any pointers. > > fbsd > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message.

No its not there in the netserver. krish \ T.S.V. Krishnan \ \ Network System Engineer \ ( : - : ) \ 3Com ............ \ ----------------------------------------------/ tkrishna@bubba.ae.usr.com ----------------------------/ http://interproc.ae.usr.com ----/ The Yadda Yadda Search - for simple anwers - http://interproc.ae.usr.com/tkb.html Any Sufficiently advanced bug is indistinguishable for a feature. - Rick Kulawiec On Tue, 28 Jul 1998, Randy Cosby wrote: > Is there a similar command on the NetServers? I'm going to play with the > radius / hiper today and see if I can get some "snoops". > > Randy > > > > -----Original Message----- > > From: owner-usr-tc@lists.xmission.com > > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Tatai SV Krishnan > > Sent: Monday, July 27, 1998 12:28 AM > > To: Randy Cosby > > Cc: usr-tc@lists.xmission.com > > Subject: Re: (usr-tc) Timeouts.. > > > > > > Yes there is a default user on the hiper arc where you can set the idle > > and session timeout > > > > set net user default idle " " > > > > krish > > > > ----------------------------------------- > > \ T.S.V. Krishnan \ > > \ Network System Engineer \ ( : - : ) > > \ 3Com ............ \ > > ----------------------------------------------/ > > tkrishna@bubba.ae.usr.com > > ----------------------------/ http://interproc.ae.usr.com ----/ > > The Yadda Yadda Search - for simple anwers - > > http://interproc.ae.usr.com/tkb.html > > > > -------------------------------------------------------------------------\ > > Any Sufficiently advanced bug is indistinguishable for a feature. > > - Rick Kulawiec > > -------------------------------------------------------------------------/ > > > > On Mon, 27 Jul 1998, Randy Cosby wrote: > > > > > Is anyone applying Session-Timeout and Idle-Timeout's with TC racks > > > (netserver or > > > HiperArc) via Radius? Mine seem to be ignored. Is there a default user > > > timeout/idle timeout that can be set on the HiperARC? > > > > > > thanks, > > > > > > Randy Cosby <dcosby@infowest.com> > > > Vice President > > > InfoWest Global Internet Services, Inc. > > > (435)674-0165 http://www.infowest.com > > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

On Mon, 27 Jul 1998, Jeff Binkley wrote: > > As promised I completed testing the upsizing of 3Com's RADIUS software > to SQL Server 6.5 from MS Accessover this past weekend. While the actual > upsizing of the database from Access to SQL Server went much better than > my attempts at Sybase 11.5, the end results were still a failure. It > appears 3Com has hard coded some MS Access specific routines into > their radius.exe executable file, which are not SQL 92 compliant > calls. Thus it can see the tables (I changed the ODBC pointer to > the new SQL database and added the appropriate security fields) but > it fials trying some SQLexec calls. I'd sure like to see more info > on this from 3Com. 3rd party RADIUS solutions are looking better > all of the time. Now if they'd offer a competitive upgrade, I > might bite... You may want to check out the Radiator product http://www.open.com.su/. It supports 3com Vendor Specific Attributes, Dynamic IP filters, just about *any* database (including sybase AND MS SQL), and alot of other features that make it very attractive. I am trying this out right now, and so far its looking really good. Radiator also offers integration with many popular ISP billing packages, and that's our next step. Brian > > Jeff Binkley > ASA Network Computing > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > Brian Feeny (BF304) | ShreveNet Inc. - Premium Internet Service Provider Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1

On Tue, 28 Jul 1998, FBSD wrote: > > After months of continuous problems with our two NETServerI/16, our 3Com > vendor has agreed to replace them with: > > 1. TC Hub > 2. Quad modems, > 3. dual PRI card > 4. Netserver card. > > I've read in this list that people should be purchasing HiperARC (?) > instead of the Netserver card. Is this correct? All we want is a stable > dial-up pool of modems. Should we request a HiperARC card from our vendor > instead of a Netserver card? Thanx in advance for any pointers. If they will give it to you then yes. Otherwise I don't *think* that a Quad/Netserver bundle is worse off than a NetservierI/16 > > fbsd > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > Brian Feeny (BF304) | ShreveNet Inc. - Premium Internet Service Provider Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1

You guys are doing better than I am, I have yet to get a mp connection up and running on an NT box. I think the problem is on the USR side. Everyone on the list tells me, There is no configuration thats need to be done on the USR box. Hence, they think it's the NT side. I have heard to verify that "set mp on" has been done on the USR end. Problem is, "set mp on" generates an error when I type it in after telneting to the netserver. Any ideas? Chuck.. -----Original Message----- >Once upon a time Mark R. Lindsey shaped the electrons to say... >>Does USR's MLPPP implementation work with Linux' serial load balancing? > >That's MP - not MLPPP. And no. MP is a specific protocol, RFC 1990. > >Linux's EQL is NOT MP, and is NOT MP compatible. It is basically a round >robin packet distribution based on multiple physical links having the same >IP endpoints. It was developed to be compatable with Livingston's Multiline >Load Balancing. But it should work with any product that can aggregate >multiple lines based on IP endpoint. I've been told 3Com routers can do this, >but I don't know about the TC or HiPer. > >-MZ >-- ><URL:mailto:megazone@megazone.org> Gweep, Discordian, Author, Engineer, me.. >Join ISP/C Internet Service Providers' Consortium <URL:http://www.ispc.org/> >"A little nonsense now and then, is relished by the wisest men" 781-788-0130 ><URL:http://www.gweep.net/> <URL:http://www.megazone.org/> Hail Discordia! >

EQL (load balancing) from Linux is doable with the netservers. You can manually start pppd daemons, or use a program like diald to automate the dialup process. Check the diald mailing list archives for details on this. Also, here's a link to do it the proper way, with MP. I havent tried this method but it sounds like it'll work, and its more efficient than EQL. http://mp.ins-coin.de/ - lv

Anyone ever heard of a GTD5 switch? I'm trying to turn up a new circuit in GTE Calif territory and the switch they are using is a GTD5. I have a call into support, and they think that it is the same as a DMS100, however they were not sure. I show carrier on the line, however I am getting an error light on the chassis that of amber in the LPBK/D-ALM position. Support says that it is a loss of D-Channel, but this is not a PRI circuit, it is a CT1 so the D-Channel shouldn't matter there. Any help would be appreciated. Thanks, Eric

FYI for y'all: If an NMC is powered up without the Ethernet (10bT) cable plugged in, the Ethernet (10bT) port will be disabled even if an Etherent cable is plugged in later. From what I'm told, if a cable is unplugged, then plugged back in, the port is *not* disabled. A feature request has been added to not disable the Ethernet port on power up if no cable is present even though the LAN Power-Up setting is Enable. Kevin Benton Network Engineer SOTA Technologies E-Mail: s1kevin@tims.net Web: http://users.sota-oh.com/~s1kevin/ Unsolicited advertisements processing fee: $50 subject to change without notice

Having some problems with the HiperArc and retrieval of certain websites. If our users call in and are dynamically assigned a ip address from the HiperArcs pool they are not able to access certain websites, however if I assign them an ip address from the dial up pool (that noone is using) in radius(Framed-Address = ###.###.###.###), they can access the website without a problem. The HiperArc is running V4.0.29 with RIP off. The websites that we are having problems with are: yp.ameritech.com, www.compaq.com, and www.schwab.com. Has anyone got any ideas or has heard of this? Mark Pansing Infinet Engineering Staff (614) 848-4638 x203 markp@infinet.com

On Tue, 28 Jul 1998, Mark Pansing wrote: > > Having some problems with the HiperArc and retrieval of certain websites. > If our users call in and are dynamically assigned a ip address from the > HiperArcs pool they are not able to access certain websites, however if I > assign them an ip address from the dial up pool (that noone is using) in > radius(Framed-Address = ###.###.###.###), they can access the website > without a problem. Post the radius entry they are getting assigned. Also tell us how your ip pools on the arc is setup. > > The HiperArc is running V4.0.29 with RIP off. The websites that we are > having problems with are: > yp.ameritech.com, www.compaq.com, and www.schwab.com. > > Has anyone got any ideas or has heard of this? > > Mark Pansing > Infinet Engineering Staff > (614) 848-4638 x203 > markp@infinet.com > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > Brian Feeny (BF304) | ShreveNet Inc. - Premium Internet Service Provider Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1

On Tue, 28 Jul 1998, Dale Hege wrote: > Has anyone been able to get anymore information from the netserver when it > makes a mpip connection? This is what I get for the second channel. > > Acct-Session-Id = "0f000062" > User-Name = "Pfhege" > NAS-IP-Address = 207.136.192.240 > NAS-Port = 6000 > Acct-Status-Type = Stop > Acct-Session-Time = 75 > Acct-Terminate-Cause = Lost-Carrier > Acct-Authentic = 0 > Called-Station-Id = "" > USR-Unauthenticated-Time = 0 > NAS-Identifier = "usr0.noc" > Acct-Input-Octets = 331 > Acct-Output-Octets = 1361 > Acct-Input-Packets = 90 > Acct-Output-Packets = 113 > Acct-Multi-Session-Id = "0000002c" > Service-Type = Framed-User > Framed-Protocol = PPP > Framed-IP-Address = 209.198.86.32 > Acct-Delay-Time = 0 > > I'm looking for information like what nas it really came from, what port > it used, the slot/span/channel used, etc. Is there a way to do this? yes, you need support for vendor specific attributes. We are using Radiator http://www.open.com.au/radiator and ours looks like this: Fri Jul 24 09:23:52 1998 User-Name = "syrinx" Client-Id = 208.206.76.35 Acct-Status-Type = Start Acct-Session-Id = "37471204" Acct-Delay-Time = 0 Acct-Authentic = RADIUS User-Service-Type = Framed-User NAS-Port-Type = 0 Client-Port-Id = 1299 USR-Mystery-1 = "<0><0><8><251>" USR-Chassis-Call-Slot = 5 USR-Chassis-Call-Span = 1 USR-Chassis-Call-Channel = 19 USR-Unauthenticated-Time = 7 Calling-Station-Id = "3183752813" Called-Station-Id = "3182134600" USR-Modulation-Type = x2 USR-Simplified-MNP-Levels = ccittV42SREJ USR-Simplified-V42bis-Usage = ccittV42bis USR-Connect-Speed = 33411656 Framed-Protocol = PPP Framed-Address = 208.214.44.124 USR-MP-MRRU = 0 USR-Mystery-2 = "<0><0><0><2>" Acct-Multi-Session-Id = "43d1" Timestamp = 901290232

Has anyone been able to get anymore information from the netserver when it makes a mpip connection? This is what I get for the second channel. Acct-Session-Id = "0f000062" User-Name = "Pfhege" NAS-IP-Address = 207.136.192.240 NAS-Port = 6000 Acct-Status-Type = Stop Acct-Session-Time = 75 Acct-Terminate-Cause = Lost-Carrier Acct-Authentic = 0 Called-Station-Id = "" USR-Unauthenticated-Time = 0 NAS-Identifier = "usr0.noc" Acct-Input-Octets = 331 Acct-Output-Octets = 1361 Acct-Input-Packets = 90 Acct-Output-Packets = 113 Acct-Multi-Session-Id = "0000002c" Service-Type = Framed-User Framed-Protocol = PPP Framed-IP-Address = 209.198.86.32 Acct-Delay-Time = 0 I'm looking for information like what nas it really came from, what port it used, the slot/span/channel used, etc. Is there a way to do this? Thanks -Dale

The GTD5 more closely resembles an AT&T 5ESS switch. I had about 20 of these switches when I worked for sprint. W econfigured all chassis PRI's for 5ESS Eric Forcey <eric@psnw.com> on 07/28/98 11:00:45 AM Please respond to usr-tc@lists.xmission.com cc: Anyone ever heard of a GTD5 switch? I'm trying to turn up a new circuit in GTE Calif territory and the switch they are using is a GTD5. I have a call into support, and they think that it is the same as a DMS100, however they were not sure. I show carrier on the line, however I am getting an error light on the chassis that of amber in the LPBK/D-ALM position. Support says that it is a loss of D-Channel, but this is not a PRI circuit, it is a CT1 so the D-Channel shouldn't matter there. Any help would be appreciated. Thanks, Eric - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

> I'm trying to turn up a new circuit in GTE Calif territory and the switch > they are using is a GTD5. > > I have a call into support, and they think that it is the same as a > DMS100, however they were not sure. > > I show carrier on the line, however I am getting an error light on the > chassis that of amber in the LPBK/D-ALM position. Support says that it is > a loss of D-Channel, but this is not a PRI circuit, it is a CT1 so the > D-Channel shouldn't matter there. Make sure the T1 settings on the HDM are set to ROBBED BIT. | Curtis V. Shambeau | curt@execpc.com | http://www.execpc.com/~curt | | Executive Vice President - Exec-PC, Inc. |

After months of continuous problems with our two NETServerI/16, our 3Com vendor has agreed to replace them with: 1. TC Hub 2. Quad modems, 3. dual PRI card 4. Netserver card. I've read in this list that people should be purchasing HiperARC (?) instead of the Netserver card. Is this correct? All we want is a stable dial-up pool of modems. Should we request a HiperARC card from our vendor instead of a Netserver card? Thanx in advance for any pointers. fbsd

Sure enough. It was set to 576. Thought we had set this to 1500 along time ago. Everything seems to be working fine. Thanks all. > > > What is the mtu of these users? > make sure the mtu is set to 1500 > > krish > Mark Pansing Infinet Engineering Staff (614) 848-4638 x203 markp@infinet.com

Thanks for the correction, MZ. I followed the instructions at http://interproc.ae.usr.com (thanks Tatai) and we're in the process of testing it now. Part of the instructions indicated that the Netserver should be at the same software revision. Is that necessary? What problems can I expect? I have two Netservers at 3.5.34 and three at 3.6.28 with the MPIP server on 3.6.28. Any idea on when the HyperArc is going to be able to create MP links across the Netsevers? Kinda defeats the purpose of MP if you have mixed situation like myself. Thanks, Walt Walter N. Gnann ISLC, Manager 843.770.1000 843.770.1002 (fax) wgnann@islc.net http://www.islc.net http://www.beaufortcomputerclub.org -----Original Message----- >Once upon a time Walt Gnann shaped the electrons to say... >>Just a quick question on MLPPP. We can successfully connect and maintain a > >That's "MP" - please don't call it MLPPP, it gets confused with all of the >private acronyms like MCPPP, MMP, MPIP, MCMP, etc. Per RFC it is MP. > >>will not work if the connections are on separate chasis. Can you have a >>MLPPP connection across chasis? How? > >That is where 3Com/USR/s 'MPIP' protocol comes in - it allows MP connections >to bundle across chasis. Most vendors have something along these lines - >Lucent has MCPPP, Ascend has MaxStack, etc. > >-MZ >-- ><URL:mailto:megazone@megazone.org> Gweep, Discordian, Author, Engineer, me.. >Join ISP/C Internet Service Providers' Consortium <URL:http://www.ispc.org/> >"A little nonsense now and then, is relished by the wisest men" 781-788-0130 ><URL:http://www.gweep.net/> <URL:http://www.megazone.org/> Hail Discordia! > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

The output you sent looks more like an HARC connection than a netserver. I am looking to get this detailed information from the netserver when it makes an mpip connection. I am also using Radiator and I've been getting VSA's on the non mpip connections. Thanks. -Dale On Tue, 28 Jul 1998, Brian wrote: > On Tue, 28 Jul 1998, Dale Hege wrote: > > > Has anyone been able to get anymore information from the netserver when it > > makes a mpip connection? This is what I get for the second channel. > > > > Acct-Session-Id = "0f000062" > > User-Name = "Pfhege" > > NAS-IP-Address = 207.136.192.240 > > NAS-Port = 6000 > > Acct-Status-Type = Stop > > Acct-Session-Time = 75 > > Acct-Terminate-Cause = Lost-Carrier > > Acct-Authentic = 0 > > Called-Station-Id = "" > > USR-Unauthenticated-Time = 0 > > NAS-Identifier = "usr0.noc" > > Acct-Input-Octets = 331 > > Acct-Output-Octets = 1361 > > Acct-Input-Packets = 90 > > Acct-Output-Packets = 113 > > Acct-Multi-Session-Id = "0000002c" > > Service-Type = Framed-User > > Framed-Protocol = PPP > > Framed-IP-Address = 209.198.86.32 > > Acct-Delay-Time = 0 > > > > I'm looking for information like what nas it really came from, what port > > it used, the slot/span/channel used, etc. Is there a way to do this? > > yes, you need support for vendor specific attributes. > > We are using Radiator http://www.open.com.au/radiator > > and ours looks like this: > > Fri Jul 24 09:23:52 1998 > User-Name = "syrinx" > Client-Id = 208.206.76.35 > Acct-Status-Type = Start > Acct-Session-Id = "37471204" > Acct-Delay-Time = 0 > Acct-Authentic = RADIUS > User-Service-Type = Framed-User > NAS-Port-Type = 0 > Client-Port-Id = 1299 > USR-Mystery-1 = "<0><0><8><251>" > USR-Chassis-Call-Slot = 5 > USR-Chassis-Call-Span = 1 > USR-Chassis-Call-Channel = 19 > USR-Unauthenticated-Time = 7 > Calling-Station-Id = "3183752813" > Called-Station-Id = "3182134600" > USR-Modulation-Type = x2 > USR-Simplified-MNP-Levels = ccittV42SREJ > USR-Simplified-V42bis-Usage = ccittV42bis > USR-Connect-Speed = 33411656 > Framed-Protocol = PPP > Framed-Address = 208.214.44.124 > USR-MP-MRRU = 0 > USR-Mystery-2 = "<0><0><0><2>" > Acct-Multi-Session-Id = "43d1" > Timestamp = 901290232 > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

On Tue, 28 Jul 1998, Stefanita Valcu wrote: > Hi, > I am looking for a radius version able to spawn an external program which > can give some suplementarry attributes to the NAS. I.e. we have users with > access only between 11pm and 8am and I want that the external program to > give to the radius server something like session-timeout= xx where xx in > the number of seconds until 8am. This program could be a real-time > interface to a SQL database written in perl. Radiator supports a check attribute that allows you to limit access for any time/date range. And its already integrated with SQL, and fully extensable via perl http://www.open.com.au/radiator > > The second question is if there are patches for USR Vendor Specific > Attributes for the Cistron Radius. Actually we are using Merit which is > a little too slow. The NAS-es are USR Total Control, cisco and > Livingston. > > I am looking only for free software running on Unix. > > TIA, > > -vsv > --- > Stefanita Valcu, http://www.dnt.ro/~vsv > Network Administrator, Dynamic Network Technologies > Calea Victoriei 155, bl.D1, sc.7, et.3, sector 1, 71102, Bucuresti, Romania > tel: +40-1-6590696, fax: +40-1-3122745, E-mail: vsv@dnt.ro > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > Brian Feeny (BF304) | ShreveNet Inc. - Premium Internet Service Provider Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1

On Tue, 28 Jul 1998, Stefanita Valcu wrote: > Hi, > I am looking for a radius version able to spawn an external program which > can give some suplementarry attributes to the NAS. I.e. we have users with > access only between 11pm and 8am and I want that the external program to > give to the radius server something like session-timeout= xx where xx in > the number of seconds until 8am. This program could be a real-time > interface to a SQL database written in perl. Radiator supports a check attribute that allows you to limit access for any time/date range. And its already integrated with SQL, and fully extensable via perl http://www.open.com.au/radiator > > The second question is if there are patches for USR Vendor Specific > Attributes for the Cistron Radius. Actually we are using Merit which is > a little too slow. The NAS-es are USR Total Control, cisco and > Livingston. > > I am looking only for free software running on Unix. > > TIA, > > -vsv > --- > Stefanita Valcu, http://www.dnt.ro/~vsv > Network Administrator, Dynamic Network Technologies > Calea Victoriei 155, bl.D1, sc.7, et.3, sector 1, 71102, Bucuresti, Romania > tel: +40-1-6590696, fax: +40-1-3122745, E-mail: vsv@dnt.ro > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > Brian Feeny (BF304) | ShreveNet Inc. - Premium Internet Service Provider Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1

Is there a similar command on the NetServers? I'm going to play with the radius / hiper today and see if I can get some "snoops". Randy > -----Original Message----- > From: owner-usr-tc@lists.xmission.com > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Tatai SV Krishnan > Sent: Monday, July 27, 1998 12:28 AM > To: Randy Cosby > Cc: usr-tc@lists.xmission.com > Subject: Re: (usr-tc) Timeouts.. > > > Yes there is a default user on the hiper arc where you can set the idle > and session timeout > > set net user default idle " " > > krish > > ----------------------------------------- > \ T.S.V. Krishnan \ > \ Network System Engineer \ ( : - : ) > \ 3Com ............ \ > ----------------------------------------------/ > tkrishna@bubba.ae.usr.com > ----------------------------/ http://interproc.ae.usr.com ----/ > The Yadda Yadda Search - for simple anwers - > http://interproc.ae.usr.com/tkb.html > > -------------------------------------------------------------------------\ > Any Sufficiently advanced bug is indistinguishable for a feature. > - Rick Kulawiec > -------------------------------------------------------------------------/ > > On Mon, 27 Jul 1998, Randy Cosby wrote: > > > Is anyone applying Session-Timeout and Idle-Timeout's with TC racks > > (netserver or > > HiperArc) via Radius? Mine seem to be ignored. Is there a default user > > timeout/idle timeout that can be set on the HiperARC? > > > > thanks, > > > > Randy Cosby <dcosby@infowest.com> > > Vice President > > InfoWest Global Internet Services, Inc. > > (435)674-0165 http://www.infowest.com > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

I think the NMC tries to autoselect the media type (AUI, BNC, TP) when it starts up. If no cable is present, what is the default? I want the ability to set the default media type to TP. -CH On Tue, 28 Jul 1998, Kevin Benton wrote: > FYI for y'all: > > If an NMC is powered up without the Ethernet (10bT) cable plugged in, the > Ethernet (10bT) port will be disabled even if an Etherent cable is plugged > in later. From what I'm told, if a cable is unplugged, then plugged back > in, the port is *not* disabled. A feature request has been added to not > disable the Ethernet port on power up if no cable is present even though > the LAN Power-Up setting is Enable. > > Kevin Benton > Network Engineer > SOTA Technologies > > E-Mail: s1kevin@tims.net > Web: http://users.sota-oh.com/~s1kevin/ > Unsolicited advertisements processing fee: $50 subject to change without notice > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Brian was heard to say: > USR-Mystery-1 = "<0><0><8><251>" > USR-Mystery-2 = "<0><0><0><2>" #1 is USR-MP-EDO #2 is USR-MP-LinkCount (Yes, even USR's RADIUS server (4.3.11) complains about those two as I never have put them in the dictionary. [0x9025 and 0x9026, IIRC]) --Ricky

I've got a 2059 chassis with 6 digital and 6 A/D quad modem cards in it. the 6 digital are fed calls by a CT1 and the 6 A/D are fed calls by analog lines into the analog nics. the First digital call in slot 2 will not answer the phone i've switched card around triple checked all the settings rebooted the chassis to no avail. Anyone seen this? U.S. Robotics 17-Slot Chassis tc0 <205.138.54.75> 1 3COM PRI-T1/E1 NAC 4.0.0 4096 1024 0000000000000000 4.2.1 2 3COM Quad V.34 Digital Modem NAC 3.0.0 0 0 0000000110001000 5.10.9 3 3COM Quad V.34 Digital Modem NAC 3.0.0 0 0 0000000110001000 5.10.9 4 3COM Quad V.34 Digital Modem NAC 3.0.0 0 0 0000000110001000 5.10.9 5 3COM Quad V.34 Digital Modem NAC 3.0.0 0 0 0000000110001000 5.10.9 6 3COM Quad V.34 Digital Modem NAC 3.0.0 0 0 0000000110001000 5.10.9 7 3COM Quad V.34 Digital Modem NAC 3.0.0 0 0 0000000110001000 5.10.9 8 3COM Quad V.34 Digital-Analog Modem NAC 3.0.0 0 0 0000000110001000 5.10.9 9 3COM Quad V.34 Digital-Analog Modem NAC 3.0.0 0 0 0000000110001000 5.10.9 10 3COM Quad V.34 Digital-Analog Modem NAC 3.0.0 0 0 0000000110001000 5.10.9 11 3COM Quad V.34 Digital-Analog Modem NAC 3.0.0 0 0 0000000110001000 5.10.9 12 3COM Quad V.34 Digital-Analog Modem NAC 3.0.0 0 0 0000000110001000 5.10.9 13 3COM Quad V.34 Digital-Analog Modem NAC 3.0.0 0 0 0000000110001000 5.10.9 16 3COM ISDN NETServer NAC 7.0.0 8192 2048 0000000000000000 3.7.24 17 3COM Network Management Card 3.0 4096 2048 0000000000010000 5.4.95 1 3COM Bellcore Long Haul Dual T1 NIC 4096 1024 0000000000000000 8 3COM Quad Modem Analog NIC v1 0 0 0000000110001000 1.1.0 9 3COM Quad Modem Analog NIC v1 0 0 0000000110001000 1.1.0 10 3COM Quad Modem Analog NIC v1 0 0 0000000110001000 1.1.0 11 3COM Quad Modem Analog NIC v1 0 0 0000000110001000 1.1.0 12 3COM Quad Modem Analog NIC v1 0 0 0000000110001000 1.1.0 13 3COM Quad Modem Analog NIC v1 0 0 0000000110001000 1.1.0 16 3COM High Speed Ethernet (with V.35) NIC 8192 2048 0000000000000000 17 3COM Ethernet NIC 0 0 0000000000000000 TIA -Dave

Kevin Benton <s1kevin@tims.net> writes: > If an NMC is powered up without the Ethernet (10bT) cable plugged in, the > Ethernet (10bT) port will be disabled even if an Etherent cable is plugged > in later. From what I'm told, if a cable is unplugged, then plugged back > in, the port is *not* disabled. A feature request has been added to not > disable the Ethernet port on power up if no cable is present even though > the LAN Power-Up setting is Enable. This isn't the ethernet port getting disabled, it's the NMC auto-detection of the cable type. Unfortunately, in the absence of any cable, the default is the 10base2 (thinnet) connector, which may arguably have been somewhat reasonable back in '94, but certainly not today :-) This auto-detection is only done at startup, which is why as long as you have a working cable at startup that you can unplug and replug it as often as you like while the NMC remains operations. Also unfortunately there is no way to program in a default connector (something like what was eventually added to the NETServer code which used to have the same auto-detect logic), although that's been a request of mine for a while. -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | ANS Communications, Inc. \ Phone: (914) 701-5327 | / 100 Manhattanville Rd, Purchase, NY 10577 \ Fax: (914) 701-5310 \ \-----------------------------------------------------------------------/

This one has me stumped... On three of our USRTC chassis, one is using the HiPer Arc, we are having connection problems. Basically a user will dial in and after authentication, the error msg..."dial up networking could not negotiate a compatible set of network protocols you specified....blablabla" This only happens to 2 or 3 ports on the device. If I have someone physically reset the card, the problem goes away. Then, the problem comes back on a different ports. arggg.. I thought maybe it was due to a problem with the V.90 firmware, but the most problematic chassis is a HiPer Arc, and is not even X2 enabled. I have double checked settings and they all seem to match other modems (DSP's), that are working, configurations. If anyone has any suggestions I would greatly appreciate it. Thanks, =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Jason Watkins I-Land Support & NOC Tech jwatkins@iland.net http://www.iland.net =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

This is a multi-part message in MIME format. ------=_NextPart_000_0020_01BDBA41.E9824070 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Using the cable access router card (a souped-up hiper card, same syntax on most things), I verified and then applied the following filter to the QAM:1 outgoing interface: HiPerCMTS>> show filter windows.fil RULES FOR FILTER /./windows.fil SHOW PROTOCOLS: ALL #filter IP: 010 REJECT udp-dst-port = 137; 020 REJECT udp-dst-port = 138; 030 REJECT tcp-dst-port = 139; 040 REJECT udp-src-port = 139; 050 REJECT udp-src-port = 138; 060 REJECT tcp-src-port = 137; This should block use of windows file sharing: (from windows nt services file) nbname 137/udp nbdatagram 138/udp nbsession 139/tcp But, alas, it doesn't. I've tried applying the same filter to the ehternet incoming interface as well. No luck. Any clues? Randy Cosby <dcosby@infowest.com> Vice President InfoWest Global Internet Services, Inc. (435)674-0165 http://www.infowest.com ------=_NextPart_000_0020_01BDBA41.E9824070 Content-Type: application/octet-stream; name="Randy Cosby.vcf" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="Randy Cosby.vcf" BEGIN:VCARD VERSION:2.1 N:Cosby;Randy FN:Randy Cosby ORG:InfoWest Global Internet Services, Inc. TITLE:Vice President NOTE;ENCODING=3DQUOTED-PRINTABLE:What do I do? =3D0D=3D0A=3D0D=3D0AVice = President, InfoWest =3D0D=3D0AAreas of responsib=3D ility include: Research, Development, communications services = http://www.inf=3D owest.com=3D0D=3D0A=3D0D=3D0AWeb Site = Manager=3D0D=3D0Ahttp://www.devshed.com=3D0D=3D0Ahttp:=3D //www.32bit.com=3D0D=3D0A=3D0D=3D0AUtah's first Internet-over-cable: = iCable=3D0D=3D0Ahtt=3D p://www.icable.net=3D0D=3D0A=3D0D=3D0AWhat can I do for you? TEL;WORK;VOICE:(435) 674-0165 TEL;WORK;FAX:(435) 674-9734 ADR;WORK:;;1845 West Sunset Boulevard;St. George;UT;84770;United States = of America LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:1845 West Sunset = Boulevard=3D0D=3D0ASt. George, UT 84770=3D0D=3D0AUnited States of A=3D merica URL: URL:http://www.infowest.com EMAIL;PREF;INTERNET:dcosby@infowest.com REV:19980630T225731Z END:VCARD ------=_NextPart_000_0020_01BDBA41.E9824070--

Can't get ARC to speak RIPv2. Our static IP users depend on that. Strangely, I had it working before, but now that I upgraded to 4.0.30 and had to delete all my previous config, I cannot get it working again. Below is a "show ip network IP" What's wrong? Where to look? ------- Forwarded Message Follows ------- SHOW IP NETWORK IP SETTINGS: Interface: eth:1 Network Address: 194.106.96.241/28 Frame Type: ETHERNET_II Status: ENABLED Reconfigure Needed: FALSE Mask: 255.255.255.240 Station: 194.106.96.241 Broadcast Algorithm: IETF Max Reassembly Size: 3468 IP Routing Protocol: RIPV2 IP RIP Routing Policies: SEND_ROUTES SEND_SUBNETS SPLIT_HORIZON POISON_REVERSE FLASH_UPDATE RIPV2_RECEIVE IP RIP Authentication Key: ---------------------------------------------------------------------- Andres Kroonmaa mail: andre@online.ee Network Manager Organization: MicroLink Online Tel: 6308 909 Tallinn, Sakala 19 Pho: +372 6308 909 Estonia, EE0001 http://www.online.ee Fax: +372 6308 901 ----------------------------------------------------------------------

Can't get ARC to speak RIPv2. Our static IP users depend on that. Strangely, I had it working before, but now that I upgraded to 4.0.30 and had to delete all my previous config, I cannot get it working again. Below is a "show ip network IP" What's wrong? Where to look? ------- Forwarded Message Follows ------- SHOW IP NETWORK IP SETTINGS: Interface: eth:1 Network Address: 194.106.96.241/28 Frame Type: ETHERNET_II Status: ENABLED Reconfigure Needed: FALSE Mask: 255.255.255.240 Station: 194.106.96.241 Broadcast Algorithm: IETF Max Reassembly Size: 3468 IP Routing Protocol: RIPV2 IP RIP Routing Policies: SEND_ROUTES SEND_SUBNETS SPLIT_HORIZON POISON_REVERSE FLASH_UPDATE RIPV2_RECEIVE IP RIP Authentication Key: ---------------------------------------------------------------------- Andres Kroonmaa mail: andre@online.ee Network Manager Organization: MicroLink Online Tel: 6308 909 Tallinn, Sakala 19 Pho: +372 6308 909 Estonia, EE0001 http://www.online.ee Fax: +372 6308 901 ----------------------------------------------------------------------

From the CARC command line: HiPerCMTS>> set interface qam:1 outpUT_FILTER "windows.fil" HiPerCMTS>> show interface qam:1 INTERFACE qam:1 SETTINGS Description: GWC QAM Driver Type: INVALID Speed: 0 High Speed: 0 Administrative Status: Up Operational Status: Up Link Up/Down Traps: ENABLED Promiscuous Mode: FALSE Connector Present: TRUE Filter Access: ON Last Change: 0d 00:00:49 Input Filter: Output Filter: windows.fil HiPerCMTS>> --- NT box on network looking at the ip of a cable modem: C:\>net view \\xxx.xxx.xxx.xxx Shared resources at \\xxx.xxx.xxx.xxx . Share name Type Used as Comment C Disk D Disk DESKTOP Disk E Disk F Disk G Disk H Disk I Disk J Disk K Disk The command completed successfully C:\> > -----Original Message----- > From: owner-usr-tc@lists.xmission.com > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of mike > Sent: Tuesday, July 28, 1998 5:12 PM > To: usr-tc@lists.xmission.com > Subject: Re: (usr-tc) Filtering Windows File sharing.. > > > > On Tue, 28 Jul 1998, Randy Cosby wrote: > > >Using the cable access router card (a souped-up hiper card, same > syntax on > >most things), I verified and then applied the following filter > to the QAM:1 > >outgoing interface: > > > >HiPerCMTS>> show filter windows.fil > > > >RULES FOR FILTER /./windows.fil SHOW PROTOCOLS: ALL > >#filter > >IP: > >010 REJECT udp-dst-port = 137; > >020 REJECT udp-dst-port = 138; > >030 REJECT tcp-dst-port = 139; > >040 REJECT udp-src-port = 139; > >050 REJECT udp-src-port = 138; > >060 REJECT tcp-src-port = 137; > > > >This should block use of windows file sharing: > >(from windows nt services file) > >nbname 137/udp > >nbdatagram 138/udp > >nbsession 139/tcp > > > >But, alas, it doesn't. I've tried applying the same filter to > the ehternet > >incoming interface as well. No luck. Any clues? > > > > > Check that filter access is on for the QAM port.. > -M > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

On Tue, 28 Jul 1998, Chuck Simons wrote: >You guys are doing better than I am, I have yet to get a mp connection up >and running on an NT box. >I think the problem is on the USR side. Everyone on the list tells me, There >is no configuration thats need to be done on the USR box. Hence, they think >it's the NT side. >I have heard to verify that "set mp on" has been done on the USR end. >Problem is, "set mp on" generates an error when I type it in after telneting >to the netserver. > What version of code are you running? Also, do the following and send me the output.. set debug 0x51 set console -start logging the screen output -make an attempt at a MP call. -Stop logging reset console -Mike

On Tue, 28 Jul 1998, Randy Cosby wrote: >Using the cable access router card (a souped-up hiper card, same syntax on >most things), I verified and then applied the following filter to the QAM:1 >outgoing interface: > >HiPerCMTS>> show filter windows.fil > >RULES FOR FILTER /./windows.fil SHOW PROTOCOLS: ALL >#filter >IP: >010 REJECT udp-dst-port = 137; >020 REJECT udp-dst-port = 138; >030 REJECT tcp-dst-port = 139; >040 REJECT udp-src-port = 139; >050 REJECT udp-src-port = 138; >060 REJECT tcp-src-port = 137; > >This should block use of windows file sharing: >(from windows nt services file) >nbname 137/udp >nbdatagram 138/udp >nbsession 139/tcp > >But, alas, it doesn't. I've tried applying the same filter to the ehternet >incoming interface as well. No luck. Any clues? > > Check that filter access is on for the QAM port.. -M

Hi, I am looking for a radius version able to spawn an external program which can give some suplementarry attributes to the NAS. I.e. we have users with access only between 11pm and 8am and I want that the external program to give to the radius server something like session-timeout= xx where xx in the number of seconds until 8am. This program could be a real-time interface to a SQL database written in perl. The second question is if there are patches for USR Vendor Specific Attributes for the Cistron Radius. Actually we are using Merit which is a little too slow. The NAS-es are USR Total Control, cisco and Livingston. I am looking only for free software running on Unix. TIA, -vsv --- Stefanita Valcu, http://www.dnt.ro/~vsv Network Administrator, Dynamic Network Technologies Calea Victoriei 155, bl.D1, sc.7, et.3, sector 1, 71102, Bucuresti, Romania tel: +40-1-6590696, fax: +40-1-3122745, E-mail: vsv@dnt.ro

Hello I've been checking on 3com's web site and checking the archives of this list. I've found some questions and answers about the hub status led on the NMC, but I want to make sure I understand it. Right now the LED is red. I've been looking all over trying to find out why it's red, but there is none that I can find. I've heard it could be the power supply, but we only have one and it tests OK. I've run the tests, put the IP's in. I can ping it, I can use TCM to get to it. But that darn LED is red and it is starting to bug me :-) Any indication of why it would be red? My next step it to try to swap it with a NMC here and see what happens. Also, as long as I am mentioning it, right now I have all green lights (except for that one red led) and the PRI seems to be set fine and GTE can trace the call to the trunk, but when you dial the lead number you get a fast busy. I've done the set s# active and modem on and some other things, but it's still fast busy. Could this hub status light have anything to do with it? I'll be calling GTE again tomorrow to see if they can run some more tests, but I don't want to yell at them when it's something at my end. ;-) Thanks in advance for any advice. Dan Allen - System Admin. -Novagate Communications Corp.-

Hello, I am currently using MRTG to monitor modem usage on a bunch of netserver based TC hubs. The setup I am using was working out quite well for me until I added a hiper chassis. The method I was using before (interfaces.ifNumber.0 - 1) doesn't seem to work on the HiperARC as it reports all interfaces regarless if they are active or not. Has anyone found a easy way to monitor these things? For reference here is the section of mrtg.cfg that I am currently using to monitor one of our modem pools ( 3 48 port hubs). Target[tcpool]: .1.3.6.1.2.1.2.1.0&.1.3.6.1.2.1.2.1.0:public@netserver1 + .1.3.6.1.2.1.2.1.0&.1.3.6.1.2.1.2.1.0:public@netserver2 + .1.3.6.1.2.1.2.1.0&.1.3.6.1.2.1.2.1.0:public@netserver3 - 3 MaxBytes[tcpool]: 144 Options[tcpool]: gauge, growright Unscaled[tcpool]: dwmy Ylegend[tcpool]: Users Online ShortLegend[tcpool]: Users Legend1[tcpool]: Users Online LegendO[tcpool]: Title[tcpool]: TC Modem Pool PageTop[tcpool]: <H1>Users online</H1> Horace Demmink PathWay Computing

I think all of us would like a copy. -Frank -----Original Message----- Cc: usr-tc@lists.xmission.com <usr-tc@lists.xmission.com> >On Tue, 28 Jul 1998, Horace Demmink wrote: > >> I am currently using MRTG to monitor modem usage on a bunch of netserver >> based TC hubs. The setup I am using was working out quite well for me >> until I added a hiper chassis. The method I was using before >> (interfaces.ifNumber.0 - 1) doesn't seem to work on the HiperARC as it >> reports all interfaces regarless if they are active or not. Has anyone >> found a easy way to monitor these things? For reference here is the >> section of mrtg.cfg that I am currently using to monitor one of our modem >> pools ( 3 48 port hubs). >> >> Target[tcpool]: .1.3.6.1.2.1.2.1.0&.1.3.6.1.2.1.2.1.0:public@netserver1 >> + .1.3.6.1.2.1.2.1.0&.1.3.6.1.2.1.2.1.0:public@netserver2 + >> .1.3.6.1.2.1.2.1.0&.1.3.6.1.2.1.2.1.0:public@netserver3 - 3 >> MaxBytes[tcpool]: 144 >> Options[tcpool]: gauge, growright >> Unscaled[tcpool]: dwmy >> Ylegend[tcpool]: Users Online >> ShortLegend[tcpool]: Users >> Legend1[tcpool]: Users Online >> LegendO[tcpool]: >> Title[tcpool]: TC Modem Pool >> PageTop[tcpool]: <H1>Users online</H1> > >Hey - this is great! I'm implementing it on our system. :) Thanks! I'd >be happy to find out how you do that with the the ARC's as well. If they >reply directly to you but don't put in on the list, could you forward a >copy to me? Thanks :) > >Kevin > >E-Mail: s1kevin@tims.net >Web: http://users.sota-oh.com/~s1kevin/ >Unsolicited advertisements processing fee: $50 subject to change without notice > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

On Tue, 28 Jul 1998, Horace Demmink wrote: > I am currently using MRTG to monitor modem usage on a bunch of netserver > based TC hubs. The setup I am using was working out quite well for me > until I added a hiper chassis. The method I was using before > (interfaces.ifNumber.0 - 1) doesn't seem to work on the HiperARC as it > reports all interfaces regarless if they are active or not. Has anyone > found a easy way to monitor these things? For reference here is the > section of mrtg.cfg that I am currently using to monitor one of our modem > pools ( 3 48 port hubs). > > Target[tcpool]: .1.3.6.1.2.1.2.1.0&.1.3.6.1.2.1.2.1.0:public@netserver1 > + .1.3.6.1.2.1.2.1.0&.1.3.6.1.2.1.2.1.0:public@netserver2 + > .1.3.6.1.2.1.2.1.0&.1.3.6.1.2.1.2.1.0:public@netserver3 - 3 > MaxBytes[tcpool]: 144 > Options[tcpool]: gauge, growright > Unscaled[tcpool]: dwmy > Ylegend[tcpool]: Users Online > ShortLegend[tcpool]: Users > Legend1[tcpool]: Users Online > LegendO[tcpool]: > Title[tcpool]: TC Modem Pool > PageTop[tcpool]: <H1>Users online</H1> Hey - this is great! I'm implementing it on our system. :) Thanks! I'd be happy to find out how you do that with the the ARC's as well. If they reply directly to you but don't put in on the list, could you forward a copy to me? Thanks :) Kevin E-Mail: s1kevin@tims.net Web: http://users.sota-oh.com/~s1kevin/ Unsolicited advertisements processing fee: $50 subject to change without notice

On Tue, 28 Jul 1998, Horace Demmink wrote: > I am currently using MRTG to monitor modem usage on a bunch of netserver > based TC hubs. The setup I am using was working out quite well for me > until I added a hiper chassis. The method I was using before > (interfaces.ifNumber.0 - 1) doesn't seem to work on the HiperARC as it > reports all interfaces regarless if they are active or not. Has anyone > found a easy way to monitor these things? For reference here is the > section of mrtg.cfg that I am currently using to monitor one of our modem > pools ( 3 48 port hubs). > > Target[tcpool]: .1.3.6.1.2.1.2.1.0&.1.3.6.1.2.1.2.1.0:public@netserver1 > + .1.3.6.1.2.1.2.1.0&.1.3.6.1.2.1.2.1.0:public@netserver2 + > .1.3.6.1.2.1.2.1.0&.1.3.6.1.2.1.2.1.0:public@netserver3 - 3 Make sure that your community string is correct for the ARC. It will work, just that you need to be sure you have access to that chassis from your machineand that you've got the right community. I learned how to count users from the above, and with what you showed me, I applied it to my own NetServers and ARC's. This is great! :) Kevin E-Mail: s1kevin@tims.net Web: http://users.sota-oh.com/~s1kevin/ Unsolicited advertisements processing fee: $50 subject to change without notice

A copy of ??? On Wed, 29 Jul 1998, Frank Basso wrote: > Date: Wed, 29 Jul 1998 09:32:56 -0700 > From: Frank Basso <frank@got.net> > Reply-To: usr-tc@lists.xmission.com > To: usr-tc@lists.xmission.com > Subject: Re: (usr-tc) MRTG with HiperARC > > I think all of us would like a copy. > > -Frank > -----Original Message----- > From: Kevin Benton <s1kevin@tims.net> > To: Horace Demmink <horace@pathwaynet.com> > Cc: usr-tc@lists.xmission.com <usr-tc@lists.xmission.com> > Date: Wednesday, July 29, 1998 8:17 AM > Subject: Re: (usr-tc) MRTG with HiperARC > > > >On Tue, 28 Jul 1998, Horace Demmink wrote: > > > >> I am currently using MRTG to monitor modem usage on a bunch of netserver > >> based TC hubs. The setup I am using was working out quite well for me > >> until I added a hiper chassis. The method I was using before > >> (interfaces.ifNumber.0 - 1) doesn't seem to work on the HiperARC as it > >> reports all interfaces regarless if they are active or not. Has anyone > >> found a easy way to monitor these things? For reference here is the > >> section of mrtg.cfg that I am currently using to monitor one of our modem > >> pools ( 3 48 port hubs). > >> > >> Target[tcpool]: .1.3.6.1.2.1.2.1.0&.1.3.6.1.2.1.2.1.0:public@netserver1 > >> + .1.3.6.1.2.1.2.1.0&.1.3.6.1.2.1.2.1.0:public@netserver2 + > >> .1.3.6.1.2.1.2.1.0&.1.3.6.1.2.1.2.1.0:public@netserver3 - 3 > >> MaxBytes[tcpool]: 144 > >> Options[tcpool]: gauge, growright > >> Unscaled[tcpool]: dwmy > >> Ylegend[tcpool]: Users Online > >> ShortLegend[tcpool]: Users > >> Legend1[tcpool]: Users Online > >> LegendO[tcpool]: > >> Title[tcpool]: TC Modem Pool > >> PageTop[tcpool]: <H1>Users online</H1> > > > >Hey - this is great! I'm implementing it on our system. :) Thanks! I'd > >be happy to find out how you do that with the the ARC's as well. If they > >reply directly to you but don't put in on the list, could you forward a > >copy to me? Thanks :) > > > >Kevin > > > >E-Mail: s1kevin@tims.net > >Web: http://users.sota-oh.com/~s1kevin/ > >Unsolicited advertisements processing fee: $50 subject to change without > notice > > > > > >- > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > E-Mail: s1kevin@tims.net Web: http://users.sota-oh.com/~s1kevin/ Unsolicited advertisements processing fee: $50 subject to change without notice

Well my .02 worth :) http://www.ac.net/modemuse/

It still didn't work but thanks for the effort. Liping -----Original Message----- [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Curt Shambeau Sent: Monday, July 27, 1998 5:24 PM > I have a trunk T-1 when connected to a dual T-1, Quad modems and netserver > bundle, > I get X2 and V.90, 56K. > > When I move the T-1 to a DSP on a hyper bundle chassis, only V.34, 33.6bps. Probably need to restore defaults on the HDM. I have had similar instances when flashing new code will put the settings for v.90, x2, etc in a disable mode. Check the 'modulation settings' or something like that via TCM on the modems of the HDM. You'll probably see a whole bunch of disabled features. A full "restore from defaults" on the HDM should fix it. | Curtis V. Shambeau | curt@execpc.com | http://www.execpc.com/~curt | | Executive Vice President - Exec-PC, Inc. | - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

It still didn't work but thanks for the effort. Liping -----Original Message----- [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Curt Shambeau Sent: Monday, July 27, 1998 5:24 PM > I have a trunk T-1 when connected to a dual T-1, Quad modems and netserver > bundle, > I get X2 and V.90, 56K. > > When I move the T-1 to a DSP on a hyper bundle chassis, only V.34, 33.6bps. Probably need to restore defaults on the HDM. I have had similar instances when flashing new code will put the settings for v.90, x2, etc in a disable mode. Check the 'modulation settings' or something like that via TCM on the modems of the HDM. You'll probably see a whole bunch of disabled features. A full "restore from defaults" on the HDM should fix it. | Curtis V. Shambeau | curt@execpc.com | http://www.execpc.com/~curt | | Executive Vice President - Exec-PC, Inc. | - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

Well guys - this one's for the pro's out there... We recently moved our Netserver/quads from digital to analog ( replaced them with the hiperARC\dsp combo's ) in place of our old Annex/multitech box's in order to better faciltate our RADIUS needs. ( Annex's don't do RADIUS well). So... we removed the T1 cards, set the modems to the nic and turned the whole mess on. Works fine except..... constant complaits of people being disconnected. Loss of carrier seems to be the dominant reason. I went through this with multitech modems and ended up adjusting transmitter levels. That's the Black Majic part. I remember all too well helping one customer only to have created other trouble in doing this. The transmitter levels are at 11db. I would imagine this is a negative level? So anyone cares to give me a little insight as to how yours are set, if they are different at all, I would appreciate it. I have already up the carrier loss from 7 to 20. Idle timeout on the modems is shut off. Any ideas aside from messing with these levels? 3.7.24 code on the netserver 5.10.9 code on the modems Terry Kennedy OlyPen, Inc.

On Tue, 28 Jul 1998, Horace Demmink wrote: > > Hello, > > I am currently using MRTG to monitor modem usage on a bunch of netserver > based TC hubs. The setup I am using was working out quite well for me > until I added a hiper chassis. The method I was using before > (interfaces.ifNumber.0 - 1) doesn't seem to work on the HiperARC as it > reports all interfaces regarless if they are active or not. Has anyone > found a easy way to monitor these things? For reference here is the > section of mrtg.cfg that I am currently using to monitor one of our modem > pools ( 3 48 port hubs). Here's what I'm using... Target[hostname]: 1.3.6.1.4.1.429.4.2.1.10.0&1.3.6.1.4.1.429.4.2.1.10.0:community@hostname I don't know if this handles MLPPP right, and one known problem is that if you telnet into the ARC to do maintenance, your telnet connection is counted... but other than that, this seems to work for us. Mike Andrews (MA12) icq 6602506 -------------- mandrews@dcr.net Senior Systems/Network Administrator --- mandrews@termfrost.org Digital Crescent, Frankfort, KY ----- http://www.termfrost.org/ "If Barbie is so popular, why do you have to buy her friends?..." -----BEGIN GEEK CODE BLOCK----- Version: 3.1 GCS/MU d- s: a- C++ UBX++++ P++ L+ !E W+++ N++ K++ w--- O+ M+ V+++ PS+++ PE- Y+ !t !5 !X !R tv- b+ DI++ D++ e++ h++ r++ y++*@ -----END GEEK CODE BLOCK-----

> I am currently using MRTG to monitor modem usage on a bunch of netserver > based TC hubs. The setup I am using was working out quite well for me > until I added a hiper chassis. The method I was using before > (interfaces.ifNumber.0 - 1) doesn't seem to work on the HiperARC as it > reports all interfaces regarless if they are active or not. Has anyone > found a easy way to monitor these things? For reference here is the Noticed the same problem myself - I use snmpwalk -v 1 {device} {commuity} interfaces.ifTable.ifEntry.ifSpeed and parse out any speed above 0 but less than 100000 (to filter out the ethernet interfaces). SGA

Total Control Hub : 16-slot chassis single 110v ac 70Amp power supply, fan tray, ethernet network management card 12 Quad v34 Digital Modem NAC (48 ports total, 56k v.90) Netserver PRI Dual PRI/T1 - supports analog/ISDN Asking $7,500 for above bundle. OR separately: Quad v34 Digital Modem NAC $500 Analog/Digital Modem NIC/NAC $1,000 Netserver PRI $900 Dual PRI/T1 $900 USR Courier v.90 ext . modem $150 70 amp Power Supply $800 All products are used and in excellent condition. Buyer is responsible for shipping. Contact brwiser@xmission.com, or call Brian at 801-539-0852, extension 131. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= XMission Internet Access | Save a Tree -- Use Email! 51 E. 400 S, Suite 200 | Salt Lake City, UT 84111 | Hardware & Software Sales: Voice 801.539.0852 | http://www.xmission.com/general/retail.html Fax 801.539.0853 | =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 

I think what you really mean is to count up the number of modems in use, right? Looking at the mdmCsStatus tree for onlineAnswer modems makes the most sense to me. It works for HDMs and quads. I've been measuring this object for several months now, and it seems to the best I've found. If I only measure logins, then I'm not really measuring what interests me: I'm really interested in how busy my hunt group is. My sample catches modems in the connect and disconnect phases. Further, if you set some arbitrary connect speed floor, you're going to miss those weird, 9600bps connections. (I'd fire any ISP that didn't let me connect with v.32.) You might want to sample for low-speed connections for other purposes, though. --- Mark R. Lindsey, mark@datasys.net Internet Engineering, DSS Online LLC Voice: 912.241.0607; Fax: 912.241.0190

4.0.29 replies with the total number of interfaces. 4.0.19 replies with the number of *active* interfaces. Would 3Com please either do one of the below? 1) Change it back to the way it was by reporting the number of interfaces in-use, 2) Allow users to select whether or not ...interfaces.0 (as per the previous posts on this list) would reply with the total number of interfaces, or the total number of active interfaces which would help us determine number of active connections, or 3) Give us a totally separate mib entry for the number of channels being used via snmp. My personal preference would be to be able to monitor the number of channels in use on a T1 level, but the above would be acceptable for the intermediate time. Kevin E-Mail: s1kevin@tims.net Web: http://users.sota-oh.com/~s1kevin/ Unsolicited advertisements processing fee: $50 subject to change without notice

On Wed, 29 Jul 1998, Mark R. Lindsey wrote: > I think what you really mean is to count up the number of modems in use, > right? Looking at the mdmCsStatus tree for onlineAnswer modems makes the > most sense to me. It works for HDMs and quads. > > I've been measuring this object for several months now, and it seems to > the best I've found. If I only measure logins, then I'm not really > measuring what interests me: I'm really interested in how busy my hunt > group is. My sample catches modems in the connect and disconnect > phases. > > Further, if you set some arbitrary connect speed floor, you're going to > miss those weird, 9600bps connections. (I'd fire any ISP that didn't let > me connect with v.32.) You might want to sample for low-speed connections > for other purposes, though. Why should I count what the chassis has a very easy time giving to me? My servers have enough work to do polling 14 3com chassis', other dial-up equipment, routers, etc. I have my mrtg refresh rate to once every five minutes. If mrtg isn't done in five minutes, then it's taking way too long. At this point, allowing mrtg to count would take too long. Kevin E-Mail: s1kevin@tims.net Web: http://users.sota-oh.com/~s1kevin/ Unsolicited advertisements processing fee: $50 subject to change without notice

I had the same problem with the hub status led being solid red. I would take the card out of the chassis and let it cool down. When I re-installed it, the problem would go away for a few minutes and then return. The chassis is at the very top of my rack. The rack had a cover. When I removed it the problem went away. Check to see if you have enough space between equipment and proper air flow. It might solve your problem. | Cassandra M. Perkins | People usually get what's coming to | | Network Operations | them... unless it's been mailed. | | The Loop Internet Switch Co., LLC | -fortune | On Tue, 28 Jul 1998, -=X=- wrote: > Hello > > I've been checking on 3com's web site and checking the archives of this > list. I've found some questions and answers about the hub status led on > the NMC, but I want to make sure I understand it. > > Right now the LED is red. I've been looking all over trying to find out > why it's red, but there is none that I can find. I've heard it could be > the power supply, but we only have one and it tests OK. I've run the > tests, put the IP's in. I can ping it, I can use TCM to get to it. But > that darn LED is red and it is starting to bug me :-) > > Any indication of why it would be red? My next step it to try to swap it > with a NMC here and see what happens. > > Also, as long as I am mentioning it, right now I have all green lights > (except for that one red led) and the PRI seems to be set fine and > GTE can trace the call to the trunk, but when you dial the lead > number you get a fast busy. I've done the set s# active and modem on and > some other things, but it's still fast busy. Could this hub status light > have anything to do with it? I'll be calling GTE again tomorrow to see if > they can run some more tests, but I don't want to yell at them when it's > something at my end. ;-) > > Thanks in advance for any advice. > > > Dan Allen - System Admin. > -Novagate Communications Corp.- > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Kevin Benton <s1kevin@tims.net> writes: > Why should I count what the chassis has a very easy time giving to me? I guess it depends on what you want. If you want to know how many IP level interfaces have been instantiated (or defined depending on implementation) on the terminal server, then it's an easy query. But if you're interested in the specific status of your modems (e.g., want to count modems more than interfaces since they may not be the same), or you care about your DS0 availability (again, not necessarily the same as modems or IP interfaces), then that information isn't immediately available at an aggregated level. Might it be useful for the NMC to have some internally aggregated tables that would be available for query externally? Sure. But is it that hard to do the aggregation yourself? Nope. To a large extent "counting users" is an ambiguous request, since exactly what you want to count might be different in different contexts. The Total Control gear has a lot of flexibility at the low level for querying anything you might want, but not as many pre-existing options at the aggregated level. > My > servers have enough work to do polling 14 3com chassis', other dial-up > equipment, routers, etc. I have my mrtg refresh rate to once every five > minutes. If mrtg isn't done in five minutes, then it's taking way too > long. At this point, allowing mrtg to count would take too long. If you're taking anywhere near minutes to poll 14 chassis and other gear, I'm betting that just a few tweaks could get you very large improvements in cycle time - particularly if you have everything serialized at this point. Polling in parallel (possibly with some grouping factor to avoid overloading a local machine or link with traffic bursts, but with only 14 hubs I don't think that's an issue) you should probably be able to poll everything in under 30 seconds - barring timeouts or network lossage requiring retransmission. We ping monitor about 10,000 individual devices from a central location with cycle times well below 5 minutes, and this includes throttles to avoid very high pps rates at the central site. Simultaneously, SNMP polls for all interface statistics of every router in the network (don't have an accurate count, but at least several thousand) with a 5 minute cycle time. Granted, that's with dedicated code, so MRTG's model may force some serialization, but you might be able to make just some small adjustments in terms of parallelization and get pretty good gains in terms of speed. Just for a data point, if you're slightly efficient with your query you can grab all the mdmCsStatus information for a doubled-up chassis (12 quad cards and 2 HDMs) in about 14-15 seconds. Or, if you're interested in DS0 utilization rather than modems, you can grab bulk status objects in about 1-2 seconds even for a fully loaded hub of HDMs. So if you query them in parellel, you should be able to get all 14 hubs in that same 14-15 second period - you just need a small script to do it and then output the single value that MRTG wants. I think there's a pretty lengthy thread available in the archives (mdmCsStatus is in the subject I think) when we last covered a lot of this ground. Given that some of the aggregate information isn't necessarily directly available (good feature request, but you still need to live with what is around), it covers a variety of techniques you can use to get other sorts of info. Of course, individual requirements vary - and if querying the MIB-II interfaces parameter is suitable, it's clearly a great object to plug straight into MRTG. Just don't discount the availability of other info at different granularities just because it might require a little extra processing on the poller side. -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | ANS Communications, Inc. \ Phone: (914) 701-5327 | / 100 Manhattanville Rd, Purchase, NY 10577 \ Fax: (914) 701-5310 \ \-----------------------------------------------------------------------/

We bought two used USR-TC racks months ago and they're on the shelf. The only response I got from USR techs on this USR-TC list was an auto-response saying he was out of the office, and I wasn't high on his list when he got back either. Nada city - they have no idea how coarse an approach this is. These dudes, dragged out from the local employment office, don't know the dues USRobotics paid throughout the BBS generation, and they certainly have to learn the business all over again, no one's reminding them. It's their Execs who should be fired, they defend their support lines with VERY high fees in place of documentation. Who's the rocket-scientist 3Com stuffed-shirt asshole who dreamed up THIS strategy? Wake up, morons, there's a difference between a Sportster modem and a TC Rack! You don't have to blackball EVERYBODY. Best Regards; Dwight G. Jones Imagen Communications Inc. http://www.imagen.net Information Architects tm This from an ISP CEO list: We have also had problems with USR and the NetServer. While we haven't had any bad ports, we have had the problem with ISDN adapters and the ISDN throughput has not been acceptable compared to other equipment. We are also still waiting for the new code for v.90. 3com released the code long ago for the TC units, but the netservers are still on hold. Tech support at 3com is very bad compared to Livingston/Lucent. We were forced to purchase a per incident from 3com simply because a feature that should have been in the documentation was not (we simply wanted to disable the ISDN on a few ports for hunting reasons). We were forced to pay $250 for the necessary information that should have been in the documentation.. not to mention being on hold for hours and numerous call backs and such nonsense. In contrast, Tech support at Livingston/Lucent is great... we have a few PM2s and have only had to call twice, but both times were a pleasant experience (as pleasant as these things can go). -----Original Message-----

I care ALOT. Actually I'm very frustrated with the hype 3com has created about their VOIP solution. Every 3com web page basically says it is available now. However, I cannot get one person over at 3com to tell me where/when/if it is even available. In my opinion VOIP will be how we ISPs will compete with cable modems and other broadband access technologies that we will not have access too. When your customers can get 2/mbs through there cable company for the same price as a 56k connect through you.. well, what would you choose?? Value added service/bundling of new services will be the only way to compete + we will be the ones who will be able to deliver these new services first! Scott > Is it just me, or is it really starting to seem like IP telephony is all > NAS vendors care about nowadays?? > > Is it just me, or do none of the ISP's out there actually care about this? > > Maybe I'm just smoking crack, or haven't had my morning caffeine fix... > > (And I'm not singling 3com out here.) > > > Mike Andrews (MA12) icq 6602506 -------------- mandrews@dcr.net > Senior Systems/Network Administrator --- mandrews@termfrost.org > Digital Crescent, Frankfort, KY ----- http://www.termfrost.org/ > "If Barbie is so popular, why do you have to buy her friends?..." > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

I am starting to DETEST 3Com/USR ... If we could do it again .. livingston would be beside me ... I have yet to have a straight answer from them and they have never fixed any of my problems ... -----Original Message----- Assholes! > >> It's their Execs who should be fired, they defend their support lines >> with VERY high fees in place of documentation. Who's the >> rocket-scientist 3Com stuffed-shirt asshole who dreamed up THIS >> strategy? > >Amen. > >We're waiting on replacment parts for our racks. In their infinite >wisdom, they've decided to do all replacements out of SINGAPORE (we're in >Australia). We have to make international phone calls to talk to them >(we can't - our phones/faxes are ISD barred). They e-mail us attachments >we can't read. They tell us our product doesn't exist. > >They tell us their standard warranty arrangements for TC class equipment >is to have us return the faulty component and wait up to 30 days for a >replacement. They should realise they're not selling $200 modems here, >it's 'high end' server equipment and a 30-day RTB warranty isn't worth >sh*t. > >They told us we'd have to move to a support contract sometime in the >future, but they never bothered to tell us just when that was happening or >what the deal would be. > >> In contrast, Tech support at Livingston/Lucent is great... we have a few >> PM2s and have only had to call twice, but both times were a pleasant >> experience (as pleasant as these things can go). > >We've already reminded 3COM that we won't be buying any more of their >equipment unless things improve. Livingston is looking very attractive at >this stage, and to that end we've already made enquiries with a view to >purchasing their equipment instead. > >...now when USR was USR, things were great - at least they were here in Oz >- can't speak for the rest of the world. 3COM downsized most of the USR >employees out of existance in Australia :-( > >Regards, > >Bob Purdon, >Technical Manager, >Southern Internet Services. > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

On Thu, 30 Jul 1998, Brian wrote: > Interview with 3Com's CEO in this weeks InternetWeek magazine, he talks > about integrating IP telephony/SS7 with USR TC gear............ Is it just me, or is it really starting to seem like IP telephony is all NAS vendors care about nowadays?? Is it just me, or do none of the ISP's out there actually care about this? Maybe I'm just smoking crack, or haven't had my morning caffeine fix... (And I'm not singling 3com out here.) Mike Andrews (MA12) icq 6602506 -------------- mandrews@dcr.net Senior Systems/Network Administrator --- mandrews@termfrost.org Digital Crescent, Frankfort, KY ----- http://www.termfrost.org/ "If Barbie is so popular, why do you have to buy her friends?..."

-> On Thu, 30 Jul 1998, Brian wrote: -> -> > Interview with 3Com's CEO in this weeks InternetWeek magazine, he talks > -> about integrating IP telephony/SS7 with USR TC gear............ -> Is it just me, or is it really starting to seem like IP telephony is all NAS -> vendors care about nowadays?? -> -> Is it just me, or do none of the ISP's out there actually care about this? -> Maybe I'm just smoking crack, or haven't had my morning caffeine fix... -> (And I'm not singling 3com out here.) No, what's happening is everyone is eyeing the crown jewel of the long distance carriers; their $200 billion+ switched voice market. Up until now you had to play by their very rigid rules. regulations and in a heavily capital overhead industry. Did you ever wonder how companies like Ascend, Nortel and Lucent got so big ? Ever buy a central office switch (i.e. ESS, DMS etc..) ? When I was at MCI figures like $4 million plus were thrown around. How can they afford them ? Simply, by charging per minute usage on a product which has about the highest profit margin of any product in that industry. So the LD companies don't want to see bypass, flat rate pricing, IP telephony etc.. unless they control the market. Watch how much IP telephony stuff they buy and how they market it. Anyway, enoguh of my ramblings but I think you see the prize and the motivation... Jeff Binkley ASA Network Computing

no it looks like in the next few years the 2 may become 1 At 09:44 AM 7/30/98 -0400, you wrote: >On Thu, 30 Jul 1998, Brian wrote: > >> Interview with 3Com's CEO in this weeks InternetWeek magazine, he talks >> about integrating IP telephony/SS7 with USR TC gear............ > >Is it just me, or is it really starting to seem like IP telephony is all >NAS vendors care about nowadays?? > >Is it just me, or do none of the ISP's out there actually care about this? > >Maybe I'm just smoking crack, or haven't had my morning caffeine fix... > >(And I'm not singling 3com out here.) > > >Mike Andrews (MA12) icq 6602506 -------------- mandrews@dcr.net >Senior Systems/Network Administrator --- mandrews@termfrost.org >Digital Crescent, Frankfort, KY ----- http://www.termfrost.org/ >"If Barbie is so popular, why do you have to buy her friends?..." > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > >

On 29 Jul 98, at 18:33, David Bolen <usr-tc@lists.xmission.com> wrote: > Kevin Benton <s1kevin@tims.net> writes: > > > Why should I count what the chassis has a very easy time giving to me? > > Or, if you're interested in DS0 utilization rather than modems, you > can grab bulk status objects in about 1-2 seconds even for a fully > loaded hub of HDMs. How? what's the mib item? ---------------------------------------------------------------------- Andres Kroonmaa mail: andre@online.ee Network Manager Organization: MicroLink Online Tel: 6308 909 Tallinn, Sakala 19 Pho: +372 6308 909 Estonia, EE0001 http://www.online.ee Fax: +372 6308 901 ----------------------------------------------------------------------

On Thu, 30 Jul 1998, Jeff Binkley wrote: > -> On Thu, 30 Jul 1998, Brian wrote: > -> > -> > Interview with 3Com's CEO in this weeks InternetWeek magazine, he talks > > -> about integrating IP telephony/SS7 with USR TC gear............ > -> Is it just me, or is it really starting to seem like IP telephony is all NAS > -> vendors care about nowadays?? > -> > -> Is it just me, or do none of the ISP's out there actually care about this? > -> Maybe I'm just smoking crack, or haven't had my morning caffeine fix... > -> (And I'm not singling 3com out here.) > > No, what's happening is everyone is eyeing the crown jewel of the long > distance carriers; their $200 billion+ switched voice market. Up until > now you had to play by their very rigid rules. regulations and in a > heavily capital overhead industry. Did you ever wonder how companies > like Ascend, Nortel and Lucent got so big ? Ever buy a central office > switch (i.e. ESS, DMS etc..) ? When I was at MCI figures like $4 million > plus were thrown around. How can they afford them ? Simply, by > charging per minute usage on a product which has about the highest > profit margin of any product in that industry. So the LD companies > don't want to see bypass, flat rate pricing, IP telephony etc.. > unless they control the market. Watch how much IP telephony stuff > they buy and how they market it. Anyway, enoguh of my ramblings > but I think you see the prize and the motivation... Realilstically however, these days you can purchase a ESS5 Lucent switch for around $1million dollars or so, and even better than that, you can buy your own switch that will do 32-125 PRI lines for anywhere from $50,000-$300,000. It certainly is cost effective for an ISP to buy there own switch, and pay NO telco charges, vs. paying $20,000 a month in telco. When I think of doing our own switching, I am not thinking 3Com. However, I can see them building this into there equipment, to get some cool functionality. I personally feel that many of us (isp's) will have our own switches over the next few years, which of course run SS7. Being able to tie features on the 3Com into our switches via SS7, is going to be really nice. Brian > > Jeff Binkley > ASA Network Computing > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > Brian Feeny (BF304) | ShreveNet Inc. - Premium Internet Service Provider Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1

Brett Hawn said once upon a time: > >We've upgraded several of our HiPer's the the V.90 code, and they're working >great... for x2/v90 customers. However they appear to really _BITE_ for >folks using v.34. Most of them get really shoddy connection speeds (we've >personally seen as low as 9600bd) and get booted randomly with 'lost >carrier'. Has anyone else seen this? USR is there is fix for this? The new code has been working great here. No major problems across the board. I'll have to test out the v.34 problems.

Brett Hawn said once upon a time: > >We've upgraded several of our HiPer's the the V.90 code, and they're working >great... for x2/v90 customers. However they appear to really _BITE_ for >folks using v.34. Most of them get really shoddy connection speeds (we've >personally seen as low as 9600bd) and get booted randomly with 'lost >carrier'. Has anyone else seen this? USR is there is fix for this? The new code has been working great here. No major problems across the board. I'll have to test out the v.34 problems.

Tatai SV Krishnan said once upon a time: > >Idle time out does work with the radius server. If for any reason it is >not working for you, let me know the version of the hiper arc code and if >possible get me a snoop trace of the authentication. It isn't so much that the idle-timeout doesn't work. It works great if nothing is sent. It is the fact that the ARC counts just about everything as activity. All some unknowledgeable subscriber needs to do is leave the room with ICQ running and their connection is up all day. It would be utterly swell if we could define what is counted as network activity on the ARC. This was a feature of the very first Xylogics Annex I bought in 1993. It amazes me that the idea isn't more widespread.

On Thu, 30 Jul 1998, Andres Kroonmaa wrote: > > Tell you what, since changeover to 3Com, things DO have improved, at least > for me. With USR you'd die before getting any help, unless you had contract. > What concerns hardware swaps, then of the few that I had to do, all went > impressively smooth and fast, even to the extent that I was amused to the > extreme. (they found that I have PSUs that might explode ;), they said > they would replace them for free, and when I sent them confirm that yes, > I want to, things went off and rolled in full speed, I was notified by > mail from at least 5 people who all did handle the shipment, was given > the DHL tracking number and in just few days the PSUs were here) > And, when Hiper did crash every 5 mins for its bugs, 3com sent an engineer > over here, gave us engineering version of code that was more stable, > and did send us 2 free NetServers just to keep our service up until Hiper > code was fixed. I wouldn't call this a bad support. And we have only software > upgrade contract with 3Com. I too feel that 3Com has to be given Credit in area's. They make a good product, and they have some very cluefull support people to help offset some of the clueless. I can speak positivly of a number of people: Sanjeav Krishna Ken Tam Mike Wronski Skip Lasher the above people are probably busier and busier each day, than they were the previous day, no doubt alot of load must be put on them, but all have shown to be positive about there jobs, genuinly concerned with the customer and the product, and seeing that attention is put where it matters. I have seen some pretty bad support people at 3Com, and hopefully they are working the necessary means to improve training and get people up to par. Its difficult, because as we all know, its hard to learn all there is to know about this stuff, especially when your not working in a real enviroment such as an ISP. Once you train someone, how do you keep them from leaving that job, and going to work for some isp or consulting firm getting paid more? Its a rough balance. If you pay them too cheap, they will take your training and leave. If you pay them too much the cost of support contracts may go up as well. My solution is I don't take bs from tech support people. If they don't know what I am talking about, then I ask them to escalate, and believe me, I have no patience with this, so I usually am successfull, and why shouldn't I be? Its for the betterment of myself and 3Com, that the call be handled by someone who knows what I am talking about. Anyone can document the issue, and I usually let them do that. Sometimes you will be surprised, as I was when Ken Tam did level1 and he knew solutions to all my problems. 1. try tech support, but escalate if you have to. You may just find an ace even at level 1 (it can happen). 2. Try to take a test/training that will allow you to get directly to level 2 applications engineering. Once again, this is for the betterment of both 3Com and you. You are not wasting there level 1 person's time, and your not wasting your time either. Furthermore, once you accomplish this, you will be well educated and probably not call much at all. 3. Use this list as a first line support, it works for us :) Brian Feeny (BF304) | ShreveNet Inc. - Premium Internet Service Provider Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1

Jason W said once upon a time: > >This one has me stumped... On three of our USRTC >chassis, one is using the HiPer Arc, we are having >connection problems. Basically a user will dial in and >after authentication, the error msg..."dial up networking >could not negotiate a compatible set of network protocols >you specified....blablabla" This only happens to 2 or 3 >ports on the device. If I have someone physically reset >the card, the problem goes away. Make sure the only protocol the user has in their Network settings is TCP/IP. We've had this same problem with some boxes that have NetBUI, IPX and all that other crap Microsoft throws on by default.

"Andres Kroonmaa" <andre@ml.ee> writes: > How? what's the mib item? I've enclosed some previous notes (should also be in the archive with the rest of the thread) that contains some details. I know that the HDM cards are supporting the bulk objects as of TCS 3.1 (the V.90 release) - 1.2.x. -- David - - - - - - - - - - - - - - - - - - - - - - - - - In-Reply-To: Your message of Mon, 12 Jan 1998 14:26:52 +0100 Message-ID: <CMM.0.90.2.884635228.db3l@valheru.ny.ans.net> Robert von Bismarck <rvb@petrel.ch> writes: > This is probably documented somewhere, but I need to know how many users > are currently connected to a TC Hub via SNMP (so I can list this in my > MRTG stats). There are several ways, depending on which card(s) you wish to query for that information. However, each method also has some pros and cons associated with it. You can't get it from the NETServer via SNMP since it only has MIB-II and while you could check interfaces for PPP customers or TCP streams for non-PPP, it wouldn't include users still logging on. You can, however, probably get more of what you want with an embedded telnet session to do a "show all" or "show session". If all you service is PPP customers, then the other response posted her that checks for the interfaces should work pretty well, although it'll only include users who have successfully started the PPP negotiation such that the NETServer has added an interface for them. As far as other SNMP options, there are probably three possible methods: (1) Querying the DS0 status on any line cards in the chassis to determine which channels are occupied. (2) Querying the modem status on any modem cards in the chassis to determine which modems are occupied. (3) Querying the LED status and gauging utilization from the chassis LEDs being displayed on the cards. (1) DS0 status on line cards This would be completely accurate (providing you queried all line cards). However, you do need to adjust the object you use by the line card type: Per-Channel Bulk --------------------------------------------------- Dual T1(*) ds0StatDs0 ds0BulkAccessStatDs0Modem Dual PRI ids0StatDs0 ids0BulkAccessStatDs0Mdm HDM usrds0StatDs0 usrds0BlkAccessStatDs0Mdm(+) (*) This is either the original 186 dual T1 card or the newer 386 dual T1/PRI card running the T1 code. (+) This object is not yet populated properly on the HDM code base. It's also technically in the DS1 mib (rds1.mib) rather than the DS0 mib even though the prefix is wrong. You'll find that the per-channel objects are very slow to query on the Dual card (slow, but not unbearably so on the HDM) so I'd strongly suggest the bulk objects, which basically have the normal status objects for every channel encoded byte by byte. (2) Querying the modem status You can use the "mdmCsStatus" object for each modem in the chassis (quad and HDM) to get the current status and judge those that aren't currently idle as in use. The actual response by the modems is quite fast (unlike the per-channel DS0), but there are a lot of these objects to query and no "bulk" equivalent. However, if you cluster a large number of modems into a single SNMP PDU you can probably get status for a doubled up chassis (48 modems in quads, and another 48 in two HDM cards) in under 15 seconds. (3) Checking LED status This is actually the fastest method, but with the introduction of HDMs it loses on exactness. Using the chassis LED objects: uchasFrontPanelLedColor, uchasFrontPanelLedColor2 uchasFrontPanelLedStates, uchasFrontPanelLedStates2 you can query all of the LEDs in the chassis. If you know which cards are modems, you can use an amber LED for training and a green for online to count users. (The *2 objects are for cards with more than 12 LEDs, like the HDM). The breakdown of these objects are documented in the NMC MIB reference - or at least for the main objects, since the *2 objects are newer, but they follow the same format just for LEDs > 12. The rub is with the introduction of HDMs. Since they don't have an LED for each modem (but rather one per 10% of the modems) you have to guess a bit with HDMs in a chassis. But you can't beat the speed, since you're just querying 4 objects and can do so in a single PDU. So what do I do? For my purposes, I have a "show chassis" command in one of our tools that presents a front view of a chassis (cards, LEDs, etc..) and it uses the LED information to quickly summarize usage as in my point (3). For HDMs, I'm forced to estimate somewhat, although prior to that point it was an exact count. The other more typical approach we use is from (1) for the DS0 status, since it lets us get a summary view of all input channels into a hub. For that, I've done code that always tries the bulk query (selecting the appropriate one for the card(s) in question) first, and then issues appropriate channel queries for any channels not properly returned in the bulk object. I've found that just checking for 0 values in the bulk object serves well here, since it covers both cases where the NMC supports the bulk object but the card does (earlier code) as well as issues where the card doesn't support it properly (like current HDMs). Oh, and some versions of the dual E1 PRI code incorrectly leaves out the 32nd channel on a span in the bulk object, so this picks up that and requeries it directly. Unfortunately, this isn't like a single object to query to give this summary. That's mostly because the TC is a distributed architecture, where the line, modems and terminal server functionality is distinct, so asking a question like "how many users are on" is more ambiguous than you might think, since the answer may differ depending on which card you are talking to and what it considers idle or "on". In some cases, what you probably want more than anything else is the NETServer view of online users, but unfortunately it doesn't do SNMP anywhere near as well as the rest of the chassis in terms of providing access to all of its information. So to work with MRTG you'd need to encapsulate this intelligence in a script or program that could then output the right value. My guess is that the LED poll would probably be suitable for your purposes (particularly if you don't have HDMs yet). Oh, and I just realized that there was a similar request last year that I also answered, so I'll include that response below (although it doesn't cover HDMs since they weren't out at the time) for added reference. -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | ANS Communications, Inc. \ Phone: (914) 701-5327 | / 100 Manhattanville Rd, Purchase, NY 10577 \ Fax: (914) 701-5310 \ \-----------------------------------------------------------------------/ In-Reply-To: Your message of Wed, 30 Jul 1997 16:16:49 -0400 Message-ID: <CMM.0.90.2.870336536.db3l@foo.ans.net> Bosco Tsang <bosco@ipoline.com> writes: > Is it possible for me to get a user count for USR Total Control via SNMP, > so that I can plot it out via MRTG? What are the OIDs? I'm not sure how implementable these methods are with MRTG (is that an SNMP display tool of some sort?), but if all you're really concerned with is simultaneous port count (as opposed to username information or other NETServer authentication type of stuff), there are a few approaches you can take. The NETServer itself won't help all that much (it supports very little via SNMP) but you can try: * Walking the mdmCsStatus object. This will give you a list of objects for each modem (e.g., mdmCsStatus.2001 is for modem 1 in slot 2). Count those that have an enumerated value of onlineAnswer(8) - or onlineOriginate(7) too if you do outbound, and you'll have a count of "live" modems. You can look at other enumeration values to see users that are training, or in other states. It's not the fastest in the world, but walking a hub with 48 modems should take about 10 seconds or so. You can "cheat" if you know just how many modems there are, by constructing a query that uses GetNext, and queries the objects just in front of the known modems. For example, if you know you have 48 modems in slots 2-13, instead of doing 48 GetNext queries to walk table dynamically, build a single query that queries the objects: mdmCsStatus.2000, mdmCsStatus.2001, mdmCsStatus.2002, mdmCsStatus.2003, mdmCsStatus.3000, mdmCsStatus.3001, (etc...) mdmCsStatus.13002, mdmCsStatus.13003 and then issue a single GetNext query (or just a few to avoid making the PDU too large). The instances will "roll" to the appropriate modem (e.g., your .2000 query will get you modem 2001), and you'll have many less PDUs to handle, cutting down the overhead. You can query a hub worth of modems this way in only about 2-3 seconds. Note that this approach is only useful for hubs where the modems handle all callers, so if you have ISDN hubs that pass callers right to the NETServer this won't count them. * Ask your circuit card(s) what the status of their individual span channels are. You can break it out by those that are connected in or out, busied out, etc.. any of the enumerations as shown in the MIBs for ds0StatDs0 (channelized T1) or ids0StatDs0 (PRI). One approach is to actually walk the appropriate MIB tree but I wouldn't recommend it if you can parse an opaque object instead, because walking the DS0 status tree is deathly slow, even trying the trick above - the interface to the T1/PRI cards is just too slow. Instead, I would suggest querying the newer bulk access objects (ds0BulkAccessStatDs0Modem for channelized configurations and ids0BulkAccessStatDs0Mdm for PRI). These objects are a single opaque value with information on all channels in one query, and allow you to query the span information in a single SNMP object in well under a second. The instance for the objects is the entity of the DS1 span (e.g., 1001 for the first DS1 in slot 1). You do have to break the information apart a bit, once you get it back, but for the performance it's worth it. For the channelized T1 case the object is two bytes per channel. The first byte is the ds0StatDs0 enumeration and the second the ds0StatModem enumeration. So just pluck out every other byte for your DS0 channel status. In the PRI case, the bulk object is 4 bytes per channel, the first being the ids0StatDs0 enumeration, the second the ids0StatDevConnTo enumeration, followed by ids0StatSlotConnTo and ids0StatChanConnTo (the latter two are actually 0xFF for no connection which isn't really documented in the objects themselves). So pluck out the first of every 4 bytes and you've got your DS0 status. Once you've got the status of your channels you can break them out, and sum them up however you'd like. -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | ANS Communications, Inc. \ Phone: (914) 789-5327 | / 100 Clearbrook Road, Elmsford, NY 10523 \ Fax: (914) 789-5310 \ \-----------------------------------------------------------------------/

When making a change to the modem settings on the HiperDSP's such as carrier loss or transmitter level, does one have to reboot the card or does the setting take place on the next call? Also same question for the quads? -----Original Message----- >4.0.29 replies with the total number of interfaces. 4.0.19 replies with >the number of *active* interfaces. Would 3Com please either do one of the >below? > >1) Change it back to the way it was by reporting the number of interfaces >in-use, > >2) Allow users to select whether or not ...interfaces.0 (as per the >previous posts on this list) would reply with the total number of >interfaces, or the total number of active interfaces which would help us >determine number of active connections, or > >3) Give us a totally separate mib entry for the number of channels being >used via snmp. > >My personal preference would be to be able to monitor the number of >channels in use on a T1 level, but the above would be acceptable for the >intermediate time. > >Kevin > >E-Mail: s1kevin@tims.net >Web: http://users.sota-oh.com/~s1kevin/ >Unsolicited advertisements processing fee: $50 subject to change without notice > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

On 29 Jul 98, at 13:27, Terry Kennedy <usr-tc@lists.xmission.com> wrote: > Well guys - this one's for the pro's out there... > > We recently moved our Netserver/quads from digital to analog > ( replaced them with the hiperARC\dsp combo's ) in place of > our old Annex/multitech box's in order to better faciltate our > RADIUS needs. ( Annex's don't do RADIUS well). > > So... we removed the T1 cards, set the modems to the nic and > turned the whole mess on. Works fine except..... constant complaits > of people being disconnected. Loss of carrier seems to be the > dominant reason. I went through this with multitech > modems and ended up adjusting transmitter levels. That's the > Black Majic part. I remember all too well helping one customer > only to have created other trouble in doing this. The transmitter > levels are at 11db. I would imagine this is a negative level? So > anyone cares to give me a little insight as to how yours are set, if > they are different at all, I would appreciate it. Try reducing modem output levels to -15db, (but no more) might help to some extent. ---- The following is perhaps more for 3com staff to read, and what I am facing is somewhat surprising to me, as I have considered USR modem technology quite robust and good. Now I am forced to review that position. Most of our customers with non-3Com modems are constantly complaining about disconnects, holes in transfers (retrain effects), slow connect times (again retrains) All the same customers have no problems when they connect to our cisco 5200 box. Note that box TC and cisco are connected to the same CO, and are in the same hunt group. One of our power-users tried to diagnose the cause and ended up with some interesting facts. He was using some IDC modem, which has some fancy features for modem-hackers, like signal spectrum analizer, AND noise spectrum analiser. 1) He found that there is considerable amount of noise when callin TC, while there is much less analog noise when calling cisco's. The noise can't appear on the digital line, so there is something wrong with DSP processing, or transmit levels overloading something somewhere. 2) signal spectrum was almost equally nice on both 3) noise spectrum was bad. low and high side of frequencies had lots of noise (perhaps mains inducted lowband noise and higband noise from crosstalks). This is pretty common on the lines around here... Now, USR does not cope with that ok, while cisco (microcom modems) does very well. I am told by some modem-gurus, that USR modems have a fundamental design flaw: - USR modem measures line signal spectrum distribution AND ONLY average signal to noise ratio in the whole spectrum. - It _assumes_ that noise distribution is _even_ across the whole spectrum. - based on average S/N level and signal specrum it determines carrier frequency and operating window within the spectrum. - in case it is right in its assumption of even noise distribution, everything is fine. - in case your lines have un-even noise distribution, with spikes in low and/or high frequencies, USR modem selects WRONG carrier and window for operation on the given line. USR modems do NOT measure noise distribution in the spectrum, (you cannot read out any data about it from the modem) and it does NOT adapt itself to line-noise distributed unevenly. the result: - it gets fooled by cute signal spectrum available, especially when - there seems to be good S/N on the whole range. So, - it tries to operate on the frequency range that has lots of noise (or spikes) and select inappropriate carrier frequency and range. Manifests as: - long and painful connecting with many retrains - frequent disconnects before connecting, or unable to connect at all - final connect speeds 21600/v34 on lines that are capable of 31200 - frequent retrains during session - carrier loss and disconnects Given non-trivial task (or 3Com's reluctance) to change DSP code, almost noone expects things to improve in near future... ;( But it would be lovely, if some tech guy from 3com could comment on these observations, and if confirm the behaviour, would get the Message: not all lines around are so perfect, and a modem from leading modem manufacturer must cope with that. PS. following are few illustrations of real-life lines as viewed from client modem where USR modems looses badly. -023-| -025-| -027-| _________ -029-| *************_____ -031-| _*********************_____ -033-| ******************************_____ -035-|_**************************************____ -037-|***********************************************__ -039-|************************************************* -041-|************************************************* -043-|************************************************* -045-|************************************************* -047-|************************************************* -049-|************************************************* -051-|************************************************* -053-|************************************************* ----------------Signal-Strength------------------ Average: -32 dB 0 0 0 0 0 0 1 1 1 1 1 1 1 2 2 2 2 2 2 3 3 3 3 3 3 1 3 4 6 7 9 0 2 3 5 6 8 9 1 2 4 5 7 8 0 1 3 4 6 7 5 0 5 0 5 0 5 0 5 0 5 0 5 0 5 0 5 0 5 0 5 0 5 0 5 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 -053-|***___ -055-|****** -057-|******_ -059-|******* -061-|******** -063-|********_ -065-|********** -067-|***********_ -069-|**************_ -071-|******************_______ -073-|*******************************_______ -075-|*****************************************__*_____ -077-|************************************************* -079-|************************************************* -081-|************************************************* -083-|************************************************* -----------------Noise-Strength------------------ Average: -70 dB 0 0 0 0 0 0 1 1 1 1 1 1 1 2 2 2 2 2 2 3 3 3 3 3 3 1 3 4 6 7 9 0 2 3 5 6 8 9 1 2 4 5 7 8 0 1 3 4 6 7 5 0 5 0 5 0 5 0 5 0 5 0 5 0 5 0 5 0 5 0 5 0 5 0 5 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 009-| 011-| 013-|__ 015-|** 017-|** 019-|** 021-|**_ 023-|***_ 025-|*****_ 027-|******_ 029-|******* 031-|*******_ 033-|********_ 035-|*********_ 037-|**********__ ______________* 039-|************______________________*************** --------------Signal-to-Noise-Ratio-------------- Average: 36 dB 0 0 0 0 0 0 1 1 1 1 1 1 1 2 2 2 2 2 2 3 3 3 3 3 3 1 3 4 6 7 9 0 2 3 5 6 8 9 1 2 4 5 7 8 0 1 3 4 6 7 5 0 5 0 5 0 5 0 5 0 5 0 5 0 5 0 5 0 5 0 5 0 5 0 5 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 ... ... >Carrier Freq ( Hz ) 1600/1600 <--- (higher carrier at 2400 - 1800 Hz) Symbol Rate 2400/2400 SNR ( dB ) 42.6 Speed: 21600/21600 -22 . X X X X X X x x x . . . . . . . . . . . . . . . 1 -24 . X X X X X X X X X X X x x . . . . . . . . . . . 3 -26 . X X X X X X X X X X X X X X X x x . . . . . . . 5 -28 . X X X X X X X X X X X X X X X X X X X x x . . . 7 -30 . X X X X X X X X X X X X X X X X X X X X X X X X 9 -32 X X X X X X X X X X X X X X X X X X X X X X X X X 11 Level --------------------Frequency-------------------- Attn ---------------------------------------------------------------------- Andres Kroonmaa mail: andre@online.ee Network Manager Organization: MicroLink Online Tel: 6308 909 Tallinn, Sakala 19 Pho: +372 6308 909 Estonia, EE0001 http://www.online.ee Fax: +372 6308 901 ----------------------------------------------------------------------

> It's their Execs who should be fired, they defend their support lines > with VERY high fees in place of documentation. Who's the > rocket-scientist 3Com stuffed-shirt asshole who dreamed up THIS > strategy? Amen. We're waiting on replacment parts for our racks. In their infinite wisdom, they've decided to do all replacements out of SINGAPORE (we're in Australia). We have to make international phone calls to talk to them (we can't - our phones/faxes are ISD barred). They e-mail us attachments we can't read. They tell us our product doesn't exist. They tell us their standard warranty arrangements for TC class equipment is to have us return the faulty component and wait up to 30 days for a replacement. They should realise they're not selling $200 modems here, it's 'high end' server equipment and a 30-day RTB warranty isn't worth sh*t. They told us we'd have to move to a support contract sometime in the future, but they never bothered to tell us just when that was happening or what the deal would be. > In contrast, Tech support at Livingston/Lucent is great... we have a few > PM2s and have only had to call twice, but both times were a pleasant > experience (as pleasant as these things can go). We've already reminded 3COM that we won't be buying any more of their equipment unless things improve. Livingston is looking very attractive at this stage, and to that end we've already made enquiries with a view to purchasing their equipment instead. ...now when USR was USR, things were great - at least they were here in Oz - can't speak for the rest of the world. 3COM downsized most of the USR employees out of existance in Australia :-( Regards, Bob Purdon, Technical Manager, Southern Internet Services.

Brian Feeny (BF304) | ShreveNet Inc. - Premium Internet Service Provider Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1 ---------- Forwarded message ---------- Cc: isp-equipment@isp-equipment.com (2) USR/Cisco 2511 Router Cards for the Total Control Hubs (NIC/NAC, IOS 11.2) 1 Ethernet, 1 Sync Serial, 16 Async Serial's. $400/ea (1) CT1 NAC Cards (Dual T1, channalized) $400 (Will trade for DUAL PRI NAC) WTB Dual PRI Nac -Scott --- GSTek Corporation *Kenneth Scott Bethke* Ezy.Net Corporation Sun/Networking/ISP Stuff -- BUY/SELL/TRADE -- FAX: 410-742-1381 Email:kbethke@ezy.net Voice:410-742-1610 Web:http://www.ezy.net/gstek To unsubscribe, e-mail: isp-services-unsubscribe@ispc.org For additional commands, e-mail: isp-services-help@ispc.org

Bob Purdon was heard to say: >They tell us their standard warranty arrangements for TC class equipment >is to have us return the faulty component and wait up to 30 days for a >replacement. They should realise they're not selling $200 modems here, >it's 'high end' server equipment and a 30-day RTB warranty isn't worth >sh*t. I can only speak of things within the USA, but I've not had a problem getting parts replaced. We don't have a 24hr replacement contract either -- we have spare hardware on hand as even 24hr replacement is too slow depending on the failure. They get replacement hardware back to us with a few weeks (always less than a month.) >> In contrast, Tech support at Livingston/Lucent is great... we have a few >> PM2s and have only had to call twice, but both times were a pleasant >> experience (as pleasant as these things can go). > >We've already reminded 3COM that we won't be buying any more of their >equipment unless things improve. Livingston is looking very attractive at >this stage, and to that end we've already made enquiries with a view to >purchasing their equipment instead. I think most of their clients have said the same thing, but it isn't sinking in as far as I've seen. I will give them some credit... the support center is actually answering the phones in less than 15 minutes and <gasp> they are actually helpful. --Ricky

Bob Purdon was heard to say: >They tell us their standard warranty arrangements for TC class equipment >is to have us return the faulty component and wait up to 30 days for a >replacement. They should realise they're not selling $200 modems here, >it's 'high end' server equipment and a 30-day RTB warranty isn't worth >sh*t. I can only speak of things within the USA, but I've not had a problem getting parts replaced. We don't have a 24hr replacement contract either -- we have spare hardware on hand as even 24hr replacement is too slow depending on the failure. They get replacement hardware back to us with a few weeks (always less than a month.) >> In contrast, Tech support at Livingston/Lucent is great... we have a few >> PM2s and have only had to call twice, but both times were a pleasant >> experience (as pleasant as these things can go). > >We've already reminded 3COM that we won't be buying any more of their >equipment unless things improve. Livingston is looking very attractive at >this stage, and to that end we've already made enquiries with a view to >purchasing their equipment instead. I think most of their clients have said the same thing, but it isn't sinking in as far as I've seen. I will give them some credit... the support center is actually answering the phones in less than 15 minutes and <gasp> they are actually helpful. --Ricky

Goemon Ishikawa said once upon a time: > >On Thu, 30 Jul 1998, Pete Ashdown wrote: >> Brett Hawn said once upon a time: >> >We've upgraded several of our HiPer's the the V.90 code, and they're working >> >great... for x2/v90 customers. However they appear to really _BITE_ for >> >folks using v.34. Most of them get really shoddy connection speeds (we've >> >personally seen as low as 9600bd) and get booted randomly with 'lost >> >carrier'. Has anyone else seen this? USR is there is fix for this? >> The new code has been working great here. No major problems across the >> board. I'll have to test out the v.34 problems. > >Are you talking about HiperDSP 1.2.5? We are about to upgrade for v.90 and >I want to make sure we are using the right release. I don't like suprises. >^_^; I am. I upgraded a few days after it came out. That was a couple of weeks ago and things have been just peachy. They fixed the ISDN support for Cisco and Webramp adapters as well. Plus ISDN connects much faster overall.

Brian was heard to say: >I am on *alot* of lists. Routers, access equipment, isp related, >operating system related, hardware related. I have never been on a list >where there were so many people who felt so strongly and negative about a >company. The only thing that comes close is the tyan motherboards >newsgroup. Hehehh... Personally, I like Tyan MBs... when they work. If it breaks, you'll wish you'd never have heard of Tyan. (But ASUS is just as bad about returns.) >When we first got TC hubs it was very frustrating because of >tech support, back then I use to wait on hold over an hour to talk to >them. That seems to be the standard case. Once you've learned how the things work, then your happy with them. But getting to the happy-ground is very difficult as there is very little accurate documentation on the hardware and it changes faster than it can be documented. Plus, some things are just plain broken. >In the defense of 3Com, I will say that it's very important that if you >have an "issue", to call their tech support and open a ticket on it, that >is the least that must get done. Level 2 and Level 3 tech >support/engineering is very good in most cases, it's the front line that >is lacking. You can also open a TT via the totalservice web site. >I personally hope 3com makes improvments so that all of us our happy once >again, because I am genuinely concerned about the health of the company >that engineers the access equipment we use. The better 3Com does, the >better we are as a company for the future. They need to learn how to market stuff. 5k$US per chassis support contracts are just out of the question -- that's half the price of replacing the chassis. 1800$US software support is tolerable, but also unreasonable as I don't have anything to show that they are, in fact, supporting the software. They have not been fixing some of the well known netserver problems and they plan to discontinue the netservers (with some insane swap out program that ends in about a month.) It's like resurecting the dead to get USR/3Com to even admit to some of the bugs in the RADIUS server code. It's taken them 14 months to add 6 lines of code to the RADIUS server to allow native crypt() passwords in the database. (Something that took me a day to do from the time I was handed the source code. Something that takes about 5min for someone familiar with the code.) They knew that was required from the moment we started talking to them. That support is now in SA6 as part of the TCS 3.5 beta. (Nothing personal, but I don't trust them.) --Ricky

I am running 1.2.5 and I have the same problems ... people getting kicked off for no apparent reason ... running NETServer's with this code ... -----Original Message----- >On Thu, 30 Jul 1998, Pete Ashdown wrote: >> Brett Hawn said once upon a time: >> >We've upgraded several of our HiPer's the the V.90 code, and they're working >> >great... for x2/v90 customers. However they appear to really _BITE_ for >> >folks using v.34. Most of them get really shoddy connection speeds (we've >> >personally seen as low as 9600bd) and get booted randomly with 'lost >> >carrier'. Has anyone else seen this? USR is there is fix for this? >> The new code has been working great here. No major problems across the >> board. I'll have to test out the v.34 problems. > >Are you talking about HiperDSP 1.2.5? We are about to upgrade for v.90 and >I want to make sure we are using the right release. I don't like suprises. >^_^; > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Hello All-- Running 7 TC's with the latest code on all cards (no Hyper's). 6 of these are on 209.38.34 as is our main mail/web server (Digital Alpha running DEC Unix 4.0c). The 7th is on 209.38.35. The server nic is stacked with both Class Cs and gated is running. Problem: Someone dials in and gets onto the 7th rack (which is also at the end of our hunt group). They can surf the web going anywhere in the world that they want to; however, they cannot get to our web server nor can they check their mail on the main server. The same customer can then hang up, change nothing, dial back in, get on TC 1-6 and everything works just fine. From the server I cannot ping their ptp address either although I can ping the 7th TC's Netserver card. I can ping their ptp from an NT box that sits on the network. So, there is obviously something wrong between the DEC box and the 209.38.35 addresses. Item of note: We do have some .35 addresses aliased to the NIC as hosted domains (as we do on the .34 addresses as well) and they work just fine. The routing on the net0 interface is set to Quiet(Off). This used to be set to broadcast, listen. Neither setting has made any difference in reference to the problem. Here is some output of the TC's routing table: 0.0.0.0 /0 209.38.35.251 NS 1 net0 0 209.38.35.51 /32 209.38.35.51 HLCO 16 Unknown 0 209.38.35.87 /32 209.38.35.87 HLC 1 ptp14 0 209.38.35.56 /32 209.38.35.56 HLC 1 ptp36 0 209.38.35.89 /32 209.38.35.89 HLC 1 ptp21 0 209.38.34.0 /24 209.38.35.251 NSC 1 net0 0 209.38.35.0 /24 209.38.35.129 NLC 1 net0 0 The setups of the TCs are identical. I even did the Restore from defaults, Save to NVRAM, and reboot sequence. I have no problems (except some random disconnecting still) with the other 6 TCs. Anyone run into this? Am I missing something real simple? I have a new Hyper bundle that is not on-line yet would it solve the problem? Or is the DEC box setup improperly? Any help would be greatly appreciated. Regards, Chad J. LaFrenz Senior System Administrator RoFIntUG V: 970-945-4920 F: 970-947-1923 Proudly serving the Aspen, Glenwood Springs, Rifle, and Vail Valleys. http://www.rof.net

On Thu, 30 Jul 1998, Chad J. LaFrenz wrote: > Hello All-- > > Running 7 TC's with the latest code on all cards (no Hyper's). 6 of these > are on 209.38.34 as is our main mail/web server (Digital Alpha running DEC > Unix 4.0c). The 7th is on 209.38.35. The server nic is stacked with both > Class Cs and gated is running. Here is my solution, you may love it, you may hate it, I don't know but it works :) If you run OSPF on your servers, which is what we do, do something like this (assuming your router is at 209.38.34.1: rip no { } ; ospf yes { area 1 { authtype none ; networks { 209.38.35.0 ; 209.38.34.0 ; } ; interface eth0; } ; } ; static { default gateway 209.38.34.1 retain; } ; If you run only RIP (yuck!) than use this for your servers: rip yes { nobroadcast ; } ; static { default gateway 208.206.76.1 retain; }; Now, on your USR boxes, simply enable RIPv2. Now on your Cisco router, do this if your using OSPF on server and RIP on USR boxen (like we do): router ospf 10 redistribute connected subnets redistribute static redistribute rip subnets network 209.38.34.0 0.0.0.255 area 1 network 209.38.35.0 0.0.0.255 area 1 ! router rip version 2 timers basic 30 30 2 60 300 passive-interface Serial0/0.1 (or whatever your serial interfaces are) network 209.38.34.0 network 209.38.35.0 no auto-summary If you just run RIPv2 on your gated/3com boxes, just use the router rip stuff and don't put the router ospf stuff in. Your config may be tweaked a little (you may have more passive interfaces, you may wish to use a different ospf area, all that can be changed). The above rocks for us, all static/ip subnet customers can dial into any box and everything gets distributed nice and aggregated etc. Brian > > Problem: Someone dials in and gets onto the 7th rack (which is also at the > end of our hunt group). They can surf the web going anywhere in the world > that they want to; however, they cannot get to our web server nor can they > check their mail on the main server. The same customer can then hang up, > change nothing, dial back in, get on TC 1-6 and everything works just fine. > >From the server I cannot ping their ptp address either although I can ping > the 7th TC's Netserver card. I can ping their ptp from an NT box that sits > on the network. So, there is obviously something wrong between the DEC box > and the 209.38.35 addresses. Item of note: We do have some .35 addresses > aliased to the NIC as hosted domains (as we do on the .34 addresses as well) > and they work just fine. The routing on the net0 interface is set to > Quiet(Off). This used to be set to broadcast, listen. Neither setting has > made any difference in reference to the problem. Here is some output of the > TC's routing table: > > 0.0.0.0 /0 209.38.35.251 NS 1 net0 0 > 209.38.35.51 /32 209.38.35.51 HLCO 16 Unknown 0 > 209.38.35.87 /32 209.38.35.87 HLC 1 ptp14 0 > 209.38.35.56 /32 209.38.35.56 HLC 1 ptp36 0 > 209.38.35.89 /32 209.38.35.89 HLC 1 ptp21 0 > 209.38.34.0 /24 209.38.35.251 NSC 1 net0 0 > 209.38.35.0 /24 209.38.35.129 NLC 1 net0 0 > > The setups of the TCs are identical. I even did the Restore from defaults, > Save to NVRAM, and reboot sequence. I have no problems (except some random > disconnecting still) with the other 6 TCs. > > Anyone run into this? Am I missing something real simple? I have a new > Hyper bundle that is not on-line yet would it solve the problem? Or is the > DEC box setup improperly? > > Any help would be greatly appreciated. > > Regards, > > Chad J. LaFrenz > Senior System Administrator > RoFIntUG > > V: 970-945-4920 F: 970-947-1923 > > Proudly serving the Aspen, Glenwood Springs, Rifle, and Vail Valleys. > > http://www.rof.net > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > Brian Feeny (BF304) | ShreveNet Inc. - Premium Internet Service Provider Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1

As the originator of this thread, I'd like to add that we are also developers of ISP billing software (Imagen's PayMaster). We were hoping to be able to configure, use and test our products on an old friend from back in 1987 - USR equipment. Instead we are embarrassed in our own ISP customer community by 3Com's non-approach to customer support. We have busy signals because of inactive racks, the telco had installed the needed extra lines months ago. I'm not a hardware tech, or a programmer for that matter - the dudes who have to make the Network work - I'm a CEO of a small software firm. It hurts when it's not enough to do your own job, and you have to cover the next guy's as well. The hardware loses value FAST in that environment, just as our software would - perhaps more so. ASIC chips don't do PR, unless you want to argue with error messages.. In the end I think it's poor management to try to avoid technical support, or to try to make it into a profit center. Word of mouth is generated by people, not equipment. If there is anything that distinguishes a network professional, it is that he takes his trade seriously. Best Regards; Dwight G. Jones Imagen Communications Inc. http://www.imagen.net Information Architects tm -----Original Message----- [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Charles Sprickman Sent: Thursday, July 30, 1998 7:14 PM 3Com Assholes! So here's my story... Previously known as "HiPer and Dead Air" or somesuch.

Tell you what, since changeover to 3Com, things DO have improved, at least for me. With USR you'd die before getting any help, unless you had contract. What concerns hardware swaps, then of the few that I had to do, all went impressively smooth and fast, even to the extent that I was amused to the extreme. (they found that I have PSUs that might explode ;), they said they would replace them for free, and when I sent them confirm that yes, I want to, things went off and rolled in full speed, I was notified by mail from at least 5 people who all did handle the shipment, was given the DHL tracking number and in just few days the PSUs were here) And, when Hiper did crash every 5 mins for its bugs, 3com sent an engineer over here, gave us engineering version of code that was more stable, and did send us 2 free NetServers just to keep our service up until Hiper code was fixed. I wouldn't call this a bad support. And we have only software upgrade contract with 3Com. Of course, when I asked from an engineer honestly, why so gentle attention, he said that they pay special attention to new startups and pilot projects. (I guess sort of new market area penetration). Well, this leads to simple general attitude: as long as you are of interest to the vendor, they dance around you, and as soon as they loose interest in you, you're on your own. Of course, you could buy that interest, and huge customers of any vendor are always under special attention. In general, I've got the impression, that both, USR and 3com can design and build very nice hardware that works and is pretty reliable, but they have deepest problems with their software, and sometimes they are plain in deep shit. I know its tough to write a code and debug it, I know they work hard on it, but I still have yet to see a vendor that rolls out firmware code with so many issues and so few features in it. Being mainly massmarket products vendor, 3com is largely as a box-mover like computer-2000 or alikes. You can buy a cisco from such, but go and try to get support for a real problem from them.. So it is, when you call just ordinary support, you get a guy that handles windows driver setup problems for some sportster perhaps, and in a organisation that large as 3com, it make take ages before they find the right person. I haven't ever called 3Com support line, so I can't comment on that, but I believe that its always a matter of who you get on the phone... Basically, when you buy 3Com hardware, expect to get it working yourself, (just as some 3com PCI network adapter?) and if you can't, tough luck. Don't expect any help from vendor, and you might be even pleased when it really does help you... Things are improving. code is better, support is better. But all this Hiper stuff is still in its infancy, and we all suffer its birthpain. You should have known the risk when selecting 3Com over Cisco or others. I guess that 3Com has lost lots of trust, and next time someone decides on vendor for some high-tech hardware, 3Com would need to drop another 20% off the price compared to Cisco to make them even consider... but we are mostly in only one of the markets... PS. I'd still like to thank those few exUSR/3Com engineers who take their time to monitor this list and provide useful hints. Although most probably this isn't their duty, they have perhaps saved us tons of "on-hold hours". Many thanks to you! And let 3Com move more support to such lists - this is the least it can do to compensate for the trouble we all are getting. On 30 Jul 98, at 9:02, Jamie Orzechowski <usr-tc@lists.xmission.com> wrote: > I am starting to DETEST 3Com/USR ... If we could do it again .. livingston > would be beside me ... I have yet to have a straight answer from them and > they have never fixed any of my problems ... > > -----Original Message----- > From: Bob Purdon <bobp@southcom.com.au> > To: usr-tc@lists.xmission.com <usr-tc@lists.xmission.com> > Date: Thursday, July 30, 1998 12:35 AM > Subject: Re: (usr-tc) Why Is USR's Brand Being Destroyed? Fire Those 3Com > Assholes! > > > > > >> It's their Execs who should be fired, they defend their support lines > >> with VERY high fees in place of documentation. Who's the > >> rocket-scientist 3Com stuffed-shirt asshole who dreamed up THIS > >> strategy? > > > >Amen. > > > >We're waiting on replacment parts for our racks. In their infinite > >wisdom, they've decided to do all replacements out of SINGAPORE (we're in > >Australia). We have to make international phone calls to talk to them > >(we can't - our phones/faxes are ISD barred). They e-mail us attachments > >we can't read. They tell us our product doesn't exist. > > > >They tell us their standard warranty arrangements for TC class equipment > >is to have us return the faulty component and wait up to 30 days for a > >replacement. They should realise they're not selling $200 modems here, > >it's 'high end' server equipment and a 30-day RTB warranty isn't worth > >sh*t. > > > >They told us we'd have to move to a support contract sometime in the > >future, but they never bothered to tell us just when that was happening or > >what the deal would be. > > > >> In contrast, Tech support at Livingston/Lucent is great... we have a few > >> PM2s and have only had to call twice, but both times were a pleasant > >> experience (as pleasant as these things can go). > > > >We've already reminded 3COM that we won't be buying any more of their > >equipment unless things improve. Livingston is looking very attractive at > >this stage, and to that end we've already made enquiries with a view to > >purchasing their equipment instead. > > > >...now when USR was USR, things were great - at least they were here in Oz > >- can't speak for the rest of the world. 3COM downsized most of the USR > >employees out of existance in Australia :-( > > > >Regards, > > > >Bob Purdon, > >Technical Manager, > >Southern Internet Services. ---------------------------------------------------------------------- Andres Kroonmaa mail: andre@online.ee Network Manager Organization: MicroLink Online Tel: 6308 909 Tallinn, Sakala 19 Pho: +372 6308 909 Estonia, EE0001 http://www.online.ee Fax: +372 6308 901 ----------------------------------------------------------------------

So here's my story... Previously known as "HiPer and Dead Air" or somesuch. I nervously set up my first HiPer chassis after going through all the PDFs (remember the days of free printed manuals?) and everything looked peachy. Lots of nice new things on the ARC like the command completion and all. Take rack to colo, triple check telco settings. All lights green, it looks happy. However it wouldn't take a call. Just dead air. Twiddle twiddle twiddle thinking there's a config mistake since it's new software. The nightmare begins... I decide to call support (no contract on this unit yet, but it's brand new) and we go through all the typical painful clueless troubleshooting which amounts to blowing out all configs, reloading all software, etc. Then the techs (level 1 for the first few calls) proceed to log in and bre^H^H fix things themselves while I wait on hold sitting on the cold hard floor of the telco colo for a few hours. They are stumped. I don't know what they've done, as they *don't talk to you while running around with full admin privs in your equipment*. They vaguely suggest a telco issue, but don't back it up with any reasoning. Cool down for a few days... Call back again and deal with another tech that sounds like more of a newbie but is open to suggestions (I later find out she is level 2). This time the tech logged in again and would be me on hold to confer with someone every 10 minutes or so. Then a nice 3 hour hold. I have a paint bucket to sit on this time, comfy... When she returns, the suggestion is to return the ARC and DSP. I suggest switching to a known good T from one of our other chassis. Same deal. The quad/Netserver chassis works on the new T but the HiPer doesn't work on the old. At that point she was willing to rule out the telco finally. At this point we turn to our local rep to try and get someone on site. They are convinced it's pilot error and suggest we pay for their install service. I work on getting him to escalate, and I eventually end up with a very helpful person in level 3. He's stumped too, but is going through a logical path of troubleshooting and bouncing ideas off me. This is what my first contact with support should have been like. Eventually, we pull all HiPer cards and I bring them back to the office and install them in an old 45A chassis and watch it take a call. Chassis must be bad somehow, right? Bzzz! Weeks later, I find my replacement chassis (yep, they shipped advance) at the colo. I'd sent a fax to "logistics" asking for two things, shipping directly to the colo and a confirmation that it would go there. Eventually someone at the telco called to ask if I was the owner of a big box taking up space there. Swap it all in to the new chassis, and blammo, same problem. WTF??! I ended up solving the problem on my own using some of the info about static configs and "ownership" that the last tech had given me. On a whim, I tried booting with a static config with the NMC removed. That worked. So it was an extremely flaky NMC that was capable of nuking the bus even with a static config and no NMC chassis awareness set. Odd, but true. So when does this nightmare end? I don't know. All I wanted was a new NMC. My tech (I'll call him Brian M. -- Hey Brian!! They need to clone you!) finished the paperwork to OK a replacement. So the fair thing is to waive the 30-day limit on advance shipment and get me a new card ASAP, right? They shipped defective equipment that literally cost me at least 9 full days of work, and took their time escalating to a tech that could diagnose the faulty hardware they sent me, but they still apply the 30-day limit and will ship me a "repaired" (I prefer the term "used") card once I ship them the broken one. What a complete crock. Sorry for the ramble, but I needed to vent. This equipment makes me want to get a therapist. Charles On Fri, 31 Jul 1998, Bob Purdon wrote: > Date: Fri, 31 Jul 1998 10:56:38 +1000 (EST) > From: Bob Purdon <bobp@southcom.com.au> > Reply-To: usr-tc@lists.xmission.com > To: usr-tc@lists.xmission.com > Subject: Re: (usr-tc) Why Is USR's Brand Being Destroyed? Fire Those 3Com Assholes! > > > > Tell you what, since changeover to 3Com, things DO have improved, at > > least for me. With USR you'd die before getting any help, unless you had > > contract. > > I'm finding the opposite here - with USR we had excellent support. Now > we're getting a much lower level of service :-( > > > What concerns hardware swaps, then of the few that I had to do, all went > > impressively smooth and fast, even to the extent that I was amused to > > the extreme. (they found that I have PSUs that might explode ;), they > > said they would replace them for free, and when I sent them confirm that > > yes, I want to, things went off and rolled in full speed, I was notified > > by mail from at least 5 people who all did handle the shipment, was > > given the DHL tracking number and in just few days the PSUs were here) > > We typically had overnight service from USR. > > We've since been told our NETserver cards are suspect (the FC2/FC3 chipset > thing, that we raised with them shortly after we purchased the units and > were told there was no known problem). Getting replacements is a painful > process. I think we're up to a week or more now, and I still haven't > heard what's happening. > > > And, when Hiper did crash every 5 mins for its bugs, 3com sent an > > engineer over here, gave us engineering version of code that was more > > stable, > > Back when USR were USR, they sent an engineer down here to isolate one > particular problem. Very impressive service back then. > > > (I guess sort of new market area penetration). Well, this leads to > > simple general attitude: as long as you are of interest to the vendor, > > they dance around you, and as soon as they loose interest in you, you're > > on your own. > > I'm inclined to think that's what's happened here. I'll bet the Telstra's > and Optus's (large Telcos here in Oz) are getting better responses than we > are. > > > Basically, when you buy 3Com hardware, expect to get it working > > yourself, (just as some 3com PCI network adapter?) and if you can't, > > tough luck. Don't expect any help from vendor, and you might be even > > pleased when it really does help you... > > We've had no problems when it comes to phone support, although we do > resolve most issues ourselves anyway. It's what happens (lately) if > something breaks :-( > > > I guess that 3Com has lost lots of trust > > Amen. > > > PS. I'd still like to thank those few exUSR/3Com engineers who take > > their time to monitor this list and provide useful hints. Although most > > probably this isn't their duty > > DEFINITELY! They're worth their weight in gold! > > Regards, > > Bob Purdon, > Technical Manager, > Southern Internet Services. > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > =-----------------= = | Charles Sprickman Internet Channel | | INCH System Administration Team (212)243-5200 | | spork@inch.com access@inch.com | = =----------------=

The easy way to upgrade the arc is as follows: on the arc add a tftp client add tftp cli <ip addr of the unix box> now from your unix box tftp the code to the arc and call the new code as netserve.dmf once the tftp is done - when ever you reboot the arc the new code will be loaded. krish \ T.S.V. Krishnan \ \ Network System Engineer \ ( : - : ) \ 3Com ............ \ ----------------------------------------------/ tkrishna@bubba.ae.usr.com ----------------------------/ http://interproc.ae.usr.com ----/ The Yadda Yadda Search - for simple anwers - http://interproc.ae.usr.com/tkb.html Any Sufficiently advanced bug is indistinguishable for a feature. - Rick Kulawiec On Fri, 31 Jul 1998, Brian wrote: > Its been a while since I have upgraded ARC code. > > Can someone please refresh my memory: > > Can you upgrade the arc code while users are online, and then just do a > reboot to come up on the new code? Or will upgrading code effect users? > I know the reboot is of course going to drop users, but I am wondering if > users can still dial in and all while the code upgrade is in progress. > > Brian > > > -------------------------------------------------------------------------- > Brian Feeny (BF304) | ShreveNet Inc. - Premium Internet Service Provider > Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ > signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, > (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1 > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

> I know what alot of you are going through. I can honestly say I haven't > "called" tech support in about 10 months We rarely call them either. Now we find that to get spares in any reasonable timeframe we need a support contract. Fine, I can grok that. Shame the annual fee seems to be about 25% of what we paid for the damn stuff. Prior to needing a contract, USR were very helpful with warranty exchanges. 3COM are a pain in the ass. We weren't even formally told we needed a contract, or what the details would be. First we really knew was when we needed something. Great. > and that what we have here going now is extremely reliable (every once > in a while an interface goes down however). Extremely reliable here too, until a NETserver started rebooting. Apparently they consider 30 day replacements on this type of equipment to be an appropriate warranty system. That's 30 days AFTER you send them the dud. Geez, these aren't $200 disposable modems or network cards! > I feel things have gotten better. In Australia, when USR were USR, things were wonderful. Now that USR is 3COM it's damn painful. We're very unlikely to do any further business with them, and have already approached the local Livingston reseller. From memory, Livingston were about half the price too... Regards, Bob Purdon, Technical Manager, Southern Internet Services.

On Fri, 31 Jul 1998, Randy Cosby wrote: > Just wanted to verify, the file name is netserve.dmf for the hiperarc? > The file can be named as ne040035.dmf or any dmf name, the hiper arc only if it sees a file called netserve.dmf - then it will try to load the same. Else it it just ignore the other files. krish > > > > -----Original Message----- > > From: owner-usr-tc@lists.xmission.com > > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Tatai SV Krishnan > > Sent: Thursday, July 30, 1998 10:35 PM > > To: Brian > > Cc: USRobotics TC Mailing List > > Subject: Re: (usr-tc) Upgrading ARC code > > > > > > The easy way to upgrade the arc is as follows: > > > > on the arc add a tftp client > > > > add tftp cli <ip addr of the unix box> > > > > now from your unix box tftp the code to the arc > > and call the new code as netserve.dmf > > > > once the tftp is done - when ever you reboot the arc the new code will be > > loaded. > > > > krish > > > > ----------------------------------------- > > \ T.S.V. Krishnan \ > > \ Network System Engineer \ ( : - : ) > > \ 3Com ............ \ > > ----------------------------------------------/ > > tkrishna@bubba.ae.usr.com > > ----------------------------/ http://interproc.ae.usr.com ----/ > > The Yadda Yadda Search - for simple anwers - > http://interproc.ae.usr.com/tkb.html > -------------------------------------------------------------------------\ > Any Sufficiently advanced bug is indistinguishable for a feature. > - Rick Kulawiec > -------------------------------------------------------------------------/ > > On Fri, 31 Jul 1998, Brian wrote: > > > Its been a while since I have upgraded ARC code. > > > > Can someone please refresh my memory: > > > > Can you upgrade the arc code while users are online, and then just do a > > reboot to come up on the new code? Or will upgrading code effect users? > > I know the reboot is of course going to drop users, but I am wondering if > > users can still dial in and all while the code upgrade is in progress. > > > > Brian > > > > > > -------------------------------------------------------------------------- > > Brian Feeny (BF304) | ShreveNet Inc. - Premium Internet Service Provider > > Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ > > signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, > > (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1 > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

On Thu, 30 Jul 1998, Pete Ashdown wrote: > Brett Hawn said once upon a time: > >We've upgraded several of our HiPer's the the V.90 code, and they're working > >great... for x2/v90 customers. However they appear to really _BITE_ for > >folks using v.34. Most of them get really shoddy connection speeds (we've > >personally seen as low as 9600bd) and get booted randomly with 'lost > >carrier'. Has anyone else seen this? USR is there is fix for this? > The new code has been working great here. No major problems across the > board. I'll have to test out the v.34 problems. Are you talking about HiperDSP 1.2.5? We are about to upgrade for v.90 and I want to make sure we are using the right release. I don't like suprises. ^_^;

Have any of you negotiated out of a 3 year contract with USWest? I think I remember a comment from someone here about that fairly recently. We have been contacted by a reseller offering a 6% discount and are wondering what real world experiences ISP's are seeing with terminating USWest contracts. I have some frame relay circuits and also some digital trunks going to our TC hubs. They are 3 year contracts for the most part that are about a year old. We've moved and upgraded lines over the past year or so too and it would be a mess tracing those back to the original agreement. I was told when they first came out with these a couple years ago by my rep that USWest would not enforce the penalty side but he has long since moved on. I hear that the penalty is 40% of the remaining term. Even at 6% the savings are substantial, any of you buying from resellers? Thanks, Greg Coffey CoffeyNet 307-234-5443 142 S. Center St. www.coffey.com Casper, WY 82601

It has recently been determined that our ARC is sending 2 Accounting requests. We are running 4.0.69 AUTHENTICATION SETTINGS Local Authentication is: DISABLED RADIUS Authentication is: ENABLED Hint Assigned is: DISABLED Primary Server is: 208.206.76.5 Primary Server Port is: 1645 Secondary Server is: 208.206.76.23 Secondary Server Port is: 1645 Retransmission Timeout: 3 Max Retranmissions: 10 HiPer>> show accOUNTING ACCOUNTING SETTINGS: Use_Servers: ONE Primary Server is: 208.206.76.5 Primary Server Port is: 1646 Secondary Server is: 208.206.76.23 Secondary Server Port is: 1646 Retransmission Timeout: 60 Accounting Start Time: CONNECTION Status is: ENABLED SYSTEM DESCRIPTION System Descriptor: 3Com Corporation HiPer Access Router Card Built on Feb 21 1998 at 12:19:26. Object ID: 1.3.6.1.4.1.429.2.19 System UpTime: 5d 20:15:28 System Contact: signal@shreve.net System Name: usr1ts1 System Location: ShreveNet System Services: Internet EndToEnd Applications System Transmit Authentication Name: HiPer System Version: V4.0.69 Has anyone seen this? *** Received from 208.206.76.35 port 1645 .... Code: Accounting-Request Identifier: 20 Authentic: )<198>.<147>P<236><21><154><210><202><200><22><10><224>}<162> Attributes: User-Name = "bnsattys" Client-Id = 208.206.76.35 Acct-Status-Type = Stop Acct-Session-Id = "4c100402" Acct-Delay-Time = 0 Acct-Authentic = RADIUS User-Service-Type = Framed-User NAS-Port-Type = 0 Client-Port-Id = 773 USR-Mystery-1 = "<0><0><6><237>" USR-Chassis-Call-Slot = 3 USR-Chassis-Call-Span = 1 USR-Chassis-Call-Channel = 5 USR-Unauthenticated-Time = 10 Calling-Station-Id = "3182269036" Called-Station-Id = "3182134660" USR-Modulation-Type = x2 USR-Simplified-MNP-Levels = ccittV42 USR-Simplified-V42bis-Usage = ccittV42bis USR-Connect-Speed = 0 Framed-Protocol = PPP Framed-Address = 208.214.44.51 USR-MP-MRRU = 0 USR-Mystery-2 = "<0><0><0><2>" Acct-Multi-Session-Id = "4adf" Acct-Session-Time = 1214 Acct-Terminate-Cause = ACCT-TERM-USER-REQUEST Acct-Input-Octets = 5326 Acct-Output-Octets = 6556 Acct-Input-Packets = 88 Acct-Output-Packets = 84 Fri Jul 31 00:40:55 1998: DEBUG: Handling request with Realm 'DEFAULT' Fri Jul 31 00:40:55 1998: DEBUG: Handling with Radius::AuthFILE Fri Jul 31 00:40:55 1998: DEBUG: Deleting session for bnsattys, , *** Sending to 208.206.76.35 port 1645 .... Code: Accounting-Response Identifier: 20 Authentic: )<198>.<147>P<236><21><154><210><202><200><22><10><224>}<162> Attributes: *** Received from 208.206.76.35 port 1645 .... Code: Accounting-Request Identifier: 21 Authentic: R<145>ah<177><26>`<187>8<229><226>g<198><184><218><0> Attributes: User-Name = "bnsattys" Client-Id = 208.206.76.35 Acct-Status-Type = Stop Acct-Session-Id = "4c100402" Acct-Delay-Time = 0 Acct-Authentic = RADIUS User-Service-Type = Framed-User NAS-Port-Type = 0 Client-Port-Id = 773 USR-Mystery-1 = "<0><0><6><237>" USR-Chassis-Call-Slot = 3 USR-Chassis-Call-Span = 1 USR-Chassis-Call-Channel = 5 USR-Unauthenticated-Time = 10 Calling-Station-Id = "3182269036" Called-Station-Id = "3182134660" USR-Modulation-Type = x2 USR-Simplified-MNP-Levels = ccittV42 USR-Simplified-V42bis-Usage = ccittV42bis USR-Connect-Speed = 25494408 Framed-Protocol = PPP Framed-Address = 208.214.44.51 USR-MP-MRRU = 0 USR-Mystery-2 = "<0><0><0><2>" Acct-Multi-Session-Id = "4adf" Acct-Session-Time = 1214 Acct-Terminate-Cause = ACCT-TERM-USER-REQUEST Acct-Input-Octets = 5326 Acct-Output-Octets = 6556 Acct-Input-Packets = 88 Acct-Output-Packets = 84 Fri Jul 31 00:40:55 1998: DEBUG: Handling request with Realm 'DEFAULT' Fri Jul 31 00:40:55 1998: DEBUG: Handling with Radius::AuthFILE Fri Jul 31 00:40:55 1998: DEBUG: Deleting session for bnsattys, , *** Sending to 208.206.76.35 port 1645 .... Code: Accounting-Response Identifier: 21 Authentic: R<145>ah<177><26>`<187>8<229><226>g<198><184><218><0> Attributes:

yes, just did it yesterday. Flash then reboot. customers won't be affected. One thing I did find was that when I rebooted the first DSP ( after loading new code on both arc and dsp ) was that the first dsp in the hunt group locked up. Maybe because it was flooded with calls. I found it better to let it boot and then plug span 1 back in. -----Original Message----- >Its been a while since I have upgraded ARC code. > >Can someone please refresh my memory: > >Can you upgrade the arc code while users are online, and then just do a >reboot to come up on the new code? Or will upgrading code effect users? >I know the reboot is of course going to drop users, but I am wondering if >users can still dial in and all while the code upgrade is in progress. > >Brian > > >-------------------------------------------------------------------------- >Brian Feeny (BF304) | ShreveNet Inc. - Premium Internet Service Provider >Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ >signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, >(318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1 > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

> Tell you what, since changeover to 3Com, things DO have improved, at > least for me. With USR you'd die before getting any help, unless you had > contract. I'm finding the opposite here - with USR we had excellent support. Now we're getting a much lower level of service :-( > What concerns hardware swaps, then of the few that I had to do, all went > impressively smooth and fast, even to the extent that I was amused to > the extreme. (they found that I have PSUs that might explode ;), they > said they would replace them for free, and when I sent them confirm that > yes, I want to, things went off and rolled in full speed, I was notified > by mail from at least 5 people who all did handle the shipment, was > given the DHL tracking number and in just few days the PSUs were here) We typically had overnight service from USR. We've since been told our NETserver cards are suspect (the FC2/FC3 chipset thing, that we raised with them shortly after we purchased the units and were told there was no known problem). Getting replacements is a painful process. I think we're up to a week or more now, and I still haven't heard what's happening. > And, when Hiper did crash every 5 mins for its bugs, 3com sent an > engineer over here, gave us engineering version of code that was more > stable, Back when USR were USR, they sent an engineer down here to isolate one particular problem. Very impressive service back then. > (I guess sort of new market area penetration). Well, this leads to > simple general attitude: as long as you are of interest to the vendor, > they dance around you, and as soon as they loose interest in you, you're > on your own. I'm inclined to think that's what's happened here. I'll bet the Telstra's and Optus's (large Telcos here in Oz) are getting better responses than we are. > Basically, when you buy 3Com hardware, expect to get it working > yourself, (just as some 3com PCI network adapter?) and if you can't, > tough luck. Don't expect any help from vendor, and you might be even > pleased when it really does help you... We've had no problems when it comes to phone support, although we do resolve most issues ourselves anyway. It's what happens (lately) if something breaks :-( > I guess that 3Com has lost lots of trust Amen. > PS. I'd still like to thank those few exUSR/3Com engineers who take > their time to monitor this list and provide useful hints. Although most > probably this isn't their duty DEFINITELY! They're worth their weight in gold! Regards, Bob Purdon, Technical Manager, Southern Internet Services.

Just wanted to verify, the file name is netserve.dmf for the hiperarc? > -----Original Message----- > From: owner-usr-tc@lists.xmission.com > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Tatai SV Krishnan > Sent: Thursday, July 30, 1998 10:35 PM > To: Brian > Cc: USRobotics TC Mailing List > Subject: Re: (usr-tc) Upgrading ARC code > > > The easy way to upgrade the arc is as follows: > > on the arc add a tftp client > > add tftp cli <ip addr of the unix box> > > now from your unix box tftp the code to the arc > and call the new code as netserve.dmf > > once the tftp is done - when ever you reboot the arc the new code will be > loaded. > > krish > > ----------------------------------------- > \ T.S.V. Krishnan \ > \ Network System Engineer \ ( : - : ) > \ 3Com ............ \ > ----------------------------------------------/ > tkrishna@bubba.ae.usr.com > ----------------------------/ http://interproc.ae.usr.com ----/ > The Yadda Yadda Search - for simple anwers - http://interproc.ae.usr.com/tkb.html Any Sufficiently advanced bug is indistinguishable for a feature. - Rick Kulawiec On Fri, 31 Jul 1998, Brian wrote: > Its been a while since I have upgraded ARC code. > > Can someone please refresh my memory: > > Can you upgrade the arc code while users are online, and then just do a > reboot to come up on the new code? Or will upgrading code effect users? > I know the reboot is of course going to drop users, but I am wondering if > users can still dial in and all while the code upgrade is in progress. > > Brian > > > -------------------------------------------------------------------------- > Brian Feeny (BF304) | ShreveNet Inc. - Premium Internet Service Provider > Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ > signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, > (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1 > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

On Fri, 31 Jul 1998, Marcelo Souza wrote: > > I'm with the same problem. It was told here that it olny happen > with Livingston Radius on Solaris and BSDI Unix box, but it seems you are > not using Livingston Radius, are you? > > - Marcelo This is not a problem with the RADIUS. This is a known problem with ARC code. I was told by a 3com engineer (krishna) that 4.0.29 and 4.0.30 has this fixed. That is the fix. Brian > > On Fri, 31 Jul 1998, Brian wrote: > > |It has recently been determined that our ARC is sending 2 Accounting > |requests. > | > |We are running 4.0.69 > | > |AUTHENTICATION SETTINGS > |Local Authentication is: DISABLED > |RADIUS Authentication is: ENABLED > |Hint Assigned is: DISABLED > |Primary Server is: 208.206.76.5 > |Primary Server Port is: 1645 > |Secondary Server is: 208.206.76.23 > |Secondary Server Port is: 1645 > |Retransmission Timeout: 3 > |Max Retranmissions: 10 > |HiPer>> show accOUNTING > | > |ACCOUNTING SETTINGS: > |Use_Servers: ONE > |Primary Server is: 208.206.76.5 > |Primary Server Port is: 1646 > |Secondary Server is: 208.206.76.23 > |Secondary Server Port is: 1646 > |Retransmission Timeout: 60 > |Accounting Start Time: CONNECTION > |Status is: ENABLED > | > |SYSTEM DESCRIPTION System Descriptor: > | 3Com Corporation HiPer Access Router Card Built on Feb 21 1998 at > |12:19:26. > |Object ID: 1.3.6.1.4.1.429.2.19 > |System UpTime: 5d 20:15:28 > |System Contact: signal@shreve.net > |System Name: usr1ts1 > |System Location: ShreveNet > |System Services: Internet EndToEnd Applications > |System Transmit Authentication Name: HiPer > |System Version: V4.0.69 > | > |Has anyone seen this? > | > |*** Received from 208.206.76.35 port 1645 .... > |Code: Accounting-Request > |Identifier: 20 > |Authentic: )<198>.<147>P<236><21><154><210><202><200><22><10><224>}<162> > |Attributes: > | User-Name = "bnsattys" > | Client-Id = 208.206.76.35 > | Acct-Status-Type = Stop > | Acct-Session-Id = "4c100402" > | Acct-Delay-Time = 0 > | Acct-Authentic = RADIUS > | User-Service-Type = Framed-User > | NAS-Port-Type = 0 > | Client-Port-Id = 773 > | USR-Mystery-1 = "<0><0><6><237>" > | USR-Chassis-Call-Slot = 3 > | USR-Chassis-Call-Span = 1 > | USR-Chassis-Call-Channel = 5 > | USR-Unauthenticated-Time = 10 > | Calling-Station-Id = "3182269036" > | Called-Station-Id = "3182134660" > | USR-Modulation-Type = x2 > | USR-Simplified-MNP-Levels = ccittV42 > | USR-Simplified-V42bis-Usage = ccittV42bis > | USR-Connect-Speed = 0 > | Framed-Protocol = PPP > | Framed-Address = 208.214.44.51 > | USR-MP-MRRU = 0 > | USR-Mystery-2 = "<0><0><0><2>" > | Acct-Multi-Session-Id = "4adf" > | Acct-Session-Time = 1214 > | Acct-Terminate-Cause = ACCT-TERM-USER-REQUEST > | Acct-Input-Octets = 5326 > | Acct-Output-Octets = 6556 > | Acct-Input-Packets = 88 > | Acct-Output-Packets = 84 > |Fri Jul 31 00:40:55 1998: DEBUG: Handling request with Realm 'DEFAULT' > |Fri Jul 31 00:40:55 1998: DEBUG: Handling with Radius::AuthFILE > |Fri Jul 31 00:40:55 1998: DEBUG: Deleting session for bnsattys, , > |*** Sending to 208.206.76.35 port 1645 .... > |Code: Accounting-Response > |Identifier: 20 > |Authentic: )<198>.<147>P<236><21><154><210><202><200><22><10><224>}<162> > |Attributes: > |*** Received from 208.206.76.35 port 1645 .... > |Code: Accounting-Request > |Identifier: 21 > |Authentic: R<145>ah<177><26>`<187>8<229><226>g<198><184><218><0> > |Attributes: > | User-Name = "bnsattys" > | Client-Id = 208.206.76.35 > | Acct-Status-Type = Stop > | Acct-Session-Id = "4c100402" > | Acct-Delay-Time = 0 > | Acct-Authentic = RADIUS > | User-Service-Type = Framed-User > | NAS-Port-Type = 0 > | Client-Port-Id = 773 > | USR-Mystery-1 = "<0><0><6><237>" > | USR-Chassis-Call-Slot = 3 > | USR-Chassis-Call-Span = 1 > | USR-Chassis-Call-Channel = 5 > | USR-Unauthenticated-Time = 10 > | Calling-Station-Id = "3182269036" > | Called-Station-Id = "3182134660" > | USR-Modulation-Type = x2 > | USR-Simplified-MNP-Levels = ccittV42 > | USR-Simplified-V42bis-Usage = ccittV42bis > | USR-Connect-Speed = 25494408 > | Framed-Protocol = PPP > | Framed-Address = 208.214.44.51 > | USR-MP-MRRU = 0 > | USR-Mystery-2 = "<0><0><0><2>" > | Acct-Multi-Session-Id = "4adf" > | Acct-Session-Time = 1214 > | Acct-Terminate-Cause = ACCT-TERM-USER-REQUEST > | Acct-Input-Octets = 5326 > | Acct-Output-Octets = 6556 > | Acct-Input-Packets = 88 > | Acct-Output-Packets = 84 > |Fri Jul 31 00:40:55 1998: DEBUG: Handling request with Realm 'DEFAULT' > |Fri Jul 31 00:40:55 1998: DEBUG: Handling with Radius::AuthFILE > |Fri Jul 31 00:40:55 1998: DEBUG: Deleting session for bnsattys, , > |*** Sending to 208.206.76.35 port 1645 .... > |Code: Accounting-Response > |Identifier: 21 > |Authentic: R<145>ah<177><26>`<187>8<229><226>g<198><184><218><0> > |Attributes: > | > | > | > | > |- > | To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > | with "unsubscribe usr-tc" in the body of the message. > | For information on digests or retrieving files and old messages send > | "help" to the same address. Do not use quotes in your message. > | > > - Marcelo > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > Brian Feeny (BF304) | ShreveNet Inc. - Premium Internet Service Provider Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1

On Fri, 31 Jul 1998, Marcelo Souza wrote: > > I'm with the same problem. It was told here that it olny happen > with Livingston Radius on Solaris and BSDI Unix box, but it seems you are > not using Livingston Radius, are you? > > - Marcelo This is not a problem with the RADIUS. This is a known problem with ARC code. I was told by a 3com engineer (krishna) that 4.0.29 and 4.0.30 has this fixed. That is the fix. Brian > > On Fri, 31 Jul 1998, Brian wrote: > > |It has recently been determined that our ARC is sending 2 Accounting > |requests. > | > |We are running 4.0.69 > | > |AUTHENTICATION SETTINGS > |Local Authentication is: DISABLED > |RADIUS Authentication is: ENABLED > |Hint Assigned is: DISABLED > |Primary Server is: 208.206.76.5 > |Primary Server Port is: 1645 > |Secondary Server is: 208.206.76.23 > |Secondary Server Port is: 1645 > |Retransmission Timeout: 3 > |Max Retranmissions: 10 > |HiPer>> show accOUNTING > | > |ACCOUNTING SETTINGS: > |Use_Servers: ONE > |Primary Server is: 208.206.76.5 > |Primary Server Port is: 1646 > |Secondary Server is: 208.206.76.23 > |Secondary Server Port is: 1646 > |Retransmission Timeout: 60 > |Accounting Start Time: CONNECTION > |Status is: ENABLED > | > |SYSTEM DESCRIPTION System Descriptor: > | 3Com Corporation HiPer Access Router Card Built on Feb 21 1998 at > |12:19:26. > |Object ID: 1.3.6.1.4.1.429.2.19 > |System UpTime: 5d 20:15:28 > |System Contact: signal@shreve.net > |System Name: usr1ts1 > |System Location: ShreveNet > |System Services: Internet EndToEnd Applications > |System Transmit Authentication Name: HiPer > |System Version: V4.0.69 > | > |Has anyone seen this? > | > |*** Received from 208.206.76.35 port 1645 .... > |Code: Accounting-Request > |Identifier: 20 > |Authentic: )<198>.<147>P<236><21><154><210><202><200><22><10><224>}<162> > |Attributes: > | User-Name = "bnsattys" > | Client-Id = 208.206.76.35 > | Acct-Status-Type = Stop > | Acct-Session-Id = "4c100402" > | Acct-Delay-Time = 0 > | Acct-Authentic = RADIUS > | User-Service-Type = Framed-User > | NAS-Port-Type = 0 > | Client-Port-Id = 773 > | USR-Mystery-1 = "<0><0><6><237>" > | USR-Chassis-Call-Slot = 3 > | USR-Chassis-Call-Span = 1 > | USR-Chassis-Call-Channel = 5 > | USR-Unauthenticated-Time = 10 > | Calling-Station-Id = "3182269036" > | Called-Station-Id = "3182134660" > | USR-Modulation-Type = x2 > | USR-Simplified-MNP-Levels = ccittV42 > | USR-Simplified-V42bis-Usage = ccittV42bis > | USR-Connect-Speed = 0 > | Framed-Protocol = PPP > | Framed-Address = 208.214.44.51 > | USR-MP-MRRU = 0 > | USR-Mystery-2 = "<0><0><0><2>" > | Acct-Multi-Session-Id = "4adf" > | Acct-Session-Time = 1214 > | Acct-Terminate-Cause = ACCT-TERM-USER-REQUEST > | Acct-Input-Octets = 5326 > | Acct-Output-Octets = 6556 > | Acct-Input-Packets = 88 > | Acct-Output-Packets = 84 > |Fri Jul 31 00:40:55 1998: DEBUG: Handling request with Realm 'DEFAULT' > |Fri Jul 31 00:40:55 1998: DEBUG: Handling with Radius::AuthFILE > |Fri Jul 31 00:40:55 1998: DEBUG: Deleting session for bnsattys, , > |*** Sending to 208.206.76.35 port 1645 .... > |Code: Accounting-Response > |Identifier: 20 > |Authentic: )<198>.<147>P<236><21><154><210><202><200><22><10><224>}<162> > |Attributes: > |*** Received from 208.206.76.35 port 1645 .... > |Code: Accounting-Request > |Identifier: 21 > |Authentic: R<145>ah<177><26>`<187>8<229><226>g<198><184><218><0> > |Attributes: > | User-Name = "bnsattys" > | Client-Id = 208.206.76.35 > | Acct-Status-Type = Stop > | Acct-Session-Id = "4c100402" > | Acct-Delay-Time = 0 > | Acct-Authentic = RADIUS > | User-Service-Type = Framed-User > | NAS-Port-Type = 0 > | Client-Port-Id = 773 > | USR-Mystery-1 = "<0><0><6><237>" > | USR-Chassis-Call-Slot = 3 > | USR-Chassis-Call-Span = 1 > | USR-Chassis-Call-Channel = 5 > | USR-Unauthenticated-Time = 10 > | Calling-Station-Id = "3182269036" > | Called-Station-Id = "3182134660" > | USR-Modulation-Type = x2 > | USR-Simplified-MNP-Levels = ccittV42 > | USR-Simplified-V42bis-Usage = ccittV42bis > | USR-Connect-Speed = 25494408 > | Framed-Protocol = PPP > | Framed-Address = 208.214.44.51 > | USR-MP-MRRU = 0 > | USR-Mystery-2 = "<0><0><0><2>" > | Acct-Multi-Session-Id = "4adf" > | Acct-Session-Time = 1214 > | Acct-Terminate-Cause = ACCT-TERM-USER-REQUEST > | Acct-Input-Octets = 5326 > | Acct-Output-Octets = 6556 > | Acct-Input-Packets = 88 > | Acct-Output-Packets = 84 > |Fri Jul 31 00:40:55 1998: DEBUG: Handling request with Realm 'DEFAULT' > |Fri Jul 31 00:40:55 1998: DEBUG: Handling with Radius::AuthFILE > |Fri Jul 31 00:40:55 1998: DEBUG: Deleting session for bnsattys, , > |*** Sending to 208.206.76.35 port 1645 .... > |Code: Accounting-Response > |Identifier: 21 > |Authentic: R<145>ah<177><26>`<187>8<229><226>g<198><184><218><0> > |Attributes: > | > | > | > | > |- > | To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > | with "unsubscribe usr-tc" in the body of the message. > | For information on digests or retrieving files and old messages send > | "help" to the same address. Do not use quotes in your message. > | > > - Marcelo > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > Brian Feeny (BF304) | ShreveNet Inc. - Premium Internet Service Provider Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1

On Fri, 31 Jul 1998, Marcelo Souza wrote: > > On Fri, 31 Jul 1998, Jeff Binkley wrote: > > |-> It has recently been determined that our ARC is sending 2 Accounting > |-> requests. > |-> > |-> We are running 4.0.69 > | > |Try 4.0.30, the latest version. I believe it is fixed in this release... > > 4.0.29 has the same problem, and I didn't see it in the release > notes of the 4.0.30. That is odd, I was told 4.0.29 had this fixed. I checked the release notes as well and saw no fix. I am hoping its fixed though, as I am about to go upgrade some chassis to fix this. Brian > > > - Marcelo > > | > |Jeff Binkley > |ASA Network Computing > | > |- > | To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > | with "unsubscribe usr-tc" in the body of the message. > | For information on digests or retrieving files and old messages send > | "help" to the same address. Do not use quotes in your message. > | > > - Marcelo > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > Brian Feeny (BF304) | ShreveNet Inc. - Premium Internet Service Provider Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1

-> It has recently been determined that our ARC is sending 2 Accounting -> requests. -> -> We are running 4.0.69 Try 4.0.30, the latest version. I believe it is fixed in this release... Jeff Binkley ASA Network Computing

Its been a while since I have upgraded ARC code. Can someone please refresh my memory: Can you upgrade the arc code while users are online, and then just do a reboot to come up on the new code? Or will upgrading code effect users? I know the reboot is of course going to drop users, but I am wondering if users can still dial in and all while the code upgrade is in progress. Brian Brian Feeny (BF304) | ShreveNet Inc. - Premium Internet Service Provider Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1

I'm with the same problem. It was told here that it olny happen with Livingston Radius on Solaris and BSDI Unix box, but it seems you are not using Livingston Radius, are you? - Marcelo On Fri, 31 Jul 1998, Brian wrote: |It has recently been determined that our ARC is sending 2 Accounting |requests. | |We are running 4.0.69 | |AUTHENTICATION SETTINGS |Local Authentication is: DISABLED |RADIUS Authentication is: ENABLED |Hint Assigned is: DISABLED |Primary Server is: 208.206.76.5 |Primary Server Port is: 1645 |Secondary Server is: 208.206.76.23 |Secondary Server Port is: 1645 |Retransmission Timeout: 3 |Max Retranmissions: 10 |HiPer>> show accOUNTING | |ACCOUNTING SETTINGS: |Use_Servers: ONE |Primary Server is: 208.206.76.5 |Primary Server Port is: 1646 |Secondary Server is: 208.206.76.23 |Secondary Server Port is: 1646 |Retransmission Timeout: 60 |Accounting Start Time: CONNECTION |Status is: ENABLED | |SYSTEM DESCRIPTION System Descriptor: | 3Com Corporation HiPer Access Router Card Built on Feb 21 1998 at |12:19:26. |Object ID: 1.3.6.1.4.1.429.2.19 |System UpTime: 5d 20:15:28 |System Contact: signal@shreve.net |System Name: usr1ts1 |System Location: ShreveNet |System Services: Internet EndToEnd Applications |System Transmit Authentication Name: HiPer |System Version: V4.0.69 | |Has anyone seen this? | |*** Received from 208.206.76.35 port 1645 .... |Code: Accounting-Request |Identifier: 20 |Authentic: )<198>.<147>P<236><21><154><210><202><200><22><10><224>}<162> |Attributes: | User-Name = "bnsattys" | Client-Id = 208.206.76.35 | Acct-Status-Type = Stop | Acct-Session-Id = "4c100402" | Acct-Delay-Time = 0 | Acct-Authentic = RADIUS | User-Service-Type = Framed-User | NAS-Port-Type = 0 | Client-Port-Id = 773 | USR-Mystery-1 = "<0><0><6><237>" | USR-Chassis-Call-Slot = 3 | USR-Chassis-Call-Span = 1 | USR-Chassis-Call-Channel = 5 | USR-Unauthenticated-Time = 10 | Calling-Station-Id = "3182269036" | Called-Station-Id = "3182134660" | USR-Modulation-Type = x2 | USR-Simplified-MNP-Levels = ccittV42 | USR-Simplified-V42bis-Usage = ccittV42bis | USR-Connect-Speed = 0 | Framed-Protocol = PPP | Framed-Address = 208.214.44.51 | USR-MP-MRRU = 0 | USR-Mystery-2 = "<0><0><0><2>" | Acct-Multi-Session-Id = "4adf" | Acct-Session-Time = 1214 | Acct-Terminate-Cause = ACCT-TERM-USER-REQUEST | Acct-Input-Octets = 5326 | Acct-Output-Octets = 6556 | Acct-Input-Packets = 88 | Acct-Output-Packets = 84 |Fri Jul 31 00:40:55 1998: DEBUG: Handling request with Realm 'DEFAULT' |Fri Jul 31 00:40:55 1998: DEBUG: Handling with Radius::AuthFILE |Fri Jul 31 00:40:55 1998: DEBUG: Deleting session for bnsattys, , |*** Sending to 208.206.76.35 port 1645 .... |Code: Accounting-Response |Identifier: 20 |Authentic: )<198>.<147>P<236><21><154><210><202><200><22><10><224>}<162> |Attributes: |*** Received from 208.206.76.35 port 1645 .... |Code: Accounting-Request |Identifier: 21 |Authentic: R<145>ah<177><26>`<187>8<229><226>g<198><184><218><0> |Attributes: | User-Name = "bnsattys" | Client-Id = 208.206.76.35 | Acct-Status-Type = Stop | Acct-Session-Id = "4c100402" | Acct-Delay-Time = 0 | Acct-Authentic = RADIUS | User-Service-Type = Framed-User | NAS-Port-Type = 0 | Client-Port-Id = 773 | USR-Mystery-1 = "<0><0><6><237>" | USR-Chassis-Call-Slot = 3 | USR-Chassis-Call-Span = 1 | USR-Chassis-Call-Channel = 5 | USR-Unauthenticated-Time = 10 | Calling-Station-Id = "3182269036" | Called-Station-Id = "3182134660" | USR-Modulation-Type = x2 | USR-Simplified-MNP-Levels = ccittV42 | USR-Simplified-V42bis-Usage = ccittV42bis | USR-Connect-Speed = 25494408 | Framed-Protocol = PPP | Framed-Address = 208.214.44.51 | USR-MP-MRRU = 0 | USR-Mystery-2 = "<0><0><0><2>" | Acct-Multi-Session-Id = "4adf" | Acct-Session-Time = 1214 | Acct-Terminate-Cause = ACCT-TERM-USER-REQUEST | Acct-Input-Octets = 5326 | Acct-Output-Octets = 6556 | Acct-Input-Packets = 88 | Acct-Output-Packets = 84 |Fri Jul 31 00:40:55 1998: DEBUG: Handling request with Realm 'DEFAULT' |Fri Jul 31 00:40:55 1998: DEBUG: Handling with Radius::AuthFILE |Fri Jul 31 00:40:55 1998: DEBUG: Deleting session for bnsattys, , |*** Sending to 208.206.76.35 port 1645 .... |Code: Accounting-Response |Identifier: 21 |Authentic: R<145>ah<177><26>`<187>8<229><226>g<198><184><218><0> |Attributes: | | | | |- | To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" | with "unsubscribe usr-tc" in the body of the message. | For information on digests or retrieving files and old messages send | "help" to the same address. Do not use quotes in your message. | - Marcelo

I'm with the same problem. It was told here that it olny happen with Livingston Radius on Solaris and BSDI Unix box, but it seems you are not using Livingston Radius, are you? - Marcelo On Fri, 31 Jul 1998, Brian wrote: |It has recently been determined that our ARC is sending 2 Accounting |requests. | |We are running 4.0.69 | |AUTHENTICATION SETTINGS |Local Authentication is: DISABLED |RADIUS Authentication is: ENABLED |Hint Assigned is: DISABLED |Primary Server is: 208.206.76.5 |Primary Server Port is: 1645 |Secondary Server is: 208.206.76.23 |Secondary Server Port is: 1645 |Retransmission Timeout: 3 |Max Retranmissions: 10 |HiPer>> show accOUNTING | |ACCOUNTING SETTINGS: |Use_Servers: ONE |Primary Server is: 208.206.76.5 |Primary Server Port is: 1646 |Secondary Server is: 208.206.76.23 |Secondary Server Port is: 1646 |Retransmission Timeout: 60 |Accounting Start Time: CONNECTION |Status is: ENABLED | |SYSTEM DESCRIPTION System Descriptor: | 3Com Corporation HiPer Access Router Card Built on Feb 21 1998 at |12:19:26. |Object ID: 1.3.6.1.4.1.429.2.19 |System UpTime: 5d 20:15:28 |System Contact: signal@shreve.net |System Name: usr1ts1 |System Location: ShreveNet |System Services: Internet EndToEnd Applications |System Transmit Authentication Name: HiPer |System Version: V4.0.69 | |Has anyone seen this? | |*** Received from 208.206.76.35 port 1645 .... |Code: Accounting-Request |Identifier: 20 |Authentic: )<198>.<147>P<236><21><154><210><202><200><22><10><224>}<162> |Attributes: | User-Name = "bnsattys" | Client-Id = 208.206.76.35 | Acct-Status-Type = Stop | Acct-Session-Id = "4c100402" | Acct-Delay-Time = 0 | Acct-Authentic = RADIUS | User-Service-Type = Framed-User | NAS-Port-Type = 0 | Client-Port-Id = 773 | USR-Mystery-1 = "<0><0><6><237>" | USR-Chassis-Call-Slot = 3 | USR-Chassis-Call-Span = 1 | USR-Chassis-Call-Channel = 5 | USR-Unauthenticated-Time = 10 | Calling-Station-Id = "3182269036" | Called-Station-Id = "3182134660" | USR-Modulation-Type = x2 | USR-Simplified-MNP-Levels = ccittV42 | USR-Simplified-V42bis-Usage = ccittV42bis | USR-Connect-Speed = 0 | Framed-Protocol = PPP | Framed-Address = 208.214.44.51 | USR-MP-MRRU = 0 | USR-Mystery-2 = "<0><0><0><2>" | Acct-Multi-Session-Id = "4adf" | Acct-Session-Time = 1214 | Acct-Terminate-Cause = ACCT-TERM-USER-REQUEST | Acct-Input-Octets = 5326 | Acct-Output-Octets = 6556 | Acct-Input-Packets = 88 | Acct-Output-Packets = 84 |Fri Jul 31 00:40:55 1998: DEBUG: Handling request with Realm 'DEFAULT' |Fri Jul 31 00:40:55 1998: DEBUG: Handling with Radius::AuthFILE |Fri Jul 31 00:40:55 1998: DEBUG: Deleting session for bnsattys, , |*** Sending to 208.206.76.35 port 1645 .... |Code: Accounting-Response |Identifier: 20 |Authentic: )<198>.<147>P<236><21><154><210><202><200><22><10><224>}<162> |Attributes: |*** Received from 208.206.76.35 port 1645 .... |Code: Accounting-Request |Identifier: 21 |Authentic: R<145>ah<177><26>`<187>8<229><226>g<198><184><218><0> |Attributes: | User-Name = "bnsattys" | Client-Id = 208.206.76.35 | Acct-Status-Type = Stop | Acct-Session-Id = "4c100402" | Acct-Delay-Time = 0 | Acct-Authentic = RADIUS | User-Service-Type = Framed-User | NAS-Port-Type = 0 | Client-Port-Id = 773 | USR-Mystery-1 = "<0><0><6><237>" | USR-Chassis-Call-Slot = 3 | USR-Chassis-Call-Span = 1 | USR-Chassis-Call-Channel = 5 | USR-Unauthenticated-Time = 10 | Calling-Station-Id = "3182269036" | Called-Station-Id = "3182134660" | USR-Modulation-Type = x2 | USR-Simplified-MNP-Levels = ccittV42 | USR-Simplified-V42bis-Usage = ccittV42bis | USR-Connect-Speed = 25494408 | Framed-Protocol = PPP | Framed-Address = 208.214.44.51 | USR-MP-MRRU = 0 | USR-Mystery-2 = "<0><0><0><2>" | Acct-Multi-Session-Id = "4adf" | Acct-Session-Time = 1214 | Acct-Terminate-Cause = ACCT-TERM-USER-REQUEST | Acct-Input-Octets = 5326 | Acct-Output-Octets = 6556 | Acct-Input-Packets = 88 | Acct-Output-Packets = 84 |Fri Jul 31 00:40:55 1998: DEBUG: Handling request with Realm 'DEFAULT' |Fri Jul 31 00:40:55 1998: DEBUG: Handling with Radius::AuthFILE |Fri Jul 31 00:40:55 1998: DEBUG: Deleting session for bnsattys, , |*** Sending to 208.206.76.35 port 1645 .... |Code: Accounting-Response |Identifier: 21 |Authentic: R<145>ah<177><26>`<187>8<229><226>g<198><184><218><0> |Attributes: | | | | |- | To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" | with "unsubscribe usr-tc" in the body of the message. | For information on digests or retrieving files and old messages send | "help" to the same address. Do not use quotes in your message. | - Marcelo

On Fri, 31 Jul 1998, Jeff Binkley wrote: |-> It has recently been determined that our ARC is sending 2 Accounting |-> requests. |-> |-> We are running 4.0.69 | |Try 4.0.30, the latest version. I believe it is fixed in this release... 4.0.29 has the same problem, and I didn't see it in the release notes of the 4.0.30. - Marcelo | |Jeff Binkley |ASA Network Computing | |- | To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" | with "unsubscribe usr-tc" in the body of the message. | For information on digests or retrieving files and old messages send | "help" to the same address. Do not use quotes in your message. | - Marcelo

On Thu, 30 Jul 1998, Tatai SV Krishnan wrote: > The easy way to upgrade the arc is as follows: > > on the arc add a tftp client > > add tftp cli <ip addr of the unix box> > > now from your unix box tftp the code to the arc > and call the new code as netserve.dmf > > once the tftp is done - when ever you reboot the arc the new code will be > loaded. And it *should* keep my 4.0.69 configuration file in tact correct? Or will it corrupt it? Brian > > krish > > ----------------------------------------- > \ T.S.V. Krishnan \ > \ Network System Engineer \ ( : - : ) > \ 3Com ............ \ > ----------------------------------------------/ > tkrishna@bubba.ae.usr.com > ----------------------------/ http://interproc.ae.usr.com ----/ > The Yadda Yadda Search - for simple anwers - http://interproc.ae.usr.com/tkb.html > -------------------------------------------------------------------------\ > Any Sufficiently advanced bug is indistinguishable for a feature. > - Rick Kulawiec > -------------------------------------------------------------------------/ > > On Fri, 31 Jul 1998, Brian wrote: > > > Its been a while since I have upgraded ARC code. > > > > Can someone please refresh my memory: > > > > Can you upgrade the arc code while users are online, and then just do a > > reboot to come up on the new code? Or will upgrading code effect users? > > I know the reboot is of course going to drop users, but I am wondering if > > users can still dial in and all while the code upgrade is in progress. > > > > Brian > > > > > > -------------------------------------------------------------------------- > > Brian Feeny (BF304) | ShreveNet Inc. - Premium Internet Service Provider > > Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ > > signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, > > (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1 > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > Brian Feeny (BF304) | ShreveNet Inc. - Premium Internet Service Provider Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1

I am running 3 Netserver Bundles and 1 new Hiper ARC Bundle=2E The Netserve= r Bundles are authenticating fine from the 3com Security and Accounting Server (v=2E5=2E5=2E3) but the ARC Bundle, it fails=2E The server gives me an error: The Packet has been dropped, due to a duplicate=2E=20= I am running the 4=2E0=2E51 on the ARC=2E Can this be a software issue? Please let me know Thanks

-> Its been a while since I have upgraded ARC code. -> -> Can someone please refresh my memory: -> -> Can you upgrade the arc code while users are online, and then just do a -> reboot to come up on the new code? Or will upgrading code effect users? I -> know the reboot is of course going to drop users, but I am wondering if -> users can still dial in and all while the code upgrade is in progress. Yes, it takes a reset to active the new code. Jeff Binkley ASA Network Computing

Thus spake Goemon Ishikawa >3com tech support says, feature x2/v90 enable key is only needed for Quad >cards, and not HiperARC+HiperDSP. >Is this true? Yes, perhaps 3Com realized that the feature key idea for modem modulations was *really* ignorant (IMHO) -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Jeff Mcadams <jeffm@iglou.com> writes: > Yes, perhaps 3Com realized that the feature key idea for modem > modulations was *really* ignorant (IMHO) Well, I don't really disagree with their approach of making it a new feature in the early days, but it's plain strange (replace with your own word choice) that it hasn't yet been permanently enabled on the quads (just as they originally had ISDN as a feature and then converted) - particularly given that the HDMs don't pay any attention to the key. I will admit though, that it provides the only non-intrusive mechanism (on the quads) for disabling/activating the higher speed modulations, so it's got a silver lining that I know we've used to our advantage. -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | ANS Communications, Inc. \ Phone: (914) 701-5327 | / 100 Manhattanville Rd, Purchase, NY 10577 \ Fax: (914) 701-5310 \ \-----------------------------------------------------------------------/

I use the TCM on win95 to pull them out of the performace monitor shows nice table of the connect speeds and the modulation type and all kinds of useful info. -Dave At 06:49 AM 8/1/98 +0900, you wrote: >How can you show on HiperARC if a connection is x2 or v90? > >User says they are connected at 49kbit with x2, but HiperARC shows: > >HiPer>> sh int slot:1/mod:1 > >INTERFACE slot:1/mod:1 SETTINGS >Description: GWC Modem Driver >Type: RS232 >Speed: 33333 >High Speed: 0 >Administrative Status: Up >Operational Status: Up > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > >

In Total Control Manager, run Performance Monitor and you will get all the=20= info you need=2E ____________________Reply Separator____________________ Author: goemon@hirune=2Egol=2Ead=2Ejp How can you show on HiperARC if a connection is x2 or v90? User says they are connected at 49kbit with x2, but HiperARC shows: HiPer>> sh int slot:1/mod:1 INTERFACE slot:1/mod:1 SETTINGS Description: GWC Modem Driver Type: RS232 Speed: 33333 High Speed: 0 Administrative Status: Up Operational Status: Up - To unsubscribe to usr-tc, send an email to "majordomo@xmission=2Ecom" with "unsubscribe usr-tc" in the body of the message=2E For information on digests or retrieving files and old messages send "help" to the same address=2E Do not use quotes in your message=2E

Its strange, I've done all there is to make ripv2 to work on ARC. But it doesn't send anything out. The only way I can make it sending packets though is when I enable RIP authentication. But I really don't want to change settings on 8+ boxes just because that damned thing won't talk otherwise. Whats wrong, krish? ---------------------------------------------------------------------- Andres Kroonmaa mail: andre@online.ee Network Manager Organization: MicroLink Online Tel: 6308 909 Tallinn, Sakala 19 Pho: +372 6308 909 Estonia, EE0001 http://www.online.ee Fax: +372 6308 901 ----------------------------------------------------------------------

Hello, I'm trying to set up a chassis for frame relay, and just wanted to know a few things. -Can anybody tell me if the default LMI type used by the NetServer is ANSI? -Also, does it use the IETF standard for frame relay encapsulation? TIA, -Kevin

This is a multi-part message in MIME format. ------=_NextPart_000_02E5_01BDBCD1.887026C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Here is my solution to the MRTG / Total control usage monitoring. The zip has 4 files mrtg sample cfg hiperdsp.pl tch-pri.pl tch-t1.pl Warning.. I am not a programmer.. I hate programming.. but I hated not having the information easily more so. Please don't criticize my code.. I already know there are better ways to do things. The nice thing about this way is if you take a circuit out of use, it is not counted in your modem totals. I use the 2 values returned for the current connections and the capacity of the chassis. I haven't tested it with mixed quad/dsp chassis either. I'll leave that up to you. Let me know what y'all think Thanks Eric T. Billeter Cable One Internet Engineer 1314 North 3rd Street ebilleter@cableone.net Phoenix, AZ 85004 ------=_NextPart_000_02E5_01BDBCD1.887026C0 Content-Type: application/x-zip-compressed; name="TCH-mrtg.zip" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="TCH-mrtg.zip" UEsDBBQAAAAIAOyu/yTIU6/PtQMAAF8IAAALAAAAaGlwZXJkc3AucGyNVW1v40QQ/kyk/ochTc+2 GpzGx50gaaqUUh1ItD1dKEIiEDn2OFnV2XW9a9pQld/O7IvtpJQTluyd3XnmfWZ9+GUymhdY5vMl 4wedg84hrBntU1mERU5bfXJRYqwwheUW4CIucyHDi5jH1fTylqMKCwUPTK0hyVab+A5LgKwUG/hZ LFks4QYVo0Ot51RYeooYolr/FSbrMyCIvMMcleDO3JVIWcasPSxZEi5ZTnySS+JljoJjSGYduERV lVyONP1nnFc4bKhIx1NJhNn11cfFDKVkgo/t0XeXnxw1E8kdKreRiuzpzUHnSPJNsUI1Gt38+P0M JuADeNaCB5Mz2gzDt+H7cBh+rd/oW/pG34QRLW+9/kEHXj6BUbvZ+r1EbDYVZ2rb75WiosACUi+L nCkYzKeDPvTOP3345beT30kiZQinp7ez8w+XABXPKQpoFcCbN+B0GO0GN4If2hKC14C9+dQrRKk2 sSS8p/GXv55fffyJJPZEimqZs2Q+TVmcnzRqNWH9l1t5HW+wr4nbQjFNMk46szhB2e/ZLLk1ouBs NlxClS6i77zu7ySjzq5NFD4y5Z9YWlbLPeknrVB7shZS7aogkyaZ08W4hnB8VAvB0n4PuVlEyVbm AFyReiXKQnCJlHiagpTxlWxJooxftDKnoFJ6raWrwp7SZ2q86/cUbgoRGBd0/bq3/I6LB24akXqz 1CrLOe86D+qy7nXck8Y8Gx36bdym6JAnIkW98euuCXXXvCJvnbChTxod5lCWMU/9wCWKpO2AkP7d efnqTBTIwaYaXuvrl89OOeB/wIfvh9aHTJT+eBwAPFkplpFVWXtBcZlKlnhfodSrrZnv2+CCIKgF dypKwbQqirRaLKssM7NigX5T8GAPmqLJMBltDBG2JoN/y/f3FDlxqX3lCe6a2RFtO9M02I7gcrvQ LZTTrbtjArpHN0fTbqviEO4rqr7QJh4Q4hKBelOyFEGt6dXNWGNzGvq60ejyG41sE6XagUVRYsYe F4XfDkfjXWvOtjV5SXCltiRFQ+87582cWhzL/BqL9+C98yB4cnfCxK1wDEMgkeeDzhcv4JFXoyOH jj6DfvcZNOw7PvlbDuZqAIPV+BUG/w/GH3N5PBi8JiGPezuMopJrcPPvUI73DJhT+zTNaW6EawEx lw/0szT/yvrCpzuhlrJLPbl1NQzX8NpmTeiHTH0SjClgkx6XY52fJj1DqtsJ6PukhUT7kKiB2Ih0 eaHrxFvP9hlRzbA/YvBtDgJbrn8AUEsDBBQAAAAIANiw/yR5oKqt0gEAAH8JAAAIAAAAbXJ0Zy5j Zme11UFLwzAUB/B7od8hIHhRJ0lEZYiIu2ygVLA7iBNN29gFsyakGXN+eteu0WXWNILbDhsv/7w8 2h/tQqi3jKk+SPuT2XJBk1fGaRkG46JMCafZ4/NTfzlbZGEQBnu9//hUnWKicqofdTqFT33wIqni 1QDV74SzZLJaOJKK9SQHcp5wll5BdNaD1fclDG7J+/VS09LsPzndmHddW48cM82pScVCEw4GotBK cDCcJ2APhsEdyWkspAldDOFlPBhCcCsyOgNjzTj7IJqJAlwcr9bC4OGG5rQw56xjAyJJyvQyDCJZ Zc1kOZnn9DBXYqFYPtVhcD8VSv9ssLre6yJsqvtFUkrr9LpiYsiKmdPtDLYzoihoWs9mx048Wo38 poqcrXbDB7XymbLV36yULX7Qlh/U+PmigtqpIIsK+qaCvKggJxXUTQW1UkF+VJAHFeRHpaPVyG+q yNlqN1Twr08aDVug4C0oeBsKboeCLSj4Gwr2goKdUHA3FNwKBftBwR5QsB+UjlYjv6kiZ6vdQNHV Tf3za+ngD7ZQW9rx0Nq2aCaE+HwDpKn+RFlXSgumCdc46w0+OptdDqFNokvpZiNbarPio9WKOsTa Oadaj5Yj/ymjzpafUEsDBBQAAAAIAPuu/yQQdiFZtQMAAF8IAAAKAAAAdGNoLXByaS5wbI1V+2/i RhD+uUj8D1NCzrbCmcD1IhVCRJpG15Oah8KlqlRaZOwhrGJ2He+6CY3Sv72zDz9I01MR9s7uft/M 7DzWe9/Go3mGeTpfMt5utVt78OXsp/fXN5/DLKWZ/cNZjpHCBJZbgLMoT4UMzyIeFdPzW44qzBQ8 MrWGeHW3ie4xB1jlYgNfxJJFEq5QMVrUeo6FlaeIIar1X2G8PgGCyHtMUQnuzF2IhK2YtYc5i8Ml S2mfeHG0TFFwDMmsA+eoipzLkZb/jNICB5U01CcqJMLs8uJ6MUMpmeBju/TD+Y2TZiK+R+UmUpE9 PWm39iXfZHeoRqOrzz/OYAI+gGcteDA5ockg/BAehYPwO/0Mv6f34Cgc0vDB67Vb8PoXGLXt1mbr d2Ox2RScqW2vm4uCjhaQAZmlTEF/Pu33oHt68+mX3w5/J07CEI6Pb2enn84BCp7SOaBWAO/egdNh 9BvcqJFG8CqsN596mcjVJpIE9zT8/NfTi+ufidBkZMUyZfF8mrAoPayU1t7LrbyMNtjTwm2mmBYZ J5WrKEbZ69oouXFIR7PRcAFVOom+87nXCEUZXRsofGLKP7SyLJY77GetUHuyFlI1VZBJE8rpYlxC OD6phWBJr4vcDCJnd2YBXJK6OcpMcIkUduqDhPE7WYskGb9oZE5BofRYsovMrtJrarzrdRVuMhEY F3T2Orf8notHbgqRajPXKvM57zgPyqTuVNyzxrwYHfqp3KbTIY9FgnrilzUT6pp5g2+dsEefVDrM oswjnviBCxSxbYOQ/ma/vD8RGXKwoYa36vr1r5EO+B/wwdHA+rASuT8eBwDPlsVWZFWWXtC5TCZz fChQ6tHmzPft4YIgKImNjNJhahVZUiyWxWplOsUC/SrhwQ40QRNhMloZImwpBv/m93YUObrUvvIY m2Ya1LoyTYE1iMvtQpdQSrduwwR09q/2p51axR48FJR9oU08IkQ5AtWmZAmCWtOji7HEptTzZaHR 5Tca2SJKtAOLLMcVe1pkft0clXe1OVvW5CXBldoSi5red86bPrU4tvJLLD6A99GD4NndCRM3wgEM gCgv7dY3r+DDGj508OFX4B+/Dm96Pvlb9ueqD/278Rsb/D82/pjLg37/LYY86DY2skKuwV0ADuX2 XgBTqp+qOs2VcCkg4vKRvpbmY1ne93QplCw7lK1bpsPsmr26WmP6IlOhBGNNKEPkAq1j5FXxp+Qd gr5UGpjhLmZYY0yCoeO41rXdxWHpr/0Mg28DENjg/wNQSwMEFAAAAAgA4a7/JD8J/s+5AwAAaAgA AAkAAAB0Y2gtdDEucGyNVW1P40YQ/nyR8h+mIVxskXNIrpzUhKBQiq4nFThdoKrUtJFjj8kKZ9d4 14Ucor+9sy9+CaWnWrJ3dueZZ2ZnZtd730XjRYZ5ulgx3m61W3twffbzu+thkKU0MSt68SzHUGEM qy3AWZinQgZnIQ+L2fkNRxVkCh6YWkOU3G7CO8wBklxs4FqsWCjhChWjRc1zLKw8QwxQrb8G0foE CCLvMEUluHN3IWKWMOsPcxYFK5aSnuyicJWi4BiQWwfOURU5l2Mt/xWmBQ4raaQ3UEiE+eXF5+Uc pWSCT+zSj+dfnDQX0R0qN5GK/OlJu7Uv+Sa7RTUeX336aQ5T8AB61kMPpic0GQbvgw/BMPhev6Mf 6HsUjOj7vtdvt+Dl4xvWdmuz9bqR2GwKztS2381FQTvziV9mKVMwWMwGfeiefvn46++Hf5BNzBCO j2/mpx/PAQqe0jagJoC3b8FxGH6DG9dlhF4F7S1mvUzkahNKQvc0+vy304vPvxC+YZAVq5RFi1nM wvSwoqxjl1t5GW6wr4WbTDEtMk6MSRih7Hdtitw4oo3ZXLhsKl1Bz0XcbySiTK1NEz4y5R1aWRar HesnTagjWQupmhTk0iRytpyUEI6PailY3O8iN4PI2a1ZAFeibo4yE1wiJZ1OQcz4raxFkkxcNDJH UCg9ltZFZlfpMzPR9bsKN5nwTQi6dp0bfsfFAzddSI2Za8p8wTsugrKkO+32pDHPhkO/Vdi0O+SR iFFPvLJjAt0xr9jbIOzWpxWHWZR5yGPPd4kia3s6iL95WN6diAw52FTDa1398mmUA/4HfPhhaGNI RO5NJj7Ak7ViCXmVZRS0L1PJHO8LlHq0NfM8uznf90vDRkVpMzVFFhfLVZEk5pxYoFcV3N+Bxmgy TE4rR4QtRf/f9v0dImcudaw8wqabhmndmabBGoar7VK3UEpXbsMFdPav9medmmIP7guqvtAuHhDC HIF6U7IYQa3p1c1YYlM68mWj0c03HtsminUAyyzHhD0uM68+HFV0tTvb1hQlwZXakhUdes8Fb86p xbHEK7F4D72jHvhP7k6YuhEOYAhk8txuvXkBH9XwkYOPvgE/+jZ8N/bp33KwUAMY3E5eUfD/UPy5 kAeDwWsW8qDbUGSFXIO7AhzK6Z4BU+qgqj/NpXApIOTygX6W5l9Z3vd0LZRWdigPb1kQozW6ul8j +iFTq/gT0LeFzZHLtE5SryoAVe8Q9K3SwIx2MaMKY2J9Y8oMHUdQh/dCMyo19ncMns2Eb+vwD1BL AQIUABQAAAAIAOyu/yTIU6/PtQMAAF8IAAALAAAAAAAAAAEAIAC2gQAAAABoaXBlcmRzcC5wbFBL AQIUABQAAAAIANiw/yR5oKqt0gEAAH8JAAAIAAAAAAAAAAEAIAC2gd4DAABtcnRnLmNmZ1BLAQIU ABQAAAAIAPuu/yQQdiFZtQMAAF8IAAAKAAAAAAAAAAEAIAC2gdYFAAB0Y2gtcHJpLnBsUEsBAhQA FAAAAAgA4a7/JD8J/s+5AwAAaAgAAAkAAAAAAAAAAQAgALaBswkAAHRjaC10MS5wbFBLBQYAAAAA BAAEAN4AAACTDQAAAAA= ------=_NextPart_000_02E5_01BDBCD1.887026C0--

> I'm finding the opposite here - with USR we had excellent support. Now > we're getting a much lower level of service :-( Having said that, over the last few hours we've had some pretty good response from 3COM. We now have a new revision NETserver card and hopefully all is well. I'm very impressed with today's efforts... Regards, Bob Purdon, Technical Manager, Southern Internet Services.

How can you show on HiperARC if a connection is x2 or v90? User says they are connected at 49kbit with x2, but HiperARC shows: HiPer>> sh int slot:1/mod:1 INTERFACE slot:1/mod:1 SETTINGS Description: GWC Modem Driver Type: RS232 Speed: 33333 High Speed: 0 Administrative Status: Up Operational Status: Up

When is x2/v90 feature enable key needed? Using TCM, NMC says x2/v90 feature is disabled. But HiperDSP says x2/v90 is enabled. 3com tech support says, feature x2/v90 enable key is only needed for Quad cards, and not HiperARC+HiperDSP. Is this true?