September 1997

I'm getting the dreaded 'blue screen' problem, running the latest code on the usr-tc and Win95 client. Port-Limit is set to two in merit radius, and I've even tried configuring a static IP for the user (is that required?) Since I'm only dealing with one usr-tc box, I've set the MPIP server off and the 4 MPIP ips to the default 0.0.0.0. Anything else I should check? The client claims he can connect MPIP to another ISP's total control just fine, but not mine. I've also been unsuccessful (same problem) with a similar dialup configuration here that I set up for testing. - lv

On Mon, 1 Sep 1997, Laszlo Vecsey wrote: > I'm getting the dreaded 'blue screen' problem, running the latest code on > the usr-tc and Win95 client. Port-Limit is set to two in merit radius, and > I've even tried configuring a static IP for the user (is that required?) Guess you are getting a blue screen on your Win 95. No you do not need to set a static IP - you need to set either a IP from a pool or a negotiated IP or a static IP. > > Since I'm only dealing with one usr-tc box, I've set the MPIP server off > and the 4 MPIP ips to the default 0.0.0.0. Anything else I should check? > MPIP is only valid if you are going to connect a user to two different NETServers. In your case you do not need any MPIP set - Make sure that MPIP is set to 0.0.0.0 and the MPIP server is set off. > The client claims he can connect MPIP to another ISP's total control just > fine, but not mine. I've also been unsuccessful (same problem) with a > similar dialup configuration here that I set up for testing. In your case since you have only one NETServer what you need here is MLPPP. The statement above which says that your are dealing with one usr-tc box - basically says that you are not doing MPIP. What you need is to dial in and connect to two channels - The basic question is now how your NETServer is configured? Can you dial into the NETServer with a user configured on the NETServer ( not radius ) and connect two channels to the NETServer? krish \ T.S.V. Krishnan \ \ Network System Engineer \ ( : - : ) \ 3Com ............ \ ----------------------------------------------/ tkrishna@bubba.ae.usr.com ----------------------------/ http://interproc.ae.usr.com ----/ Any Sufficiently advanced bug is indistinguishable for a feature. - Rick Kulawiec > > - lv > >

On Mon, 1 Sep 1997, Laszlo Vecsey wrote: > I'm getting the dreaded 'blue screen' problem, running the latest code on > the usr-tc and Win95 client. Port-Limit is set to two in merit radius, and > I've even tried configuring a static IP for the user (is that required?) Guess you are getting a blue screen on your Win 95. No you do not need to set a static IP - you need to set either a IP from a pool or a negotiated IP or a static IP. > > Since I'm only dealing with one usr-tc box, I've set the MPIP server off > and the 4 MPIP ips to the default 0.0.0.0. Anything else I should check? > MPIP is only valid if you are going to connect a user to two different NETServers. In your case you do not need any MPIP set - Make sure that MPIP is set to 0.0.0.0 and the MPIP server is set off. > The client claims he can connect MPIP to another ISP's total control just > fine, but not mine. I've also been unsuccessful (same problem) with a > similar dialup configuration here that I set up for testing. In your case since you have only one NETServer what you need here is MLPPP. The statement above which says that your are dealing with one usr-tc box - basically says that you are not doing MPIP. What you need is to dial in and connect to two channels - The basic question is now how your NETServer is configured? Can you dial into the NETServer with a user configured on the NETServer ( not radius ) and connect two channels to the NETServer? krish \ T.S.V. Krishnan \ \ Network System Engineer \ ( : - : ) \ 3Com ............ \ ----------------------------------------------/ tkrishna@bubba.ae.usr.com ----------------------------/ http://interproc.ae.usr.com ----/ Any Sufficiently advanced bug is indistinguishable for a feature. - Rick Kulawiec > > - lv > >

On Tue, 2 Sep 1997, Phil Dye wrote: > Tatai SV Krishnan said; > > > >On Mon, 1 Sep 1997, Laszlo Vecsey wrote: > > > >> I'm getting the dreaded 'blue screen' problem, running the latest code on > >> the usr-tc and Win95 client. Port-Limit is set to two in merit radius, and > [snip] > >In your case since you have only one NETServer what you need here is > >MLPPP. The statement above which says that your are dealing with one > >usr-tc box - basically says that you are not doing MPIP. What you need > >is to dial in and connect to two channels - The basic question is now how > >your NETServer is configured? > > > >Can you dial into the NETServer with a user configured on the NETServer ( > >not radius ) and connect two channels to the NETServer? > > Having had a similar problem here, I've just (literally; the above > prompted me try something else) found out that a Port-Limit > in RADIUS seems to prevent MLPPP setting up correctly (both with a > Cisco 760 and a Motorola BitSurfr Pro). > > Adding a netuser directly onto the NetServer worked okay, so I then > removed the Port-Limit attribute from RADIUS (in my case inherited > from the pppuser in Merit) and now it all works. Add the Port-Limit back > in (in the specific user concerned in the users file) and it stops again. > > So it looks as though a RADIUS Port-Limit (set to either 1 or 2) stops MLPPP > from working. I'm not convinced that it ever stopped people logging in more > than once anyway (having seen people logged in twice on the same chassis > in the past)... Hmmm... Port limit does make user to connect to only the number of ports that he/she is specified for - If you say port limit is 1 then MLPPP will not work. The user will try to dial to the next channels and he will be trying but will not get a established session. In your case setting the port limit to 1 or more - does not seems to allow users to connect. The log file and the radius debug will tell you if you have an error in the user configuration. Please check it out. krish \ T.S.V. Krishnan \ \ Network System Engineer \ ( : - : ) \ 3Com ............ \ ----------------------------------------------/ tkrishna@bubba.ae.usr.com ----------------------------/ http://interproc.ae.usr.com ----/ Any Sufficiently advanced bug is indistinguishable for a feature. - Rick Kulawiec > > -- > Phil Dye | Work: pmd@tcp.net.uk > Network Manager | Play: phil@buggy.ing.co.uk > Total Connectivity Providers | Consider myself properly disclaimed > "Why is the load average on zeus 27.3 ?!?!" - john >

I called in the slow SLIP problem today and managed to get it pushed beyond the front line. I would presume that USR would have a battery of tests that would have caught this before the code went into release. Isn't SLIP included on that? I tested the problem this weekend, and the performance is HORRENDOUS. Like hit a key, get a response 30 seconds later.

Tatai SV Krishnan said; > >On Mon, 1 Sep 1997, Laszlo Vecsey wrote: > >> I'm getting the dreaded 'blue screen' problem, running the latest code on >> the usr-tc and Win95 client. Port-Limit is set to two in merit radius, and [snip] >In your case since you have only one NETServer what you need here is >MLPPP. The statement above which says that your are dealing with one >usr-tc box - basically says that you are not doing MPIP. What you need >is to dial in and connect to two channels - The basic question is now how >your NETServer is configured? > >Can you dial into the NETServer with a user configured on the NETServer ( >not radius ) and connect two channels to the NETServer? Having had a similar problem here, I've just (literally; the above prompted me try something else) found out that a Port-Limit in RADIUS seems to prevent MLPPP setting up correctly (both with a Cisco 760 and a Motorola BitSurfr Pro). Adding a netuser directly onto the NetServer worked okay, so I then removed the Port-Limit attribute from RADIUS (in my case inherited from the pppuser in Merit) and now it all works. Add the Port-Limit back in (in the specific user concerned in the users file) and it stops again. So it looks as though a RADIUS Port-Limit (set to either 1 or 2) stops MLPPP from working. I'm not convinced that it ever stopped people logging in more than once anyway (having seen people logged in twice on the same chassis in the past)... -- Phil Dye | Work: pmd@tcp.net.uk Network Manager | Play: phil@buggy.ing.co.uk Total Connectivity Providers | Consider myself properly disclaimed "Why is the load average on zeus 27.3 ?!?!" - john

Steph@emarkt.com said once upon a time: >No one seems to answer my mails, so shall I go to another mailing list? Generally, if nobody answers, nobody has a solution. >Does anyone know of any that discuss telecoms in general? comp.dcom.*?

Hello everyone, I am trying to setup a test environment using a usr total control unit and Livinsgton Radius running on a Linux box. Everything seems to work pretty well, except that when I dial-in, the user gets authenticated, I get a message that it's all connected, but after a second or so, the total control end drops the carrier and it disconnects the user! Anyone has any idea on what is causing this?? regards, Virgil Vaduva - Support Engineer The Allegro Group, Inc. (937) 264-7000 ext. 227 virgil@allegro.net "I have never let my schooling interfere with my education.." - Mark Twain

Tatai SV Krishnan said; > >On Tue, 2 Sep 1997, Phil Dye wrote: >> So it looks as though a RADIUS Port-Limit (set to either 1 or 2) stops MLPPP >> from working. I'm not convinced that it ever stopped people logging in more >> than once anyway (having seen people logged in twice on the same chassis >> in the past)... > >Hmmm... Port limit does make user to connect to only the number of ports >that he/she is specified for - If you say port limit is 1 then MLPPP will >not work. The user will try to dial to the next channels and he will be >trying but will not get a established session. Understood; although I'm sure I've seen users logged into the same chassis more than once before (not MLPPP, just multiple logins with a dynamic address pool so each login gets a different address) - one to check later. >In your case setting the port limit to 1 or more - does not seems to >allow users to connect. The log file and the radius debug will tell you >if you have an error in the user configuration. Please check it out. Found it; unless you specify Service-Type again (I use the 'default' dumbuser and pppuser abilities of Merit) for the user concerned, RADIUS doesn't overlay all the attributes over the pppuser user. So I had this; pppuser Authentication-Type = None Service-Type = Framed, Framed-Protocol = PPP, Framed-IP-Netmask = 255.255.255.255, Framed-Routing = None, Port-Limit = 1 mlppp-user Encrypted-Password = "F8hsk.zugz4hc" Framed-IP-Address = 192.168.10.194, Port-Limit = 2 (merit just uses the Encrypted-Password and Framed-IP-Address, and silently ignors the Port-Limit (it already having been defined in pppuser) Whereas I needed to be more explicit for mlppp-user, by including Service-Type and *all* other attributes I wanted; mlppp-user Encrypted-Password = "F8hsk.zugz4hc" Framed-IP-Address = 192.168.10.194, Port-Limit = 2, Service-Type = Framed, Framed-Protocol = PPP, Framed-IP-Netmask = 255.255.255.255, Framed-Routing = None, -- Phil Dye | Work: pmd@tcp.net.uk Network Manager | Play: phil@buggy.ing.co.uk Total Connectivity Providers | Consider myself properly disclaimed "Why is the load average on zeus 27.3 ?!?!" - john

Here's my 'users' file. Check it against yours, I've had problems like this when I had incompatible info in there. DEFAULT Password = "UNIX" User-Service-Type = Framed-User, Framed-MTU = 1500, Framed-Protocol = PPP Tom On Tuesday, September 02, 1997 4:05 PM, Virgil Vaduva [SMTP:Virgil@allegro.net] wrote: > Hello everyone, > > I am trying to setup a test environment using a usr total control unit and Livinsgton Radius running on a Linux box. Everything seems to work pretty well, except that when I dial-in, the user gets authenticated, I get a message that it's all connected, but after a second or so, the total control end drops the carrier and it disconnects the user! Anyone has any idea on what is causing this?? > > regards, > > > Virgil Vaduva - Support Engineer > The Allegro Group, Inc. > (937) 264-7000 ext. 227 > virgil@allegro.net > > "I have never let my schooling interfere with my education.." > - Mark Twain > >

Virgil Vaduva <Virgil@allegro.net> writes: > I am trying to setup a test environment using a usr total control > unit and Livinsgton Radius running on a Linux box. Everything seems > to work pretty well, except that when I dial-in, the user gets > authenticated, I get a message that it's all connected, but after a > second or so, the total control end drops the carrier and it > disconnects the user! Anyone has any idea on what is causing this?? Are you syslogging to the Linux box and is there anything interesting in the log? One thing that I do know can cause behavior like this is if your authentication response indicates a Filter-Id that specifies a filter that is not present on the NETServer, it will disconnect the user shortly after authentication. This particular cause will also leave a useful message in the syslog though. Another possibility might be that however you are trying to configure the user session conflicts with how the user has themselves configured. For example, if the NETServer is trying to negotiate an address (either because you gave it a specific address in the response or you are letting it dynamically pick one), but the user is also specifically configured for an address, and they are different, the PPP negotiation will fail. -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | ANS Communications, Inc. \ Phone: (914) 789-5327 | / 100 Clearbrook Road, Elmsford, NY 10523 \ Fax: (914) 789-5310 \ \-----------------------------------------------------------------------/

Did you create your std.ppp.in and std.ppp.out filter's on the TC box? I just set up my first TC box 2 weeks ago and experienced the same thing until I telnet'ed into the box and did a add filter std.ppp.in and add filter std.ppp.out I believe this was necessitated from the entry's in your /etc/raddb/users file. I am sure someone on the list can correct me on the technicals of this. good luck! jarden@mail.delrio.com > Hello everyone, > > I am trying to setup a test environment using a usr total control unit and > Livinsgton Radius running on a Linux box. Everything seems to work pretty > well, except that when I dial-in, the user gets authenticated, I get a > message that it's all connected, but after a second or so, the total control > end drops the carrier and it disconnects the user! Anyone has any idea on > what is causing this?? > > regards, > > > Virgil Vaduva - Support Engineer > The Allegro Group, Inc. > (937) 264-7000 ext. 227 > virgil@allegro.net > > "I have never let my schooling interfere with my education.." > - Mark > Twain > >

On Tue, 2 Sep 1997, Virgil Vaduva wrote: > Hello everyone, > > I am trying to setup a test environment using a usr total control unit and Livinsgton Radius running on a Linux box. Everything seems to work pretty well, except that when I dial-in, the user gets authenticated, I get a message that it's all connected, but after a second or so, the total control end drops the carrier and it disconnects the user! Anyone has any idea on what is causing this?? > > regards, > > > Virgil Vaduva - Support Engineer > The Allegro Group, Inc. > (937) 264-7000 ext. 227 > virgil@allegro.net > > "I have never let my schooling interfere with my education.." > - Mark Twain > > If your radius user has a filter id setup then create a filter on the NETServer or remove the filter id statement from radius krish \ T.S.V. Krishnan \ \ Network System Engineer \ ( : - : ) \ 3Com ............ \ ----------------------------------------------/ tkrishna@bubba.ae.usr.com ----------------------------/ http://interproc.ae.usr.com ----/ Any Sufficiently advanced bug is indistinguishable for a feature. - Rick Kulawiec

John is right. This is the exact kind of behavior I was experiencing on a TC when Radius was trying to do a filter that I didn't have installed. John Arden said once upon a time: > >Did you create your std.ppp.in and std.ppp.out filter's on the TC box? >I just set up my first TC box 2 weeks ago and experienced the same thing >until I telnet'ed into the box and did a > >add filter std.ppp.in and >add filter std.ppp.out > > >I believe this was necessitated from the entry's in your /etc/raddb/users >file. I am sure someone on the list can correct me on the technicals of >this. >> I am trying to setup a test environment using a usr total control unit and >> Livinsgton Radius running on a Linux box. Everything seems to work pretty >> well, except that when I dial-in, the user gets authenticated, I get a >> message that it's all connected, but after a second or so, the total control >> end drops the carrier and it disconnects the user! Anyone has any idea on >> what is causing this??

I have the following USR Total Control parts left FOR SALE (1) Total Control Chassis with Hub Control Unit, Dual 45Watt power = Supplies USR Rack-Mount Fan Tray. Unit is in LIKE NEW Condition.... = $1100 (1) USR NetServer Card $3500 (48 Ports, includes NIC/NAC,Docs and = SW) (1) USR Dual T1/PRI Card $2500 (Includes NIC/NAC, and Docs) (12) USR Quad Digital Modems $500/ea (Includes Modem card and = Docs) Selling as Parts to try to make my monkey back. Will sell as one = unit for $11,000. Everything works, 90 day warranty, X2 code may or may not be = loaded on the modems (I dont know) -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

We have had the much chronicled ethernet lock-up when running the 3.5.34 code on several of our Netservers, and have decided to downgrade the code on cards exhibiting problems to the more stable 3.3.28. I did one card, but the card appears to be completely hosed after a successful SDL from TCM. The TCM display showed a question mark in the slot, and the SDL screen said the slot was empty. The card would not respond to an attempted telnet, so I thought the settings had been lost, but from the TCM display it looked like the card wasn't even recognized by the chassis. Reseating and powercycling did not help. I then cabled directly to the console port on the Netserver and did a PCSDL, which went through successfully but still the card was failing, I couldn't even get a prompt from the console port. It looks like the card is not completely initializing, the run/fail light keeps blinking and then going to red, it will only go to a solid green for a period of several seconds before beginning to blink again. This is a 16MB EPB Netserver PRI card that had been running fine before the upgrade. I now am not able to even do a PCSDL before the connection times out. I seem to remember this being discussed shortly after we found this list, but I have searched the archives and cannot find mention of it. Anyone have any ideas? I appreciate any insight. =============================== Casey Cook CyberGate Network Administrator caseyc@gate.net ===============================

Krish, Here's my SRO# 5779736002 and my call ref # is 7069308. I'm waiting for Troy from logistics to call me about getting my netserver's hot swapped to FC2 chips. I'm hoping USR is going to take care of me on this. I have service contracts on all 3 chassis and I have sent back quad modem cards several times. The last one took almost 3 weeks to get a replacement back to us!@#$% I didn't raise hell because I can afford to be down a quad modem card but I can't afford to be down a whole chassis. If there is anything you can do, let me know. Thanks, Tom On Wednesday, August 20, 1997 8:13 AM, Tatai SV Krishnan [SMTP:tkrishna@bubba.ae.usr.com] wrote: > > On Tue, 19 Aug 1997, Tom Bilan wrote: > > > Brian, > > > > I'm still having the same lockup problems and I DO have the FC3 chip. > > I finally went back to 3.3.x before the users started burning crosses in > > my front lawn. > > > > Do you know your case#? I would like to reference that in my "conversation" > > with the cannon fodder they call 1st level support. > > > > Thanks, > > Tom > > Tom, > > Open a call with support and email me the ticket number. > > krish

Krish, Here's my SRO# 5779736002 and my call ref # is 7069308. I'm waiting for Troy from logistics to call me about getting my netserver's hot swapped to FC2 chips. I'm hoping USR is going to take care of me on this. I have service contracts on all 3 chassis and I have sent back quad modem cards several times. The last one took almost 3 weeks to get a replacement back to us!@#$% I didn't raise hell because I can afford to be down a quad modem card but I can't afford to be down a whole chassis. If there is anything you can do, let me know. Thanks, Tom On Wednesday, August 20, 1997 8:13 AM, Tatai SV Krishnan [SMTP:tkrishna@bubba.ae.usr.com] wrote: > > On Tue, 19 Aug 1997, Tom Bilan wrote: > > > Brian, > > > > I'm still having the same lockup problems and I DO have the FC3 chip. > > I finally went back to 3.3.x before the users started burning crosses in > > my front lawn. > > > > Do you know your case#? I would like to reference that in my "conversation" > > with the cannon fodder they call 1st level support. > > > > Thanks, > > Tom > > Tom, > > Open a call with support and email me the ticket number. > > krish

Im wondering if anyone else had had this problem and found a solution to it. Last week I upgraded our TC enterprise hub with the lastest software versions form the totalservice.usr.com and appart from some minor technical problems the upgrade when well. Everything seemed to be working until this laborday weekend when for no apparent reason the netserver card stopped authenticating Radius users correctly. What it seems to me seems to be a timeout problem. Here is what is happening. 1. A user connects to the hub, and it asks for there username/password 2. It sends this information off to the Radius Server (USR's Solaris version) 3. Radius Server validates the user and gets that users profile. 4. Radius Server sends the profile to the hub. Between the Radius server getting the users profile and sending it back to the hub, the hub seems to give up on the radius server and asks the user for there login information again 5. Hub sends newly entered in login info back to the radius server 6. Radius server validates but doesnt get users profile. At this point, the process seems to loop #5 and #6 until the hub logs the user off for too many tries. Anyone have a clue as to whats happening or need further info to help me solve this problem I would be greatfull. /--------------------------- David Crabtree -------------------------------\ | Vice Pres/Sys Admin | Dialup 56K | Quake - [GI] Scream | | WSNetworxx Inc. | Dialup ISDN | http://www.wsnet.com/~quake | | 448 South Lawrence Street | Ded. ISDN/T1 |-------------------------------| | Montgomery, AL, 36104 | Web Hosting | SysAdmin - WebMaster/Designer | | http://www.wsnet.com | Web Design | Graphics - Programmer | \------- mailto:wolfcub@wsnet.com -- http://www.wsnet.com/~wolfcub --------/

Ok, not sure if this is a problem with the USR boxes or not, but I'll pass on my experience. I was logged in, from my house via ISDN, connection up 6days. I have 16 IP's routed to my house (/28). On one machine, I started Quake, and then on the other I tried to telnet. My telnet would freeze up. It was very strange, I could only have one machine doing something, the other would lock up. And it wasnt bandwidth either. Dropping the connection and dialing back in fixed the problem. Normally, I can run Quake and a telnet with no problem, I have 128k isdn with STAC compression. Brian /-------------------------- signal@shreve.net -----------------------------\ | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | | Systems Administrator | Perl, Linux | Web hosting, online stores, | | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | | 89 CRX, Akimoto intake, DC |-=*:Quake:*=-| http://www.shreve.net/ | | headers, Eurosport exhaust |LordSignal/SN| Quake server: 208.206.76.3 | \-------------------------- 318-222-2638 x109 -----------------------------/

We're trying to bring our first two PRI's up on our first USR chassis and can't get the thing to sync up. Bellsouth ran some tests on the T1's and said they look good from the CO to us, but our TC rack is transmitting junk. They kept saying I didn't have it set for ESF, but I do... I suspect I have a dead T1 NIC card, and USR has a replacement on the way; however I thought I'd throw it out on the list in case the replacement doesn't help... This is the newer enhanced bus chassis. Dual T1 PRI Application Card Revision 2.5.3 (Card Id: 27) Boot Code Linked Date : Mon Dec 04 17:41:48 1995 Operation Code Linked Date: Wed May 21 12:47:17 1997 The Alarm/Event Status screen shows about 5 frame slips a second. The smart jacks occasionally click and reset, generating a *ton* of other errors in the process. Relevant stuff from the Span Line 1 screen: 1 Framing Mode ESF 2 Line Coding B8ZS 3 Remotely Initiated Loopback Ignore 4 Jitter Attenuation Transmitter 5 Transmit Line Build Out 0.0 dB 6 Switch Type (Boot time) Config=DMS-100(NT)Act.=DMS-100(NT) 7 Idle Byte Sent to TELCO FE Hex Bad hardware is suspected because the "Power-up Self-test Status" screen on the console menu says three things fail self-test: RAM: PASSED Flash ROM: PASSED Non-maskable Interrupt: PASSED Watch Dog: PASSED Management Bus UART: PASSED User Interface UART: PASSED Time/space Switch: FAILED Framer 1: PASSED Framer 2: PASSED Line Interface Unit 1: FAILED Line Interface Unit 2: FAILED FLASH ROM 12V Test: PASSED HDLC Channel 1: PASSED HDLC Channel 2: PASSED I suspect bad hardware based on this. USR suspects the same thing, and has a new PRI card set on the way. Just wanted to see if anyone else had seen this, because if it isn't the PRI card at fault, I'm in trouble :) Thanks... -- Mike Andrews (MA12) network & systems guy, Digital Crescent, Frankfort KY -- mandrews@dcr.net -- mandrews@termfrost.org -- http://www.termfrost.org/ -- "Evil shall always prevail over good, because evil has better marketing..." -- Sick of junk e-mail? Visit http://www.cauce.org/ or http://spam.abuse.net/

Hi, everyone, I have 2 questions here and hope anyone with the knowledge can reply me. Thanks in advance. First question is if TC (with netserver version 3.49) is compatible with Livingston released RADIUS 2.01? Specificly, I need to know if TC will acknowledge and apply the following RADIUS 2.x user profile settings. 1. Filter-Id 2. Session-Timeout 3. Idle-Timeout 4. Port-Limit Second question is regarding MTU settings in netserver. I was reading the thread regarding MTU settings on this mailing list before, and realized that setting MTU settings doesn't always applied by TC depending on the condition. However, I am wondering if I set the MTU settings in netserver to 576 instead of 1500 (the default), will this be applied and if this is what you will recommanded to do? Thanks again. Andy Yu-Hun Liao Internet Team, System Admin AICOM Internet Services Corp. (http://www.aicom.com), a division of AIC Asia International Services Corp. Phone #: (604) 298-2881 Fax #: (604) 298-5813

On Wed, 3 Sep 1997, Brian wrote: > > Ok, not sure if this is a problem with the USR boxes or not, but I'll pass > on my experience. > > I was logged in, from my house via ISDN, connection up 6days. I have 16 > IP's routed to my house (/28). On one machine, I started Quake, and then > on the other I tried to telnet. My telnet would freeze up. It was very > strange, I could only have one machine doing something, the other would > lock up. And it wasnt bandwidth either. Dropping the connection and > dialing back in fixed the problem. > > Normally, I can run Quake and a telnet with no problem, I have 128k isdn > with STAC compression. > > Brian I use a similar solution with (/28). All my connections from my house go via the NETServer ( 3.5.34 code based non EPB ) I have several session up, Others in my house use the connection at the same time - I have also played quake at the same time without any problem. I have not seen this type of problem so far. krish \ T.S.V. Krishnan \ \ Network System Engineer \ ( : - : ) \ 3Com ............ \ ----------------------------------------------/ tkrishna@bubba.ae.usr.com ----------------------------/ http://interproc.ae.usr.com ----/ Any Sufficiently advanced bug is indistinguishable for a feature. - Rick Kulawiec > > > /-------------------------- signal@shreve.net -----------------------------\ > | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | > | Systems Administrator | Perl, Linux | Web hosting, online stores, | > | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | > | 89 CRX, Akimoto intake, DC |-=*:Quake:*=-| http://www.shreve.net/ | > | headers, Eurosport exhaust |LordSignal/SN| Quake server: 208.206.76.3 | > \-------------------------- 318-222-2638 x109 -----------------------------/ > > >

On Thu, 4 Sep 1997, Doug McClure wrote: > Has anyone used/seen/tested the next generation *"ComOS"* that will be in > the TC/Hyper systems of the near future? Any feedback? > > Doug > If you are talking about the HiPer Arc card ( the new generation RISC based card ) - it does not use ComOS. It is totally a different operating system. krish \ T.S.V. Krishnan \ \ Network System Engineer \ ( : - : ) \ 3Com ............ \ ----------------------------------------------/ tkrishna@bubba.ae.usr.com ----------------------------/ http://interproc.ae.usr.com ----/ Any Sufficiently advanced bug is indistinguishable for a feature. - Rick Kulawiec

Has anyone used/seen/tested the next generation *"ComOS"* that will be in the TC/Hyper systems of the near future? Any feedback? Doug

At 06:58 AM 9/4/97 -0500, you wrote: > >On Thu, 4 Sep 1997, Doug McClure wrote: > >> Has anyone used/seen/tested the next generation *"ComOS"* that will be in >> the TC/Hyper systems of the near future? Any feedback? >> >> Doug >> > >If you are talking about the HiPer Arc card ( the new generation RISC >based card ) - it does not use ComOS. It is totally a different >operating system. > I know that the LE ComOS must be out of ALL USR gear by the end of the year. What OS will be replacing that in the TC platform and the futre HiPer TC systems? I am looking for feedback about that new OS. Doug >krish >----------------------------------------- > \ T.S.V. Krishnan \ > \ Network System Engineer \ ( : - : ) > \ 3Com ............ \ > ----------------------------------------------/ >tkrishna@bubba.ae.usr.com >----------------------------/ http://interproc.ae.usr.com ----/ >-------------------------------------------------------------------------\ > Any Sufficiently advanced bug is indistinguishable for a feature. > - Rick Kulawiec >-------------------------------------------------------------------------/ > > >

Can I safely list more than one Framed-Route statement in a merit radius users entry? i.e., to route say a block of 16 IPs, plus a few more static IPs with /32 netmask. - lv

From: owner-usr-tc@xmission.com Date: 05 Sep 1997 01:29:30 -0600

Hello, Can anyone give me some tips on how to get dialup IPX to a USR TC hub working? The client is a windows 95 PC with Novell's client32. Is additional software necessary? thanks, mark Mark Miller Lead Network Analyst lumm@Lehigh.EDU 183 Computing Center, Bldg #8B lumm@spot.CC.Lehigh.EDU Lehigh University Bethlehem, PA 18015

Sorry if I got the quoting wrong.. On Tue, 2 Sep 1997, Phil Dye wrote: > Whereas I needed to be more explicit for mlppp-user, by including Service-Type > and *all* other attributes I wanted; > > mlppp-user Encrypted-Password = "F8hsk.zugz4hc" > Framed-IP-Address = 192.168.10.194, > Port-Limit = 2, > Service-Type = Framed, > Framed-Protocol = PPP, > Framed-IP-Netmask = 255.255.255.255, > Framed-Routing = None, > Tried this.. still no good! > Tatai SV Krishnan said; > > > Can you dial into the NETServer with a user configured on the NETServer > (not radius) and connect two channels to the NETServer? I tried this too.. same problem. Any netserver settings in particular that I should be checking, which might cause this 'blue screen' Win95 problem? It only occurs when the second modem dials up for connection. - lv

Will the TC support ISDN DOV on a CT1 like the livingston PM3 or the Bay? Thanks -Dan

On Fri, 5 Sep 1997, Laszlo Vecsey wrote: > Sorry if I got the quoting wrong.. > > On Tue, 2 Sep 1997, Phil Dye wrote: > > Whereas I needed to be more explicit for mlppp-user, by including Service-Type > > and *all* other attributes I wanted; > > > > mlppp-user Encrypted-Password = "F8hsk.zugz4hc" > > Framed-IP-Address = 192.168.10.194, > > Port-Limit = 2, > > Service-Type = Framed, > > Framed-Protocol = PPP, > > Framed-IP-Netmask = 255.255.255.255, > > Framed-Routing = None, > > > > Tried this.. still no good! > > > Tatai SV Krishnan said; > > > > > Can you dial into the NETServer with a user configured on the NETServer > > (not radius) and connect two channels to the NETServer? > > I tried this too.. same problem. Any netserver settings in particular that > I should be checking, which might cause this 'blue screen' Win95 problem? > It only occurs when the second modem dials up for connection. > > - lv > > The NETServer is not capable of causing a blue screen on the win 95. What is happening is that you are dialing into the NETServer and as soon as the PPP/SLIP connection is established some setting in your Win95 does not agree with the setup and you get a blue screen. Check you configuration on Win95 - Make sure you are setup properlly for network protocols etc. All that happens when you dial a NETServer or any other terminal router is that you a IP address and your modem/terminal adapter now acts as a network card. Due to some misconfiguration on the Win95 side when the PPP connection is started - there seems to be some misconfiguration which casues your blue screen. Check the win95 setup. Try using a different win95 - If all this fails send me the phone number to the NETServer. krish

To all, I have gone through the archives for info and still have these questions PPP negotiation Failure

SO you have problems with one chassis B in which users are droped after connecting. The users dial in and the handshake is fine and then they are dropped - Am I right? You do not see this problem in any other chassis. If this is true - then the question is are users that dial to chassis B able to dial to chassis A and connect properlly? The packet bus master/slave does not really matter. When the PRI card is present it becomes the master, if the PRI card is booted after the NETServer card the NETServer card will be the master. The NETServer or the PRI being the master does not cause any PPP problems. What is needed is to first find out if the users dialing to B are in fact able to connect properlly to A, C and D. See if the problem is ppp framing releated and or radius related. krish \ T.S.V. Krishnan \ \ Network System Engineer \ ( : - : ) \ 3Com ............ \ ----------------------------------------------/ tkrishna@bubba.ae.usr.com ----------------------------/ http://interproc.ae.usr.com ----/ Any Sufficiently advanced bug is indistinguishable for a feature. - Rick Kulawiec On Sat, 6 Sep 1997 eric@dol.net wrote: > To all, I have gone through the archives for info and still have these questions > > PPP negotiation Failure > ----------------------- > We have 4 tc x2 systems all fed with pris. we are experiencing random > disconnects with > x2 modems as well as non x2 modems. for the most part everything is working > fine > with the exception of chassis b which fails to get customers into ppp modem > when the chassis > get full. i am not sure if it is a funcion of the chassis being full or > something else but that > is when the problem is occuring. chassis a b and c are the new chassis with > chassis d being the > older chassis bundle that usr was offering. > > we had the netserver card replaced in the problem chassis (b) because it had > an 841f2 chip. > this was done at the suggestion of usr. we did that and have had nothing > but problems > with that chassis. it is at a remote site on an smds t1 circuit that is > validated on a > tx/radius server on a different network in another state. the customers are > getting > authenticated properly but fail to go into ppp mode. > > when i checked about the clock master i don't understand why it is not an > option that can be > turned on for this chassis since it is a newer chassis where as the older > bundle we bought > does in fact have this setting on as per the below table. I am not sure if > that has anything > to do with the problem. > > usr has tried to free up memory but of course that make no sense since it > has 16 meg of ram > on it and should not be a memory problem. > > location a b c d > ------------ ------- ------- ------- ------- > version 3.3.28 3.5.34 3.3.28 3.4.23 > ram meg 8 16 8 20 > rom meg 2 4 2 2 > hard ver 7 7 6 7 > packebus > clockmaster y n y y > > has anyone seen this behavior before and provide and insight? > > what is the policy of usr for software upgrdes. i have version 3.3.28 on > the original > chassis yet when they sent me the new card it had 3.5.34 on it. i do not > have that > version avaiable to me to reflash the card in case i need to. should they > give it to > me when i get a new card? > > Disconnects > ----------- > from those who have had modem problems and solved them, are there any standard > modem init strings and register setting that i should make on all my chassis > to enable > them to perform better and retain customer connections better? i have > changed the s10=14 > as per usr when i was getting a more frequest disconnect problem with x2 modems. > > x2 customer connections > ----------------------- > When customers with x2 modems are getting dropped during downloads and > during the > initial handshaking are there any register/modem init settings that the > customer > can make on their modems that will help maintain their connections? > > Thanks > Eric > > Delaware Online!.........The SMART Choice! With 56K X2 Modems > Phone : 302-762-0375 Fax: 302-762-3462 WWW: www.dol.net > Eight out of five people have a problem understanding statistics! > ****************Customer support is our bottom line!********************* > > >

And another....................."prysm.net" is our competition, who opted not to spend big $$$ for US Robotics equiptment, instead just used an annex and some modems. They are about 8 hops away from us. /-------------------------- signal@shreve.net -----------------------------\ | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | | Systems Administrator | Perl, Linux | Web hosting, online stores, | | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | | 89 CRX, Akimoto intake, DC |-=*:Quake:*=-| http://www.shreve.net/ | | headers, Eurosport exhaust |LordSignal/SN| Quake server: 208.206.76.3 | \-------------------------- 318-222-2638 x109 -----------------------------/ ---------- Forwarded message ---------- Hello! I have a question. Since yall upgraded your modem code and other things about 5 weeks ago i have not been able to play quake. My pings went from 180-300 to 1900-3000. I really enjoy the quake and having been playing it the first month you got it up. I have others who are having the same problem and would like to see it work again. Everything else works as normal such as web pages and all other internet applications. I ping the kali server at 120 and lower all the time. That is why i cant understand what has happened to the quake server. A buddy of mine has shreve net and cant play quake but he also has a prysm account and get better pings going through prysm than shreve net. Explain that one. Wierd. Please Help Thanks John Taylor

At 10:29 AM 9/6/97 -0500, you wrote: >SO you have problems with one chassis B in which users are droped after >connecting. The users dial in and the handshake is fine and then they >are dropped - Am I right? You do not see this problem in any other >chassis. they handshake fine, they get authenticated. they get the famous dialup networking cant't negotiate message. in my log on the radius tsx server it says failed to negotiate ppp there is another term server a pm2er with microcom modems that is down stream to that pop and goes through the same router. i am not experiencing problems in that pop during validation and ppp negotiation. So it does not seem to be a delay problem between the tc server and the radius server. Eric > >If this is true - then the question is are users that dial to chassis B >able to dial to chassis A and connect properlly? The packet bus >master/slave does not really matter. When the PRI card is present it >becomes the master, if the PRI card is booted after the NETServer card >the NETServer card will be the master. The NETServer or the PRI being >the master does not cause any PPP problems. What is needed is to first >find out if the users dialing to B are in fact able to connect properlly >to A, C and D. See if the problem is ppp framing releated and or radius >related. yes they are able to connect to the other boxes and connect successfully and get logged on with radius on other boxes. Thanks Eric > Delaware Online!.........The SMART Choice! With 56K X2 Modems Phone : 302-762-0375 Fax: 302-762-3462 WWW: www.dol.net Eight out of five people have a problem understanding statistics! ****************Customer support is our bottom line!*********************

On Sat, 6 Sep 1997 eric@dol.net wrote: > At 10:29 AM 9/6/97 -0500, you wrote: > >SO you have problems with one chassis B in which users are droped after > >connecting. The users dial in and the handshake is fine and then they > >are dropped - Am I right? You do not see this problem in any other > >chassis. > > they handshake fine, they get authenticated. > they get the famous dialup networking cant't negotiate message. > in my log on the radius tsx server it says failed to negotiate ppp > > there is another term server a pm2er with microcom modems that is down > stream to that pop and goes through the same router. i am not experiencing > problems in that pop during validation and ppp negotiation. So it does > not seem to be a delay problem between the tc server and the radius > server. > Eric > > > > > >If this is true - then the question is are users that dial to chassis B > >able to dial to chassis A and connect properlly? The packet bus > >master/slave does not really matter. When the PRI card is present it > >becomes the master, if the PRI card is booted after the NETServer card > >the NETServer card will be the master. The NETServer or the PRI being > >the master does not cause any PPP problems. What is needed is to first > >find out if the users dialing to B are in fact able to connect properlly > >to A, C and D. See if the problem is ppp framing releated and or radius > >related. > > yes they are able to connect to the other boxes and connect successfully > and get logged on with radius on other boxes. > Thanks > Eric > > > > Delaware Online!.........The SMART Choice! With 56K X2 Modems > Phone : 302-762-0375 Fax: 302-762-3462 WWW: www.dol.net > Eight out of five people have a problem understanding statistics! > ****************Customer support is our bottom line!********************* > > > Logon to the NETserver as !root and use the following command to set the NETServer in debug modem. set cons set debug 0x51 Logon as the user who fials, You will see hex values and some ppp information on the screen. Capture them and send them to me. krish

Has anyone else noticed that USR X2 modems with voice capability always connect and stay at v34 modulation? We have been tracking slower than average connect rates >42K and with the exception of robbits(yes) this is the most obvious factor. Trying to force a higher connect rate "AT U26" doesn't help. I've looked at the doc's trying to find a proper ini string to use and found none that made a difference. Also some of the clone modems like Logicode seem to report a higher connected rate than Maxtech's. We try to steer people towards USR but with all of the cheap 56Kflex many want a $99 modem. Just want to know if there are any good X2 clones out there. Mike Hamrich Technical Director DrFast.Net, Inc.

On Mon, 8 Sep 1997, Ricardo Rizzi wrote: > > The NetServer Card work with BootP? > How can I do to configure this in NetServer v.3.3.3 > > Thanks, BootP - Do you want the NETServer on rebooting get an IP address from a bootP server? - This we do not do. However if you are using clients which can dial in and then run bootp you will get the assigned address from the NETServer for the clients krish \ T.S.V. Krishnan \ \ Network System Engineer \ ( : - : ) \ 3Com ............ \ ----------------------------------------------/ tkrishna@bubba.ae.usr.com ----------------------------/ http://interproc.ae.usr.com ----/ Any Sufficiently advanced bug is indistinguishable for a feature. - Rick Kulawiec > > _________________________________________________________________________ > "Centertap, acelerando o tempo, diminuindo distancias" > _________________________________________________________________________ > Ricardo Rizzi e-mail: ricardo.rizzi@centertap.com.br > Departamento Tecnico web: http://www.centertap.com.br > Av. Francisco Matarazzo, 404 13 andar tel: (+55-11) 862-4323 > 05001-100 - Sao Paulo - SP - Brasil fax: (+55-11) 862-4313 > _________________________________________________________________________ > >

The NetServer Card work with BootP? How can I do to configure this in NetServer v.3.3.3 Thanks, _________________________________________________________________________ "Centertap, acelerando o tempo, diminuindo distancias" _________________________________________________________________________ Ricardo Rizzi e-mail: ricardo.rizzi@centertap.com.br Departamento Tecnico web: http://www.centertap.com.br Av. Francisco Matarazzo, 404 13 andar tel: (+55-11) 862-4323 05001-100 - Sao Paulo - SP - Brasil fax: (+55-11) 862-4313 _________________________________________________________________________

On Mon, 8 Sep 1997, Ricardo Rizzi wrote: > At 15:29 08/09/97 -0500, Krishnan wrote: > >On Mon, 8 Sep 1997, Ricardo Rizzi wrote: > > > >> > >> The NetServer Card work with BootP? > >> How can I do to configure this in NetServer v.3.3.3 > >> > >> Thanks, > > > >BootP - Do you want the NETServer on rebooting get an IP address from a > >bootP server? - This we do not do. > > > >However if you are using clients which can dial in and then run bootp you > >will get the assigned address from the NETServer for the clients > > Yes!!! In this case, how can I configure the NetServer v.3.3.3??? If you have users on the NETServer only then you have to set the user with an IP address set user bob addr <ip address> or you can setup assigned IP address set assigned < start of IP address for the pool > set user bob addr assigned --- If the user is radius user then the user should have IPaddress as 255.255.255.254 for assigned or give him a specific IP address krish > > > > >krish > > > >----------------------------------------- > > \ T.S.V. Krishnan \ > > \ Network System Engineer \ ( : - : ) > > \ 3Com ............ \ > > ----------------------------------------------/ > >tkrishna@bubba.ae.usr.com > >----------------------------/ http://interproc.ae.usr.com ----/ > >-------------------------------------------------------------------------\ > > Any Sufficiently advanced bug is indistinguishable for a feature. > > - Rick Kulawiec > >-------------------------------------------------------------------------/ > > > > > > > >> > >> _________________________________________________________________________ > >> "Centertap, acelerando o tempo, diminuindo distancias" > >> _________________________________________________________________________ > >> Ricardo Rizzi e-mail: ricardo.rizzi@centertap.com.br > >> Departamento Tecnico web: http://www.centertap.com.br > >> Av. Francisco Matarazzo, 404 13 andar tel: (+55-11) 862-4323 > >> 05001-100 - Sao Paulo - SP - Brasil fax: (+55-11) 862-4313 > >> _________________________________________________________________________ > >> > >> > > > > > > > _________________________________________________________________________ > "Centertap, acelerando o tempo, diminuindo distancias" > _________________________________________________________________________ > Ricardo Rizzi e-mail: ricardo.rizzi@centertap.com.br > Departamento Tecnico web: http://www.centertap.com.br > Av. Francisco Matarazzo, 404 13 andar tel: (+55-11) 862-4323 > 05001-100 - Sao Paulo - SP - Brasil fax: (+55-11) 862-4313 > _________________________________________________________________________ > >

At 15:29 08/09/97 -0500, Krishnan wrote: >On Mon, 8 Sep 1997, Ricardo Rizzi wrote: > >> >> The NetServer Card work with BootP? >> How can I do to configure this in NetServer v.3.3.3 >> >> Thanks, > >BootP - Do you want the NETServer on rebooting get an IP address from a >bootP server? - This we do not do. > >However if you are using clients which can dial in and then run bootp you >will get the assigned address from the NETServer for the clients Yes!!! In this case, how can I configure the NetServer v.3.3.3??? > >krish > >----------------------------------------- > \ T.S.V. Krishnan \ > \ Network System Engineer \ ( : - : ) > \ 3Com ............ \ > ----------------------------------------------/ >tkrishna@bubba.ae.usr.com >----------------------------/ http://interproc.ae.usr.com ----/ >-------------------------------------------------------------------------\ > Any Sufficiently advanced bug is indistinguishable for a feature. > - Rick Kulawiec >-------------------------------------------------------------------------/ > > > >> >> _________________________________________________________________________ >> "Centertap, acelerando o tempo, diminuindo distancias" >> _________________________________________________________________________ >> Ricardo Rizzi e-mail: ricardo.rizzi@centertap.com.br >> Departamento Tecnico web: http://www.centertap.com.br >> Av. Francisco Matarazzo, 404 13 andar tel: (+55-11) 862-4323 >> 05001-100 - Sao Paulo - SP - Brasil fax: (+55-11) 862-4313 >> _________________________________________________________________________ >> >> > > > _________________________________________________________________________ "Centertap, acelerando o tempo, diminuindo distancias" _________________________________________________________________________ Ricardo Rizzi e-mail: ricardo.rizzi@centertap.com.br Departamento Tecnico web: http://www.centertap.com.br Av. Francisco Matarazzo, 404 13 andar tel: (+55-11) 862-4323 05001-100 - Sao Paulo - SP - Brasil fax: (+55-11) 862-4313 _________________________________________________________________________

David Crabtree said once upon a time: > >I am wondering if someone who has done this before could help me out. > >I am trying to setup a users bitsurfr pro isa to dial into our TC at 128K >instead of 64K as he is currently getting. > >He has told his bitsurfr that he is trying to do a 2 channel >connect/PPP/PAP ie AT @B0=2 %A2=95 @M2=P but as yet we have had no luck. > >If someone could help I would be greatly thankful If you have one TC, then this is a lot simpler. Make sure your RADIUS entry for the subscriber has: Port-Limit = 2; Framed-Protocol = MPP, Service-Type = Framed, Then MPPP should work. If you have two or more chassis, this is the same entry you use, but you need to have MPIP functional.

I am wondering if someone who has done this before could help me out. I am trying to setup a users bitsurfr pro isa to dial into our TC at 128K instead of 64K as he is currently getting. He has told his bitsurfr that he is trying to do a 2 channel connect/PPP/PAP ie AT @B0=2 %A2=95 @M2=P but as yet we have had no luck. If someone could help I would be greatly thankful /--------------------------- David Crabtree -------------------------------\ | Vice Pres/Sys Admin | Dialup 56K | Quake - [GI] Scream | | WSNetworxx Inc. | Dialup ISDN | http://www.wsnet.com/~quake | | 448 South Lawrence Street | Ded. ISDN/T1 |-------------------------------| | Montgomery, AL, 36104 | Web Hosting | SysAdmin - WebMaster/Designer | | http://www.wsnet.com | Web Design | Graphics - Programmer | \------- mailto:wolfcub@wsnet.com -- http://www.wsnet.com/~wolfcub --------/

> If you have one TC, then this is a lot simpler. Make sure your RADIUS > entry for the subscriber has: > > Port-Limit = 2; > Framed-Protocol = MPP, > Service-Type = Framed, > > Then MPPP should work. If you have two or more chassis, this is the same > entry you use, but you need to have MPIP functional. Ok what if I am running USR's Security(Radius) Server that doesnt use the above setup? /--------------------------- David Crabtree -------------------------------\ | Vice Pres/Sys Admin | Dialup 56K | Quake - [GI] Scream | | WSNetworxx Inc. | Dialup ISDN | http://www.wsnet.com/~quake | | 448 South Lawrence Street | Ded. ISDN/T1 |-------------------------------| | Montgomery, AL, 36104 | Web Hosting | SysAdmin - WebMaster/Designer | | http://www.wsnet.com | Web Design | Graphics - Programmer | \------- mailto:wolfcub@wsnet.com -- http://www.wsnet.com/~wolfcub --------/

You missed the point. The Netserver card is a different card from the T1/PRI card. And the Netserver card can either be plain Jane netserver or Netserver PRI. > The only difference is software anyway -- you can flash a T1 card up to a > PRI one. We did have the PRI card, and it was faulty; the new one USR > sent us worked fine after flashing it up to PRI. > > -- > Mike Andrews (MA12) "Oh my god, they killed Kenny!" > mandrews@dcr.net -- mandrews@termfrost.org -- http://www.termfrost.org/ > Senior Systems & Network Administrator, Digital Crescent, Frankfort, KY > Providing x2 Internet Access in Franklin, Anderson, and Shelby Counties > > On Tue, 9 Sep 1997, Webmaster wrote: > > > Make sure you have a Netserver PRI card and not just a Netserver > > card. I was shipped a new rack with the wrong Netserver card which > > caused a delay of 2-3 weeks for me. > > > > > We're trying to bring our first two PRI's up on our first USR chassis and > > > can't get the thing to sync up. Bellsouth ran some tests on the T1's and > > > said they look good from the CO to us, but our TC rack is transmitting > > > junk. They kept saying I didn't have it set for ESF, but I do... > > > I suspect I have a dead T1 NIC card, and USR has a replacement on the way; > > > however I thought I'd throw it out on the list in case the replacement > > > doesn't help... > > Webmaster > > http://www.wingnet.net > > > > > WingNET System Administrator 423-559-LINK (v) 423-559-5444 (f)

Thus spake David Crabtree >I am wondering if someone who has done this before could help me out. >I am trying to setup a users bitsurfr pro isa to dial into our TC at 128K >instead of 64K as he is currently getting. >He has told his bitsurfr that he is trying to do a 2 channel >connect/PPP/PAP ie AT @B0=2 %A2=95 @M2=P but as yet we have had no luck. >If someone could help I would be greatly thankful Uhm...make sure he's dialing the number twice.....by that I mean, my dial string ends up being sent to the bitsurfer pro as: atdt 9920029&9920029 -- Jeff McAdams Email: jeffm@iglou.com Chief Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

G. Douglas Davidson said once upon a time: >PPP is fine, and telnet is fine. Rlogin is another story. When an >rlogin session is made to the default host, the connection is always >dropped under certain conditions. > > - When another telnet session from the default host is attempted > - Upon exiting the Pine news reader This sounds similar to my ZModem dropping via rlogin. David Bolen eventually tracked it down to a TCP problem in the Netserver code. It was reported and replicated at USR, but I don't know whatever happened with the issue. I just took the offending code out of rzsz and things were fine for me. I don't have the pine/telnet drop problem on Solaris.

We are in the process of setting up our first Total Control Hub and have run into a strange problem. We are using Livingston's Radius Server 2.01 with its menuing feature and doing our best to duplicate the login procedure for PPP and Login users accross the TC and our Livingstons. PPP is fine, and telnet is fine. Rlogin is another story. When an rlogin session is made to the default host, the connection is always dropped under certain conditions. - When another telnet session from the default host is attempted - Upon exiting the Pine news reader and there are probably others conditions as well. The reason code that shows up in the radius log is "Lost-Carrier". Also, I have been trying to get the USR Radius dictionary without success for about a week. I have had two people in tech support promise to email it to me and another that told me to call Livingston. I don't feel comfortable calling Livingston to ask them for USR's attribute definitions. I thought that USR would probably be a bit better able to do this. Hmmm. Of course I can't get it from the USR Web Site because I have not purchased their version of Radius. Amazing. Any assistance would be appreciated.

Oh, sorry, missed the word "netserver" in your message. Duh! We do have the Netserver PRI w/ the Munich ISDN daughtercard. It's the enhanced packet bus one... nervously running 3.5.34 on it and hoping our ethernet doesn't die like everyone else's. Thanks for those that responded; the problem was in fact a dud T1 card. We're up and running now. :) -- Mike Andrews (MA12) "With sufficient thrust, pigs fly just fine." mandrews@dcr.net -- mandrews@termfrost.org -- http://www.termfrost.org/ Senior Systems & Network Administrator, Digital Crescent, Frankfort, KY Providing x2 Internet Access in Franklin, Anderson, and Shelby Counties On Wed, 10 Sep 1997, System Administrator wrote: > You missed the point. The Netserver card is a different card from > the T1/PRI card. And the Netserver card can either be plain Jane > netserver or Netserver PRI. > > > The only difference is software anyway -- you can flash a T1 card up to a > > PRI one. We did have the PRI card, and it was faulty; the new one USR > > sent us worked fine after flashing it up to PRI. > > > > -- > > Mike Andrews (MA12) "Oh my god, they killed Kenny!" > > mandrews@dcr.net -- mandrews@termfrost.org -- http://www.termfrost.org/ > > Senior Systems & Network Administrator, Digital Crescent, Frankfort, KY > > Providing x2 Internet Access in Franklin, Anderson, and Shelby Counties > > > > On Tue, 9 Sep 1997, Webmaster wrote: > > > > > Make sure you have a Netserver PRI card and not just a Netserver > > > card. I was shipped a new rack with the wrong Netserver card which > > > caused a delay of 2-3 weeks for me. > > > > > > > We're trying to bring our first two PRI's up on our first USR chassis and > > > > can't get the thing to sync up. Bellsouth ran some tests on the T1's and > > > > said they look good from the CO to us, but our TC rack is transmitting > > > > junk. They kept saying I didn't have it set for ESF, but I do... > > > > I suspect I have a dead T1 NIC card, and USR has a replacement on the way; > > > > however I thought I'd throw it out on the list in case the replacement > > > > doesn't help... > > > Webmaster > > > http://www.wingnet.net > > > > > > > > > > WingNET System Administrator > 423-559-LINK (v) > 423-559-5444 (f) >

On Wed, 10 Sep 1997, Pete Ashdown wrote: > G. Douglas Davidson said once upon a time: > > >PPP is fine, and telnet is fine. Rlogin is another story. When an > >rlogin session is made to the default host, the connection is always > >dropped under certain conditions. > > > > - When another telnet session from the default host is attempted > > - Upon exiting the Pine news reader > > This sounds similar to my ZModem dropping via rlogin. David Bolen > eventually tracked it down to a TCP problem in the Netserver code. It was > reported and replicated at USR, but I don't know whatever happened with the > issue. I just took the offending code out of rzsz and things were fine for > me. I don't have the pine/telnet drop problem on Solaris. > This does sound familiar in that it appears to be some sequence of bytes that is actually causing the drop. After thinking about your reply, I thought I should add that the box I am "rlogining" to is running SGI's IRIX 5.3. I went ahead and tried a box running 6.2 with the same results. I should also mention that I don't have the Total Control box listed in the hosts.equiv file, prompting the SGI box to prompt for the password. Again, all of this works just find from the Livingstons. My radius file for the login looks like this: SHELL Service-Type = Login-User, Login-IP-Host = machine ip address, Login-Service = Rlogin Thanks!

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-215727185-873979618=:9012 Content-Type: TEXT/PLAIN; charset=US-ASCII Attached is the dictionary file - in Livingston fromat with USR attributes It is strange that you have problem with rlogin. How is the Radius user setup in Radius for rlogin? krish \ T.S.V. Krishnan \ \ Network System Engineer \ ( : - : ) \ 3Com ............ \ ----------------------------------------------/ tkrishna@bubba.ae.usr.com ----------------------------/ http://interproc.ae.usr.com ----/ Any Sufficiently advanced bug is indistinguishable for a feature. - Rick Kulawiec On Wed, 10 Sep 1997, G. Douglas Davidson wrote: > We are in the process of setting up our first Total Control Hub and have > run into a strange problem. We are using Livingston's Radius Server 2.01 > with its menuing feature and doing our best to duplicate the login > procedure for PPP and Login users accross the TC and our Livingstons. > > PPP is fine, and telnet is fine. Rlogin is another story. When an > rlogin session is made to the default host, the connection is always > dropped under certain conditions. > > - When another telnet session from the default host is attempted > - Upon exiting the Pine news reader > > and there are probably others conditions as well. The reason code that > shows up in the radius log is "Lost-Carrier". > > Also, I have been trying to get the USR Radius dictionary without success > for about a week. I have had two people in tech support promise to email > it to me and another that told me to call Livingston. I don't feel > comfortable calling Livingston to ask them for USR's attribute > definitions. I thought that USR would probably be a bit better able to > do this. Hmmm. Of course I can't get it from the USR Web Site because I > have not purchased their version of Radius. > > Amazing. > > Any assistance would be appreciated. > > ----- > G. Douglas Davidson | CityNet, Inc. > douglas@city-net.com | Pittsburgh, PA > > --416219727-215727185-873979618=:9012 Content-Type: TEXT/PLAIN; charset=US-ASCII; name=dictionary Content-Transfer-Encoding: BASE64 Content-ID: <Pine.LNX.3.91.970911070657.9012B@bubba.ae.usr.com> Content-Description: IyAgJFJldmlzaW9uOiAgIDEuMzggICQNCiMgICREYXRlOiAgIDI1IEp1biAx OTk3IDExOjM0OjIwICAkDQojDQojICAgICAgIFRoaXMgZmlsZSBjb250YWlu cyBkaWN0aW9uYXJ5IHRyYW5zbGF0aW9ucyBmb3IgcGFyc2luZw0KIyAgICAg ICByZXF1ZXN0cyBhbmQgZ2VuZXJhdGluZyByZXNwb25zZXMuICBBbGwgdHJh bnNhY3Rpb25zIGFyZQ0KIyAgICAgICBjb21wb3NlZCBvZiBBdHRyaWJ1dGUv VmFsdWUgUGFpcnMuICBUaGUgdmFsdWUgb2YgZWFjaCBhdHRyaWJ1dGUNCiMg ICAgICAgaXMgc3BlY2lmaWVkIGFzIG9uZSBvZiA0IGRhdGEgdHlwZXMuICBW YWxpZCBkYXRhIHR5cGVzIGFyZToNCiMNCiMgICAgICAgc3RyaW5nIC0gMC0y NTQgb2N0ZXRzDQojICAgICAgIGlwYWRkciAtIDQgb2N0ZXRzIGluIG5ldHdv cmsgYnl0ZSBvcmRlcg0KIyAgICAgICBpbnRlZ2VyIC0gMzIgYml0IHZhbHVl IGluIGJpZyBlbmRpYW4gb3JkZXIgKGhpZ2ggYnl0ZSBmaXJzdCkNCiMgICAg ICAgZGF0ZSAtIDMyIGJpdCB2YWx1ZSBpbiBiaWcgZW5kaWFuIG9yZGVyIC0g c2Vjb25kcyBzaW5jZQ0KIyAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIDAwOjAwOjAwIEdNVCwgIEphbi4gIDEsICAxOTcwDQojDQoj ICAgICAgIEVudW1lcmF0ZWQgdmFsdWVzIGFyZSBzdG9yZWQgaW4gdGhlIHVz ZXIgZmlsZSB3aXRoIGRpY3Rpb25hcnkNCiMgICAgICAgVkFMVUUgdHJhbnNs YXRpb25zIGZvciBlYXN5IGFkbWluaXN0cmF0aW9uLg0KIw0KIyAgICAgICBF eGFtcGxlOg0KIw0KIyAgICAgICBBVFRSSUJVVEUgICAgICAgICBWQUxVRQ0K IyAgICAgICAtLS0tLS0tLS0gICAgICAgICAtLS0tLQ0KIyAgICAgICBGcmFt ZWRfUHJvdG9jb2wgPSBQUFANCiMgICAgICAgNyAgICAgICAgICAgICAgID0g MSAgICAgKGludGVnZXIgZW5jb2RpbmcpDQojDQpBVFRSSUJVVEUgICAgICAg VXNlcl9OYW1lICAgICAgICAgICAgICAgMSAgICAgICBzdHJpbmcgICAgICAg ICAgVXNlcjolDQpBVFRSSUJVVEUgICAgICAgUGFzc3dvcmQgICAgICAgICAg ICAgICAgMiAgICAgICBzdHJpbmcgICAgICANCkFUVFJJQlVURSAgICAgICBD SEFQX1Bhc3N3b3JkICAgICAgICAgICAzICAgICAgIHN0cmluZw0KQVRUUklC VVRFICAgICAgIENsaWVudF9JZCAgICAgICAgICAgICAgIDQgICAgICAgaXBh ZGRyICAgICAgICAgIElQZG90DQpBVFRSSUJVVEUgICAgICAgQ2xpZW50X1Bv cnRfSWQgICAgICAgICAgNSAgICAgICBpbnRlZ2VyICAgICAgICAgUG9ydCMl DQpBVFRSSUJVVEUgICAgICAgVXNlcl9TZXJ2aWNlX1R5cGUgICAgICAgNiAg ICAgICBpbnRlZ2VyICAgICAgICAgVkFMVUUNCkFUVFJJQlVURSAgICAgICBG cmFtZWRfUHJvdG9jb2wgICAgICAgICA3ICAgICAgIGludGVnZXIgICAgICAg ICBWQUxVRQ0KQVRUUklCVVRFICAgICAgIEZyYW1lZF9BZGRyZXNzICAgICAg ICAgIDggICAgICAgaXBhZGRyDQpBVFRSSUJVVEUgICAgICAgRnJhbWVkX05l dG1hc2sgICAgICAgICAgOSAgICAgICBpcGFkZHINCkFUVFJJQlVURSAgICAg ICBGcmFtZWRfUm91dGluZyAgICAgICAgICAxMCAgICAgIGludGVnZXIgICAg ICAgICBWQUxVRQ0KQVRUUklCVVRFICAgICAgIEZyYW1lZF9GaWx0ZXJfSWQg ICAgICAgIDExICAgICAgc3RyaW5nDQpBVFRSSUJVVEUgICAgICAgRnJhbWVk X01UVSAgICAgICAgICAgICAgMTIgICAgICBpbnRlZ2VyDQpBVFRSSUJVVEUg ICAgICAgRnJhbWVkX0NvbXByZXNzaW9uICAgICAgMTMgICAgICBpbnRlZ2Vy ICAgICAgICAgVkFMVUUNCkFUVFJJQlVURSAgICAgICBMb2dpbl9Ib3N0ICAg ICAgICAgICAgICAxNCAgICAgIGlwYWRkcg0KQVRUUklCVVRFICAgICAgIExv Z2luX1NlcnZpY2UgICAgICAgICAgIDE1ICAgICAgaW50ZWdlciAgICAgICAg IFZBTFVFDQpBVFRSSUJVVEUgICAgICAgTG9naW5fVENQX1BvcnQgICAgICAg ICAgMTYgICAgICBpbnRlZ2VyDQojIFVzZWQgYnkgVVNSIE5NQyBDYXJkDQpB VFRSSUJVVEUgICAgICAgT2xkX1Bhc3N3b3JkICAgICAgICAgICAgMTcgICAg ICBzdHJpbmcNCkFUVFJJQlVURSAgICAgICBQb3J0X01lc3NhZ2UgICAgICAg ICAgICAxOCAgICAgIHN0cmluZw0KQVRUUklCVVRFICAgICAgIERpYWxiYWNr X05vICAgICAgICAgICAgIDE5ICAgICAgc3RyaW5nDQpBVFRSSUJVVEUgICAg ICAgRGlhbGJhY2tfTmFtZSAgICAgICAgICAgMjAgICAgICBzdHJpbmcNCkFU VFJJQlVURSAgICAgICBFeHBpcmF0aW9uICAgICAgICAgICAgICAyMSAgICAg IGRhdGUNCkFUVFJJQlVURSAgICAgICBGcmFtZWRfUm91dGUgICAgICAgICAg ICAyMiAgICAgIHN0cmluZw0KQVRUUklCVVRFICAgICAgIEZyYW1lZF9JUFhf TmV0d29yayAgICAgIDIzICAgICAgaXBhZGRyDQpBVFRSSUJVVEUgICAgICAg Q2hhbGxlbmdlX1N0YXRlICAgICAgICAgMjQgICAgICBzdHJpbmcNCkFUVFJJ QlVURSAgICAgICBDbGFzcyAgICAgICAgICAgICAgICAgICAyNSAgICAgIHN0 cmluZw0KQVRUUklCVVRFICAgICAgIFNlc3Npb25fVGltZW91dCAgICAgICAg IDI3ICAgICAgaW50ZWdlcg0KQVRUUklCVVRFICAgICAgIElkbGVfVGltZW91 dCAgICAgICAgICAgIDI4ICAgICAgaW50ZWdlcg0KQVRUUklCVVRFICAgICAg IFRlcm1pbmF0aW9uX0FjdGlvbiAgICAgIDI5ICAgICAgaW50ZWdlcg0KQVRU UklCVVRFICAgICAgIENhbGxlZF9TdGF0aW9uX0lkICAgICAgIDMwICAgICAg c3RyaW5nDQpBVFRSSUJVVEUgICAgICAgQ2FsbGluZ19TdGF0aW9uX0lkICAg ICAgMzEgICAgICBzdHJpbmcNCkFUVFJJQlVURSAgICAgICBOQVNfSWRlbnRp ZmllciAgICAgICAgICAzMiAgICAgIHN0cmluZw0KQVRUUklCVVRFICAgICAg IFByb3h5X1N0YXRlICAgICAgICAgICAgIDMzICAgICAgc3RyaW5nDQpBVFRS SUJVVEUgICAgICAgTG9naW5fTEFUX1NlcnZpY2UgICAgICAgMzQgICAgICBz dHJpbmcNCkFUVFJJQlVURSAgICAgICBMb2dpbl9MQVRfTm9kZSAgICAgICAg ICAzNSAgICAgIHN0cmluZw0KQVRUUklCVVRFICAgICAgIExvZ2luX0xBVF9H cm91cCAgICAgICAgIDM2ICAgICAgc3RyaW5nDQpBVFRSSUJVVEUgICAgICAg RnJhbWVkX0FwcGxlVGFsa19MaW5rICAgMzcgICAgICBpbnRlZ2VyDQpBVFRS SUJVVEUgICAgICAgRnJhbWVkX0FwcGxlVGFsa19OZXR3b3JrIDM4ICAgICBp bnRlZ2VyDQpBVFRSSUJVVEUgICAgICAgRnJhbWVkX0FwcGxlVGFsa19ab25l ICAgIDM5ICAgICBzdHJpbmcNCkFUVFJJQlVURSAgICAgICBBY2N0X1N0YXR1 c19UeXBlICAgICAgICA0MCAgICAgIGludGVnZXIgICAgICAgICBBY2N0LVN0 YXR1cy1UeXBlPSUNCkFUVFJJQlVURSAgICAgICBBY2N0X0RlbGF5X1RpbWUg ICAgICAgICA0MSAgICAgIGludGVnZXINCkFUVFJJQlVURSAgICAgICBBY2N0 X0lucHV0X09jdGV0cyAgICAgICA0MiAgICAgIGludGVnZXINCkFUVFJJQlVU RSAgICAgICBBY2N0X091dHB1dF9PY3RldHMgICAgICA0MyAgICAgIGludGVn ZXINCkFUVFJJQlVURSAgICAgICBBY2N0X1Nlc3Npb25fSWQgICAgICAgICA0 NCAgICAgIHN0cmluZw0KQVRUUklCVVRFICAgICAgIEFjY3RfQXV0aGVudGlj ICAgICAgICAgIDQ1ICAgICAgaW50ZWdlciAgICAgICAgIFZBTFVFDQpBVFRS SUJVVEUgICAgICAgQWNjdF9TZXNzaW9uX1RpbWUgICAgICAgNDYgICAgICBp bnRlZ2VyDQpBVFRSSUJVVEUgICAgICAgQWNjdF9JbnB1dF9QYWNrZXRzICAg ICAgNDcgICAgICBpbnRlZ2VyICAgICAgICAgVkFMVUUNCkFUVFJJQlVURSAg ICAgICBBY2N0X091dHB1dF9QYWNrZXRzICAgICA0OCAgICAgIGludGVnZXIg ICAgICAgICBWQUxVRQ0KQVRUUklCVVRFICAgICAgIEFjY3RfVGVybWluYXRl X0NhdXNlICAgIDQ5ICAgICAgaW50ZWdlciAgICAgICAgIFZBTFVFDQpBVFRS SUJVVEUgICAgICAgQWNjdF9NdWx0aV9TZXNzaW9uX0lEICAgNTAgICAgICBz dHJpbmcNCkFUVFJJQlVURSAgICAgICBBY2N0X0xpbmtfQ291bnQgICAgICAg ICA1MSAgICAgIGludGVnZXINCkFUVFJJQlVURSAgICAgICBDSEFQX0NoYWxs ZW5nZSAgICAgICAgICA2MCAgICAgIHN0cmluZw0KQVRUUklCVVRFICAgICAg IE5BU19Qb3J0X1R5cGUgICAgICAgICAgIDYxICAgICAgaW50ZWdlcgkgICAg VkFMVUUNCkFUVFJJQlVURSAgICAgICBQb3J0X0xpbWl0ICAgICAgICAgICAg ICA2MiAgICAgIGludGVnZXINCkFUVFJJQlVURSAgICAgICBMb2dpbl9MQVRf UG9ydCAgICAgICAgICA2MyAgICAgIHN0cmluZw0KIyBQcm9tcHQgdmFsdWUg c2hvdWxkIGJlIDEgZm9yIGVjaG8sIDAgZm9yIG5vIGVjaG8sIGRlZmF1bHQg MS4NCkFUVFJJQlVURSAgICAgICBQcm9tcHQgICAgICAgICAgICAgICAgICA2 NCAgICAgIGludGVnZXIgICAgICAgICBWQUxVRQ0KQVRUUklCVVRFICAgICAg IENvbm5lY3RfSW5mbyAgICAgICAgICAgIDY1ICAgICAgc3RyaW5nDQpBVFRS SUJVVEUgICAgICAgU2lnbmF0dXJlICAgICAgICAgICAgICAgNjYgICAgICBz dHJpbmcNCkFUVFJJQlVURSAgICAgICBFQVBfTWVzc2FnZSAgICAgICAgICAg ICA2NyAgICAgIHN0cmluZw0KQVRUUklCVVRFICAgICAgIENvbmZpZ3VyYXRp b25fVG9rZW4gICAgIDY4ICAgICAgc3RyaW5nDQpBVFRSSUJVVEUgICAgICAg UGFzc3dvcmRfUmV0cnkgICAgICAgICAgNjkgICAgICBpbnRlZ2VyDQpBVFRS SUJVVEUgICAgICAgQVJBUF9QYXNzd29yZCAgICAgICAgICAgNzAgICAgICBz dHJpbmcNCkFUVFJJQlVURSAgICAgICBBUkFQX0ZlYXR1cmUgICAgICAgICAg ICA3MSAgICAgIHN0cmluZw0KQVRUUklCVVRFICAgICAgIEFSQVBfWm9uZV9B Y2Nlc3MgICAgICAgIDcyICAgICAgc3RyaW5nICAgICAgICAgIFZBTFVFDQpB VFRSSUJVVEUgICAgICAgQVJBUF9TZWN1cml0eSAgICAgICAgICAgNzMgICAg ICBzdHJpbmcNCkFUVFJJQlVURSAgICAgICBBUkFQX1NlY3VyaXR5X0RhdGEg ICAgICA3NCAgICAgIHN0cmluZw0KQVRUUklCVVRFICAgICAgIE1vZGVtX2Vy cm9yX2NvbnRyb2wgICAgIDk5ICAgICAgaW50ZWdlcg0KQVRUUklCVVRFICAg ICAgIHVua25vd24gCSAgICAgICAxMDAgICAgICBpbnRlZ2VyDQoNCiMgVVNS IG9ubHkgYXR0cmlidXRlIF8gc2V0IGlmIGNsaWVudCBzaG91bGQgaGlkZSB0 aGUgdXNlciB0eXBlZCBpbiB0ZXh0DQpBVFRSSUJVVEUgICAgICAgQ2hhcl9O b2VjaG8gICAgICAgICAgICAyNTAgICAgICBpbnRlZ2VyDQoNClZBTFVFICAg IFRlcm1pbmF0aW9uX0FjdGlvbiAgICBEZWZhdWx0ICAgIDANClZBTFVFICAg IFRlcm1pbmF0aW9uX0FjdGlvbiAgICBSQURJVVNfUmVxdWVzdCAgICAxDQoN CiMNCiMgTk1DIEF0dHJpYnV0ZXMgdXNpbmcgVmVuZG9yX1NwZWNpZmljIA0K Iw0KDQpBVFRSSUJfTk1DICAgICAgTGFzdF9OdW1iZXJfRGlhbGVkX091dCAg ICAgICAgICAweDAwNjYgIHN0cmluZw0KQVRUUklCX05NQyAgICAgIExhc3Rf TnVtYmVyX0RpYWxlZF9Jbl9ETklTICAgICAgMHgwMEU4ICBzdHJpbmcNCkFU VFJJQl9OTUMgICAgICBMYXN0X0NhbGxlcnNfTnVtYmVyX0FOSSAgICAgICAg IDB4MDBFOSAgc3RyaW5nDQpBVFRSSUJfTk1DICAgICAgQ2hhbm5lbCAgICAg ICAgICAgICAgICAgICAgICAgICAweEJGMzggIGludGVnZXIgDQoNCkFUVFJJ Ql9OTUMgICAgICBFdmVudF9JZCAgICAgICAgICAgICAgICAgICAgICAgIDB4 QkZCRSAgaW50ZWdlciAgICAgICAgIFZBTFVFDQojICJFdmVudC1JZCIgbmVl ZGVkIGJ5IHRoZSB3aW5kb3dzIHZlcnNpb24gb2YgdGhlIGFjY291bnRpbmcg c2VydmVyDQoNCkFUVFJJQl9OTUMgICAgICBFdmVudF9EYXRlX1RpbWUgICAg ICAgICAgICAgICAgIDB4QkYyRiAgZGF0ZSAgICAgICAgICAgIERBVEUxDQpB VFRSSUJfTk1DICAgICAgQ2FsbF9TdGFydF9EYXRlX1RpbWUgICAgICAgICAg ICAweEJGRjcgIGRhdGUgICAgICAgICAgICBEQVRFMQ0KQVRUUklCX05NQyAg ICAgIENhbGxfRW5kX0RhdGVfVGltZSAgICAgICAgICAgICAgMHhCRkY2ICBk YXRlICAgICAgICAgICAgREFURTENCkFUVFJJQl9OTUMgICAgICBEZWZhdWx0 X0RURV9EYXRhX1JhdGUgICAgICAgICAgIDB4MDA1RSAgaW50ZWdlciAgICAg ICAgIFZBTFVFDQpBVFRSSUJfTk1DICAgICAgSW5pdGlhbF9SeF9MaW5rX0Rh dGFfUmF0ZSAgICAgICAweEJGMkQgIGludGVnZXIgICAgICAgICBWQUxVRQ0K QVRUUklCX05NQyAgICAgIEZpbmFsX1J4X0xpbmtfRGF0YV9SYXRlICAgICAg ICAgMHhCRjJDICBpbnRlZ2VyICAgICAgICAgVkFMVUUNCkFUVFJJQl9OTUMg ICAgICBJbml0aWFsX1R4X0xpbmtfRGF0YV9SYXRlICAgICAgIDB4MDA2QSAg aW50ZWdlciAgICAgICAgIFZBTFVFDQpBVFRSSUJfTk1DICAgICAgRmluYWxf VHhfTGlua19EYXRhX1JhdGUgICAgICAgICAweDAwNkIgIGludGVnZXIgICAg ICAgICBWQUxVRQ0KQVRUUklCX05NQyAgICAgIENoYXNzaXNfVGVtcGVyYXR1 cmUgICAgICAgICAgICAgMHhCRjMxICBpbnRlZ2VyICAgICAgICAgQ2hhc3Np cy1UZW1wZXJhdHVyZShDKT0lDQpBVFRSSUJfTk1DICAgICAgQ2hhc3Npc19U ZW1wX1RocmVzaG9sZCAgICAgICAgICAweEJFODQgIGludGVnZXIgICAgICAg ICBDaGFzc2lzLVRlbXAtVGhyZXNob2xkKEMpPSUNCkFUVFJJQl9OTUMgICAg ICBBY3R1YWxfVm9sdGFnZSAgICAgICAgICAgICAgICAgIDB4QkYzMiAgaW50 ZWdlciAgICAgICAgIEFjdHVhbC1Wb2x0YWdlKHYpPSUNCkFUVFJJQl9OTUMg ICAgICBFeHBlY3RlZF9Wb2x0YWdlICAgICAgICAgICAgICAgIDB4QkYzMyAg aW50ZWdlciAgICAgICAgIEV4cGVjdGVkLVZvbHRhZ2Uodik9JQ0KQVRUUklC X05NQyAgICAgIFBvd2VyX1N1cHBseV9OdW1iZXIgICAgICAgICAgICAgMHhC RjM0ICBpbnRlZ2VyICAgICAgICAgUG93ZXItU3VwcGx5LU5vPSUNCkFUVFJJ Ql9OTUMgICAgICBDYXJkX1R5cGUgICAgICAgICAgICAgICAgICAgICAgIDB4 QkU4NSAgaW50ZWdlciAgICAgICAgIFZBTFVFDQpBVFRSSUJfTk1DICAgICAg Q2hhc3Npc19TbG90ICAgICAgICAgICAgICAgICAgICAweEJGMzkgIGludGVn ZXIgICAgICAgICBTbG90LSUNCkFUVFJJQl9OTUMgICAgICBTeW5jX0FzeW5j X01vZGUgICAgICAgICAgICAgICAgIDB4MDA2NyAgaW50ZWdlciAgICAgICAg IFZBTFVFDQpBVFRSSUJfTk1DICAgICAgT3JpZ2luYXRlX0Fuc3dlcl9Nb2Rl ICAgICAgICAgICAweDAwNjggIGludGVnZXIgICAgICAgICBWQUxVRQ0KQVRU UklCX05NQyAgICAgIE1vZHVsYXRpb25fVHlwZSAgICAgICAgICAgICAgICAg MHgwMDZDICBpbnRlZ2VyICAgICAgICAgVkFMVUUNCkFUVFJJQl9OTUMgICAg ICBDb25uZWN0X1Rlcm1fUmVhc29uICAgICAgICAgICAgIDB4MDA5QiAgaW50 ZWdlciAgICAgICAgIFZBTFVFDQpBVFRSSUJfTk1DICAgICAgRmFpbHVyZV90 b19Db25uZWN0X1JlYXNvbiAgICAgICAweDAwNjkgIGludGVnZXIgICAgICAg ICBWQUxVRQ0KQVRUUklCX05NQyAgICAgIEVxdWFsaXphdGlvbl9UeXBlICAg ICAgICAgICAgICAgMHgwMDZGICBpbnRlZ2VyICAgICAgICAgVkFMVUUNCkFU VFJJQl9OTUMgICAgICBGYWxsYmFja19FbmFibGVkICAgICAgICAgICAgICAg IDB4MDA3MCAgaW50ZWdlciAgICAgICAgIFZBTFVFDQpBVFRSSUJfTk1DICAg ICAgQ29ubmVjdF9UaW1lX0xpbWl0ICAgICAgICAgICAgICAweEJGRTcgIGlu dGVnZXIgICAgICAgICBDb25uZWN0LVRpbWUtbGltaXQobWluKT0lDQpBVFRS SUJfTk1DICAgICAgTnVtYmVyX29mX1JpbmdzX0xpbWl0ICAgICAgICAgICAw eEJGRTYgIGludGVnZXINCkFUVFJJQl9OTUMgICAgICBEVEVfRGF0YV9JZGxl X1RpbW91dCAgICAgICAgICAgIDB4MDA0OCAgaW50ZWdlciAgICAgICAgIERU RS1EYXRhLUlkbGUtdGltZS1vdXQobWluKT0lDQpBVFRSSUJfTk1DICAgICAg Q2hhcmFjdGVyc19TZW50ICAgICAgICAgICAgICAgICAweDAwNzEgIGludGVn ZXINCkFUVFJJQl9OTUMgICAgICBDaGFyYWN0ZXJzX1JlY2VpdmVkICAgICAg ICAgICAgIDB4MDA3MiAgaW50ZWdlcg0KQVRUUklCX05NQyAgICAgIEJsb2Nr c19TZW50ICAgICAgICAgICAgICAgICAgICAgMHgwMDc1ICBpbnRlZ2VyDQpB VFRSSUJfTk1DICAgICAgQmxvY2tzX1JlY2VpdmVkICAgICAgICAgICAgICAg ICAweDAwNzYgIGludGVnZXINCkFUVFJJQl9OTUMgICAgICBCbG9ja3NfUmVz ZW50ICAgICAgICAgICAgICAgICAgIDB4MDA3NyAgaW50ZWdlcg0KQVRUUklC X05NQyAgICAgIFJldHJhaW5zX1JlcXVlc3RlZCAgICAgICAgICAgICAgMHgw MDc4ICBpbnRlZ2VyDQpBVFRSSUJfTk1DICAgICAgUmV0cmFpbnNfR3JhbnRl ZCAgICAgICAgICAgICAgICAweDAwNzkgIGludGVnZXINCkFUVFJJQl9OTUMg ICAgICBMaW5lX1JldmVyc2FscyAgICAgICAgICAgICAgICAgIDB4MDA3QSAg aW50ZWdlcg0KQVRUUklCX05NQyAgICAgIE51bWJlcl9PZl9DaGFyYWN0ZXJz X0xvc3QgICAgICAgMHgwMDdCICBpbnRlZ2VyDQpBVFRSSUJfTk1DICAgICAg TnVtYmVyX29mX0JsZXJzICAgICAgICAgICAgICAgICAweDAwN0QgIGludGVn ZXINCkFUVFJJQl9OTUMgICAgICBOdW1iZXJfb2ZfTGlua19UaW1lb3V0cyAg ICAgICAgIDB4MDA3RSAgaW50ZWdlcg0KQVRUUklCX05NQyAgICAgIE51bWJl cl9vZl9GYWxsYmFja3MgICAgICAgICAgICAgMHgwMDdGICBpbnRlZ2VyDQpB VFRSSUJfTk1DICAgICAgTnVtYmVyX29mX1Vwc2hpZnRzICAgICAgICAgICAg ICAweDAwODAgIGludGVnZXINCkFUVFJJQl9OTUMgICAgICBOdW1iZXJfb2Zf TGlua19OQUtzICAgICAgICAgICAgIDB4MDA4MSAgaW50ZWdlcg0KQVRUUklC X05NQyAgICAgIERUUl9GYWxzZV9UaW1lb3V0ICAgICAgICAgICAgICAgMHgw MEJFICBpbnRlZ2VyICAgICAgICAgRFRSLUZhbHNlX1RpbWVvdXQoc2VjKT0l DQpBVFRSSUJfTk1DICAgICAgRmFsbGJhY2tfTGltaXQgICAgICAgICAgICAg ICAgICAweDAwQkYgIGludGVnZXIgICAgICAgICBGYWxsQmFjay1MaW1pdD0l DQpBVFRSSUJfTk1DICAgICAgQmxvY2tfRXJyb3JfQ291bnRfTGltaXQgICAg ICAgICAweDAwQzAgIGludGVnZXIgICAgICAgICBCbG9jay1FcnJvci1Db3Vu dC1MaW1pdD0lDQpBVFRSSUJfTk1DICAgICAgRFRSX1RydWVfVGltZW91dCAg ICAgICAgICAgICAgICAweDAwREEgIGludGVnZXIgICAgICAgICBEVFItVHJ1 ZS1UaW1lb3V0KHNlYyk9JQ0KQVRUUklCX05NQyAgICAgIFNlY3VyaXR5X0xv Z2luX0xpbWl0ICAgICAgICAgICAgMHhCRURFICBpbnRlZ2VyICAgICAgICAg U2VjdXJpdHktTG9naW4tTGltaXQ9JQ0KQVRUUklCX05NQyAgICAgIFNlY3Vy aXR5X1Jlc3BfTGltaXQgICAgICAgICAgICAgMHhCRUZBICBpbnRlZ2VyICAg ICAgICAgU2VjdXJpdHktUmVzcG9uc2UtTGltaXQ9JQ0KQVRUUklCX05NQyAg ICAgIERURV9SaW5nX05vX0Fuc3dlcl9MaW1pdCAgICAgICAgMHhCRjE3ICBp bnRlZ2VyICAgICAgICAgRFRFLVJpbmctTm8tQW5zd2VyLUxpbWl0PSUNCkFU VFJJQl9OTUMgICAgICBCYWNrX0NoYW5uZWxfRGF0YV9SYXRlICAgICAgICAg IDB4MDA3QyAgaW50ZWdlciAgICAgICAgIFZBTFVFDQpBVFRSSUJfTk1DICAg ICAgU2ltcGxpZmllZF9NTlBfTGV2ZWxzICAgICAgICAgICAweDAwOTkgIGlu dGVnZXINCkFUVFJJQl9OTUMgICAgICBTaW1wbGlmaWVkX1Y0MmJpc19Vc2Fn ZSAgICAgICAgIDB4MDBDNyAgaW50ZWdlcg0KQVRUUklCX05NQyAgICAgIE1i aV9DdF9QUklfQ2FyZF9TbG90ICAgICAgICAgICAgMHgwMTg0ICBpbnRlZ2Vy DQpBVFRSSUJfTk1DICAgICAgTWJpX0N0X1RETV9UaW1lX1Nsb3QgICAgICAg ICAgICAweDAxODUgIGludGVnZXINCkFUVFJJQl9OTUMgICAgICBNYmlfQ3Rf UFJJX0NhcmRfU3Bhbl9MaW5lICAgICAgIDB4MDE4NiAgaW50ZWdlcg0KQVRU UklCX05NQyAgICAgIE1iaV9DdF9CQ2hhbm5lbF9Vc2VkICAgICAgICAgICAg MHgwMTg3ICBpbnRlZ2VyDQpBVFRSSUJfTk1DICAgICAgUGh5c2ljYWxfU3Rh dGUgICAgICAgICAgICAgICAgICAweEJFNzcgIGludGVnZXIgICAgICAgIFBo eXNpY2FsLVN0YXRlPSUNCkFUVFJJQl9OTUMgICAgICBQYWNrZXRfQnVzX1Nl c3Npb24gICAgICAgICAgICAgIDB4QkYxNCAgaW50ZWdlciAgICAgICAgUGFj a2V0LUJ1cy1TZXNzaW9uPSUNCg0KQVRUUklCX05NQyAgICAgIFNlcnZlcl9U aW1lICAgICAgICAgICAgICAgICAgICAgMHhGMDAwICBkYXRlICAgICAgICAg ICAgZGF0ZTUNCiMgIlNlcnZlci1UaW1lIiBpcyBuZWVkZWQgYnkgdGhlIHdp bmRvd3MgdmVyc2lvbiBvZiB0aGUgYWNjb3VudGluZyBzZXJ2ZXINCg0KIyAw eEJFNURfMHhCRTYzIHNlbnQgd2l0aCBFdmVudF9JZCA3OQ0KQVRUUklCX05N QyAgICAgIENoYW5uZWxfQ29ubmVjdGVkX1RvICAgICAgICAgICAgMHhCRTVE ICBpbnRlZ2VyDQpBVFRSSUJfTk1DICAgICAgU2xvdF9Db25uZWN0ZWRfVG8g ICAgICAgICAgICAgICAweEJFNUUgIGludGVnZXIgDQpBVFRSSUJfTk1DICAg ICAgRGV2aWNlX0Nvbm5lY3RlZF9UbyAgICAgICAgICAgICAweEJFNUYgIGlu dGVnZXINCkFUVFJJQl9OTUMgICAgICBORkFTX0lEICAgICAgICAgICAgICAg ICAgICAgICAgIDB4QkU2MCAgaW50ZWdlcg0KQVRUUklCX05NQyAgICAgIFE5 MzFfQ2FsbF9SZWZlcmVuY2VfVmFsdWUgICAgICAgMHhCRTYxICBpbnRlZ2Vy DQpBVFRSSUJfTk1DICAgICAgQ2FsbF9FdmVudF9Db2RlICAgICAgICAgICAg ICAgICAweEJFNjIgIGludGVnZXINCkFUVFJJQl9OTUMgICAgICBEUzAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIDB4QkU2MyAgaW50ZWdlcg0KIyBE UzBzIHNlbnQgd2l0aCBFdmVudF9JZCA3Nyw3OA0KQVRUUklCX05NQyAgICAg IERTMHMgICAgICAgICAgICAgICAgICAgICAgICAgICAgMHhCRTY0ICBzdHJp bmcNCiMgR2F0ZXdheV9JUF9BZGRyZXNzIHNlbnQgd2l0aCBFdmVudF9JZCA3 MSw3Mg0KQVRUUklCX05NQyAgICAgIEdhdGV3YXlfSVBfQWRkcmVzcyAgICAg ICAgICAgICAgMHhCRTY2ICBpcGFkZHINCg0KQVRUUklCX05NQyAgICAgIENh bGxfQXJyaXZhbF9pbl9HTVQgICAgICAgICAgICAgMHhCRTUyICBkYXRlDQpB VFRSSUJfTk1DICAgICAgQ2FsbF9Db25uZWN0X2luX0dNVCAgICAgICAgICAg ICAweEJFNTEgIGRhdGUNCkFUVFJJQl9OTUMgICAgICBDYWxsX1Rlcm1pbmF0 ZV9pbl9HTVQgICAgICAgICAgIDB4QkU1MCAgZGF0ZQ0KQVRUUklCX05NQyAg ICAgIElEUzBfQ2FsbF9UeXBlICAgICAgICAgICAgICAgICAgMHhCRTRGICBp bnRlZ2VyDQoNCg0KIw0KIyBUaGVzZSBhcmUgTmV0U2VydmVyIDMuWCBWU0Eg YXR0cmlidXRlcw0KIw0KQVRUUklCX05NQyAgICAgIFBXX1VTUl9JRmlsdGVy X0lQICAgICAgICAgICAgICAgMHg5MDAwICBzdHJpbmcNCkFUVFJJQl9OTUMg ICAgICBQV19VU1JfSUZpbHRlcl9JUFggICAgICAgICAgICAgIDB4OTAwMSAg c3RyaW5nDQpBVFRSSUJfTk1DICAgICAgUFdfVVNSX09GaWx0ZXJfSVAgICAg ICAgICAgICAgICAweDkwMDMgIHN0cmluZw0KQVRUUklCX05NQyAgICAgIFBX X1VTUl9PRmlsdGVyX0lQWCAgICAgICAgICAgICAgMHg5MDA0ICBzdHJpbmcN CkFUVFJJQl9OTUMgICAgICBQV19VU1JfT0ZpbHRlcl9TQVAgICAgICAgICAg ICAgIDB4OTAwNSAgc3RyaW5nDQpBVFRSSUJfTk1DICAgICAgUFdfVlBOX0lE ICAgICAgICAgICAgICAgICAgICAgICAweDkwMDYgIGludGVnZXINCkFUVFJJ Ql9OTUMgICAgICBQV19WUE5fTmFtZSAgICAgICAgICAgICAgICAgICAgIDB4 OTAwNyAgc3RyaW5nDQpBVFRSSUJfTk1DICAgICAgUFdfVlBOX05laWdoYm9y ICAgICAgICAgICAgICAgICAweDkwMDggIGlwYWRkcg0KQVRUUklCX05NQyAg ICAgIFBXX0ZyYW1lZF9Sb3V0aW5nX1YyICAgICAgICAgICAgMHg5MDA5ICBp bnRlZ2VyIFZBTFVFDQpBVFRSSUJfTk1DICAgICAgUFdfVlBOX0dhdGV3YXkg ICAgICAgICAgICAgICAgICAweDkwMGEgIHN0cmluZw0KQVRUUklCX05NQyAg ICAgIFBXX1R1bm5lbF9BdXRoZW50aWNhdGlvbiAgICAgICAgMHg5MDBiICBz dHJpbmcNCkFUVFJJQl9OTUMgICAgICBQV19JbmRleCAgICAgICAgICAgICAg ICAgICAgICAgIDB4OTAwYyAgaW50ZWdlcg0KQVRUUklCX05NQyAgICAgIFBX X0N1dG9mZiAgICAgICAgICAgICAgICAgICAgICAgMHg5MDBkICBzdHJpbmcN CkFUVFJJQl9OTUMgICAgICBQV19QYWNrZXQgICAgICAgICAgICAgICAgICAg ICAgIDB4OTAwZSAgc3RyaW5nDQpBVFRSSUJfTk1DICAgICAgUHJpbWFyeV9E TlNfU2VydmVyICAgICAgICAgICAgICAweDkwMGYgIGlwYWRkcg0KQVRUUklC X05NQyAgICAgIFNlY29uZGFyeV9ETlNfU2VydmVyICAgICAgICAgICAgMHg5 MDEwICBpcGFkZHINCkFUVFJJQl9OTUMgICAgICBQcmltYXJ5X05CTlNfU2Vy dmVyICAgICAgICAgICAgIDB4OTAxMSAgaXBhZGRyDQpBVFRSSUJfTk1DICAg ICAgU2Vjb25kYXJ5X05CTlNfU2VydmVyICAgICAgICAgICAweDkwMTIgIGlw YWRkcg0KQVRUUklCX05NQyAgICAgIFN5c2xvZ19UYXAgICAgICAgICAgICAg ICAgICAgICAgMHg5MDEzICBpbnRlZ2VyCVZBTFVFDQpBVFRSSUJfTk1DICAg ICAgTG9nX0ZpbHRlcl9QYWNrZXQgICAgICAgICAgICAgICAweDkwMTcgIGlu dGVnZXINCkFUVFJJQl9OTUMgICAgICBDaGFzc2lzX0NhbGxfU2xvdCAgICAg ICAgICAgICAgIDB4OTAxOSAgaW50ZWdlcg0KQVRUUklCX05NQyAgICAgIENo YXNzaXNfQ2FsbF9TcGFuICAgICAgICAgICAgICAgMHg5MDFBICBpbnRlZ2Vy DQpBVFRSSUJfTk1DICAgICAgQ2hhc3Npc19DYWxsX0NoYW5uZWwgICAgICAg ICAgICAweDkwMUIgIGludGVnZXINCkFUVFJJQl9OTUMgICAgICBLZXlwcmVz c19UaW1lb3V0ICAgICAgICAgICAgICAgIDB4OTAxQyAgaW50ZWdlcg0KQVRU UklCX05NQyAgICAgIFVuYXV0aGVudGljYXRlZF9UaW1lICAgICAgICAgICAg MHg5MDFEICBpbnRlZ2VyDQojIFVzZWQgYnkgRW5oYW5jZWQgUkFESVVTIG9u bHkgYW5kIG9ubHkgaW4gUGFja2V0IEF0dHJpYnV0ZQ0KQVRUUklCX05NQyAg ICAgIFZQTl9FbmNyeXB0b3IgICAgICAgICAgICAJCTB4OTAxRSAgc3RyaW5n DQojIFVzZWQgaW4gQWNjb3VudGluZyBQYWNrZXRzDQpBVFRSSUJfTk1DICAg ICAgVlBOX0dXX0xvY2F0aW9uX0lkICAgICAgICAgICAgCTB4OTAxRiAgc3Ry aW5nDQpBVFRSSUJfTk1DICAgICAgUmVfQ2hhcF9UaW1lb3V0ICAgICAgICAg ICAgCTB4OTAyMCAgaW50ZWdlcg0KQVRUUklCX05NQyAgICAgIENDUF9BbGdv cml0aG0gICAgICAgICAgICAgICAgICAgMHg5MDIxICBpbnRlZ2VyDQpBVFRS SUJfTk1DICAgICAgQ29ubmVjdC1SYXRlICAgICAgICAgICAgICAgICAgIDB4 OTAyMyAgaW50ZWdlcg0KDQpWQUxVRSAgIENDUF9BbGdvcml0aG0gICBOT05F ICAgICAgICAxDQpWQUxVRSAgIENDUF9BbGdvcml0aG0gICBTdGFjICAgICAg ICAyDQpWQUxVRSAgIENDUF9BbGdvcml0aG0gICBNUyAgICAgICAgICAzDQpW QUxVRSAgIENDUF9BbGdvcml0aG0gICBBbnkgICAgICAgICA0DQoNClZBTFVF ICAgQ29ubmVjdC1SYXRlICBOT05FICAgICAgICAgMCANClZBTFVFICAgQ29u bmVjdC1SYXRlICAzMDBfQlBTICAgICAgMSANClZBTFVFICAgQ29ubmVjdC1S YXRlICAxMjAwX0JQUyAgICAgIDIgDQpWQUxVRSAgIENvbm5lY3QtUmF0ZSAg MjQwMF9CUFMgICAgICAzIA0KVkFMVUUgICBDb25uZWN0LVJhdGUgIDQ4MDBf QlBTICAgICAgNCANClZBTFVFICAgQ29ubmVjdC1SYXRlICA3MjAwX0JQUyAg ICAgIDUgDQpWQUxVRSAgIENvbm5lY3QtUmF0ZSAgOTYwMF9CUFMgICAgICA2 IA0KVkFMVUUgICBDb25uZWN0LVJhdGUgIDEyMDAwX0JQUyAgICAgIDcgDQpW QUxVRSAgIENvbm5lY3QtUmF0ZSAgMTQ0MDBfQlBTICAgICAgOCANClZBTFVF ICAgQ29ubmVjdC1SYXRlICAxNjgwMF9CUFMgICAgICA5DQpWQUxVRSAgIENv bm5lY3QtUmF0ZSAgMTkyMDBfQlBTICAgICAxMCANClZBTFVFICAgQ29ubmVj dC1SYXRlICAyMTYwMF9CUFMgICAgIDExIA0KVkFMVUUgICBDb25uZWN0LVJh dGUgIDI4ODAwX0JQUyAgICAgMTIgDQpWQUxVRSAgIENvbm5lY3QtUmF0ZSAg Mzg0MDBfQlBTICAgICAxMyANClZBTFVFICAgQ29ubmVjdC1SYXRlICA1NzYw MF9CUFMgICAgIDE0IA0KVkFMVUUgICBDb25uZWN0LVJhdGUgIDQ0MDAwX0JQ UyAgICAgMjcgDQpWQUxVRSAgIENvbm5lY3QtUmF0ZSAgNDUzMzNfQlBTICAg ICAyOCANClZBTFVFICAgQ29ubmVjdC1SYXRlICA0NjY2Nl9CUFMgICAgIDI5 IA0KVkFMVUUgICBDb25uZWN0LVJhdGUgIDQ4MDAwX0JQUyAgICAgMzAgDQpW QUxVRSAgIENvbm5lY3QtUmF0ZSAgNDkzMzNfQlBTICAgICAzMSANClZBTFVF ICAgQ29ubmVjdC1SYXRlICA1MDY2Nl9CUFMgICAgIDMyIA0KVkFMVUUgICBD b25uZWN0LVJhdGUgIDUyMDAwX0JQUyAgICAgMzMgDQpWQUxVRSAgIENvbm5l Y3QtUmF0ZSAgNTMzMzNfQlBTICAgICAzNCANClZBTFVFICAgQ29ubmVjdC1S YXRlICA1NDY2Nl9CUFMgICAgIDM1IA0KVkFMVUUgICBDb25uZWN0LVJhdGUg IDU2MDAwX0JQUyAgICAgMzYgDQpWQUxVRSAgIENvbm5lY3QtUmF0ZSAgNTcz MzNfQlBTICAgICAzNyANClZBTFVFICAgQ29ubmVjdC1SYXRlICA2NDAwMF9C UFMgICAgIDM4IA0KVkFMVUUgICBDb25uZWN0LVJhdGUgIDI1MzMzX0JQUyAg ICAgMzkgDQpWQUxVRSAgIENvbm5lY3QtUmF0ZSAgMjY2NjZfQlBTICAgICAg NDANClZBTFVFICAgQ29ubmVjdC1SYXRlICAyODAwMF9CUFMgICAgICA0MSAN ClZBTFVFICAgQ29ubmVjdC1SYXRlICAxMTUyMDBfQlBTICAgICAxNSANClZB TFVFICAgQ29ubmVjdC1SYXRlICAyODgwMDBfQlBTICAgICAgMTYNClZBTFVF ICAgQ29ubmVjdC1SYXRlICA3NV8xMjAwX0JQUyAgICAxNyANClZBTFVFICAg Q29ubmVjdC1SYXRlICAxMjAwXzc1X0JQUyAgICAxOA0KVkFMVUUgICBDb25u ZWN0LVJhdGUgIDI0MDAwX0JQUyAgICAgIDE5DQpWQUxVRSAgIENvbm5lY3Qt UmF0ZSAgMjY0MDBfQlBTICAgICAgMjANClZBTFVFICAgQ29ubmVjdC1SYXRl ICAzMTIwMF9CUFMgICAgICAyMQ0KVkFMVUUgICBDb25uZWN0LVJhdGUgIDMz NjAwX0JQUyAgICAgIDIyDQpWQUxVRSAgIENvbm5lY3QtUmF0ZSAgMzMzMzNf QlBTICAgICAgMjMNClZBTFVFICAgQ29ubmVjdC1SYXRlICAzNzMzM19CUFMg ICAgICAyNA0KVkFMVUUgICBDb25uZWN0LVJhdGUgIDQxMzMzX0JQUyAgICAg IDI1DQpWQUxVRSAgIENvbm5lY3QtUmF0ZSAgNDI2NjZfQlBTICAgICAgMjYN ClZBTFVFICAgQ29ubmVjdC1SYXRlICAyOTMzM19CUFMgICAgICA0MiANClZB TFVFICAgQ29ubmVjdC1SYXRlICAzMDY2Nl9CUFMgICAgICA0Mw0KVkFMVUUg ICBDb25uZWN0LVJhdGUgIDMyMDAwX0JQUyAgICAgIDQ0IA0KVkFMVUUgICBD b25uZWN0LVJhdGUgIDM0NjY2X0JQUyAgICAgIDQ1IA0KVkFMVUUgICBDb25u ZWN0LVJhdGUgIDM2MDAwX0JQUyAgICAgIDQ2IA0KVkFMVUUgICBDb25uZWN0 LVJhdGUgIDM4NjY2X0JQUyAgICAgIDQ3IA0KVkFMVUUgICBDb25uZWN0LVJh dGUgIDQwMDAwX0JQUyAgICAgIDQ4IA0KVkFMVUUgICBDb25uZWN0LVJhdGUg IDU4NjY2X0JQUyAgICAgIDQ5IA0KVkFMVUUgICBDb25uZWN0LVJhdGUgIDYw MDAwX0JQUyAgICAgIDUwIA0KVkFMVUUgICBDb25uZWN0LVJhdGUgIDYxMzMz X0JQUyAgICAgIDUxIA0KVkFMVUUgICBDb25uZWN0LVJhdGUgIDYyNjY2X0JQ UyAgICAgIDUyIA0KDQojDQojIEhpUGVyIGF0dHJpYnV0ZXMNCiMgDQpBVFRS SUJfTk1DICAgICAgQmVhcmVyX0NhcGFiaWxpdGllcyAgICAgICAgICAgICAw eDk4MDAgIGludGVnZXINCkFUVFJJQl9OTUMgICAgICBTcGVlZF9PZl9Db25u ZWN0aW9uICAgICAgICAgICAgIDB4OTgwMSAgaW50ZWdlcg0KQVRUUklCX05N QyAgICAgIE1heF9DaGFubmVscyAgICAgICAgICAgICAgICAgICAgMHg5ODAy ICBpbnRlZ2VyDQpBVFRSSUJfTk1DICAgICAgQ2hhbm5lbF9FeHBhbnNpb24g ICAgICAgICAgICAgICAweDk4MDMgIGludGVnZXINCkFUVFJJQl9OTUMgICAg ICBDaGFubmVsX0RlY3JlbWVudCAgICAgICAgICAgICAgIDB4OTgwNCAgaW50 ZWdlcg0KQVRUUklCX05NQyAgICAgIEV4cGFuc2lvbl9BbGdvcml0aG0gICAg ICAgICAgICAgMHg5ODA1ICBpbnRlZ2VyDQpBVFRSSUJfTk1DICAgICAgQ29t cHJlc3Npb25fQWxnb3JpdGhtICAgICAgICAgICAweDk4MDYgIGludGVnZXIN CkFUVFJJQl9OTUMgICAgICBSZWNlaXZlX0FjY19NYXAgICAgICAgICAgICAg ICAgIDB4OTgwNyAgaW50ZWdlcg0KQVRUUklCX05NQyAgICAgIFRyYW5zbWl0 X0FjY19NYXAgICAgICAgICAgICAgICAgMHg5ODA4ICBpbnRlZ2VyDQpBVFRS SUJfTk1DICAgICAgQ29tcHJlc3Npb25fUmVzZXRfTW9kZSAgICAgICAgICAw eDk4MGEgIGludGVnZXINCkFUVFJJQl9OTUMgICAgICBNaW5fQ29tcHJlc3Np b25fU2l6ZSAgICAgICAgICAgIDB4OTgwYiAgaW50ZWdlcg0KQVRUUklCX05N QyAgICAgIElQICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgMHg5ODBj ICBpbnRlZ2VyDQpBVFRSSUJfTk1DICAgICAgSVBYICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAweDk4MGQgIGludGVnZXINCkFUVFJJQl9OTUMgICAg ICBGaWx0ZXJfWm9uZXMgICAgICAgICAgICAgICAgICAgIDB4OTgwZSAgaW50 ZWdlcg0KQVRUUklCX05NQyAgICAgIEFwcGxldGFsayAgICAgICAgICAgICAg ICAgICAgICAgMHg5ODBmICBpbnRlZ2VyDQpBVFRSSUJfTk1DICAgICAgQnJp ZGdpbmcgICAgICAgICAgICAgICAgICAgICAgICAweDk4MTAgIGludGVnZXIN CkFUVFJJQl9OTUMgICAgICBTcG9vZmluZyAgICAgICAgICAgICAgICAgICAg ICAgIDB4OTgxMSAgaW50ZWdlcg0KQVRUUklCX05NQyAgICAgIEhvc3RfVHlw ZSAgICAgICAgICAgICAgICAgICAgICAgMHg5ODEyICBpbnRlZ2VyDQpBVFRS SUJfTk1DICAgICAgU2VuZF9OYW1lICAgICAgICAgICAgICAgICAgICAgICAw eDk4MTMgIHN0cmluZw0KQVRUUklCX05NQyAgICAgIFNlbmRfUGFzc3dvcmQg ICAgICAgICAgICAgICAgICAgMHg5ODE0ICBzdHJpbmcNCkFUVFJJQl9OTUMg ICAgICBTdGFydF9UaW1lICAgICAgICAgICAgICAgICAgICAgIDB4OTgxNSAg aW50ZWdlcg0KQVRUUklCX05NQyAgICAgIEVuZF9UaW1lICAgICAgICAgICAg ICAgICAgICAgICAgMHg5ODE2ICBpbnRlZ2VyDQpBVFRSSUJfTk1DICAgICAg U2VuZF9TY3JpcHQxICAgICAgICAgICAgICAgICAgICAweDk4MTcgIHN0cmlu Zw0KQVRUUklCX05NQyAgICAgIFJlcGx5X1NjcmlwdDEgICAgICAgICAgICAg ICAgICAgMHg5ODE4ICBzdHJpbmcNCkFUVFJJQl9OTUMgICAgICBTZW5kX1Nj cmlwdDIgICAgICAgICAgICAgICAgICAgIDB4OTgxOSAgc3RyaW5nDQpBVFRS SUJfTk1DICAgICAgUmVwbHlfU2NyaXB0MiAgICAgICAgICAgICAgICAgICAw eDk4MWEgIHN0cmluZw0KQVRUUklCX05NQyAgICAgIFNlbmRfU2NyaXB0MyAg ICAgICAgICAgICAgICAgICAgMHg5ODFiICBzdHJpbmcNCkFUVFJJQl9OTUMg ICAgICBSZXBseV9TY3JpcHQzICAgICAgICAgICAgICAgICAgIDB4OTgxYyAg c3RyaW5nDQpBVFRSSUJfTk1DICAgICAgU2VuZF9TY3JpcHQ0ICAgICAgICAg ICAgICAgICAgICAweDk4MWQgIHN0cmluZw0KQVRUUklCX05NQyAgICAgIFJl cGx5X1NjcmlwdDQgICAgICAgICAgICAgICAgICAgMHg5ODFlICBzdHJpbmcN CkFUVFJJQl9OTUMgICAgICBTZW5kX1NjcmlwdDUgICAgICAgICAgICAgICAg ICAgIDB4OTgxZiAgc3RyaW5nDQpBVFRSSUJfTk1DICAgICAgUmVwbHlfU2Ny aXB0NSAgICAgICAgICAgICAgICAgICAweDk4MjAgIHN0cmluZw0KQVRUUklC X05NQyAgICAgIFNlbmRfU2NyaXB0NiAgICAgICAgICAgICAgICAgICAgMHg5 ODIxICBzdHJpbmcNCkFUVFJJQl9OTUMgICAgICBSZXBseV9TY3JpcHQ2ICAg ICAgICAgICAgICAgICAgIDB4OTgyMiAgc3RyaW5nDQpBVFRSSUJfTk1DICAg ICAgVGVybWluYWxfVHlwZSAgICAgICAgICAgICAgICAgICAweDk4MjMgIHN0 cmluZw0KQVRUUklCX05NQyAgICAgIEFwcGxldGFsa19OZXR3b3JrX1Jhbmdl ICAgICAgICAgMHg5ODI0ICBpbnRlZ2VyDQpBVFRSSUJfTk1DICAgICAgTG9j YWxfSVBfQWRkcmVzcyAgICAgICAgICAgICAgICAweDk4MjUgIHN0cmluZw0K QVRUUklCX05NQyAgICAgIFJvdXRpbmdfUHJvdG9jb2wgICAgICAgICAgICAg ICAgMHg5ODI2ICBpbnRlZ2VyDQpBVFRSSUJfTk1DICAgICAgTW9kZW1fR3Jv dXAgICAgICAgICAgICAgICAgICAgICAweDk4MjcgIGludGVnZXINCkFUVFJJ Ql9OTUMgICAgICBJUFhfUm91dGluZyAgICAgICAgICAgICAgICAgICAgIDB4 OTgyOCAgaW50ZWdlcg0KQVRUUklCX05NQyAgICAgIElQWF9XYW4gICAgICAg ICAgICAgICAgICAgICAgICAgMHg5ODI5ICBpbnRlZ2VyDQpBVFRSSUJfTk1D ICAgICAgSVBfUklQX1BvbGljaWVzICAgICAgICAgICAgICAgICAweDk4MmEg IGludGVnZXINCkFUVFJJQl9OTUMgICAgICBJUF9SSVBfU2ltcGxlX0F1dGhf UGFzc3dvcmQgICAgIDB4OTgyYiAgc3RyaW5nDQoNCiMNCiMgICAgICAgSW50 ZWdlciBUcmFuc2xhdGlvbnMNCiMNCg0KIyAgICAgICBVc2VyIFR5cGVzDQoN ClZBTFVFICAgVXNlcl9TZXJ2aWNlX1R5cGUgICAgICAgTG9naW5fVXNlciAg ICAgICAgICAgICAgMQ0KVkFMVUUgICBVc2VyX1NlcnZpY2VfVHlwZSAgICAg ICBGcmFtZWRfVXNlciAgICAgICAgICAgICAyDQpWQUxVRSAgIFVzZXJfU2Vy dmljZV9UeXBlICAgICAgIERpYWxiYWNrX0xvZ2luX1VzZXIgICAgIDMNClZB TFVFICAgVXNlcl9TZXJ2aWNlX1R5cGUgICAgICAgRGlhbGJhY2tfRnJhbWVk X1VzZXIgICAgNA0KVkFMVUUgICBVc2VyX1NlcnZpY2VfVHlwZSAgICAgICBP dXRib3VuZF9Vc2VyICAgICAgICAgICA1DQpWQUxVRSAgIFVzZXJfU2Vydmlj ZV9UeXBlICAgICAgIFNoZWxsX1VzZXIgICAgICAgICAgICAgIDYNClZBTFVF ICAgVXNlcl9TZXJ2aWNlX1R5cGUgICAgICAgTkFTX1Byb21wdCAgICAgICAg ICAgICAgNw0KVkFMVUUgICBVc2VyX1NlcnZpY2VfVHlwZSAgICAgICBBdXRo ZW50aWNhdGVfT25seSAgICAgICA4DQpWQUxVRSAgIFVzZXJfU2VydmljZV9U eXBlICAgICAgIENhbGxiYWNrX05BU19Qcm9tcHQgICAgIDkNCg0KDQojICAg ICAgIEZyYW1lZCBQcm90b2NvbHMNCg0KVkFMVUUgICBGcmFtZWRfUHJvdG9j b2wgICAgICAgICBQUFAgICAgICAgICAgICAgICAgICAgICAxDQpWQUxVRSAg IEZyYW1lZF9Qcm90b2NvbCAgICAgICAgIFNMSVAgICAgICAgICAgICAgICAg ICAgIDINClZBTFVFICAgRnJhbWVkX1Byb3RvY29sICAgICAgICAgQVJBUCAg ICAgICAgICAgICAgICAgICAgMw0KVkFMVUUgICBGcmFtZWRfUHJvdG9jb2wg ICAgICAgICBHYW5kYWxmX0xpbmsgICAgICAgICAgICA0DQpWQUxVRSAgIEZy YW1lZF9Qcm90b2NvbCAgICAgICAgIFh5bG9naWNzICAgICAgICAgICAgICAg IDUNClZBTFVFICAgRnJhbWVkX1Byb3RvY29sICAgICAgICAgUFBUUCAgICAg ICAgICAgICAgICAgICAgOQ0KDQojICAgICAgIEZyYW1lZCBSb3V0aW5nIFZh bHVlcw0KDQpWQUxVRSAgIEZyYW1lZF9Sb3V0aW5nICAgICAgICAgIE5vbmUg ICAgICAgICAgICAgICAgICAgIDANClZBTFVFICAgRnJhbWVkX1JvdXRpbmcg ICAgICAgICAgQnJvYWRjYXN0ICAgICAgICAgICAgICAgMQ0KVkFMVUUgICBG cmFtZWRfUm91dGluZyAgICAgICAgICBMaXN0ZW4gICAgICAgICAgICAgICAg ICAyDQpWQUxVRSAgIEZyYW1lZF9Sb3V0aW5nICAgICAgICAgIEJyb2FkY2Fz dF9MaXN0ZW4gICAgICAgIDMNCg0KIyAgICAgICBGcmFtZWQgQ29tcHJlc3Np b24gVHlwZXMNCg0KVkFMVUUgICBGcmFtZWRfQ29tcHJlc3Npb24gICAgICBO b25lICAgICAgICAgICAgICAgICAgICAwDQpWQUxVRSAgIEZyYW1lZF9Db21w cmVzc2lvbiAgICAgIFZhbl9KYWNvYnNlbl9UQ1BfSVAgICAgIDENClZBTFVF ICAgRnJhbWVkX0NvbXByZXNzaW9uICAgICAgSVBYX0hlYWRlciAgICAgICAg ICAgICAgMg0KDQojICAgICAgIExvZ2luIFNlcnZpY2VzDQoNClZBTFVFICAg TG9naW5fU2VydmljZSAgICAgICAgICAgVGVsbmV0ICAgICAgICAgICAgICAg ICAgMA0KVkFMVUUgICBMb2dpbl9TZXJ2aWNlICAgICAgICAgICBSbG9naW4g ICAgICAgICAgICAgICAgICAxDQpWQUxVRSAgIExvZ2luX1NlcnZpY2UgICAg ICAgICAgIFRDUF9DbGVhciAgICAgICAgICAgICAgIDINClZBTFVFICAgTG9n aW5fU2VydmljZSAgICAgICAgICAgUG9ydE1hc3RlciAgICAgICAgICAgICAg Mw0KVkFMVUUgICBMb2dpbl9TZXJ2aWNlICAgICAgICAgICBMQVQgICAgICAg ICAgICAgICAgICAgICA0DQoNCiMgICAgICAgU3RhdHVzIFR5cGVzDQoNClZB TFVFICAgQWNjdF9TdGF0dXNfVHlwZSAgICAgICAgU3RhcnQgICAgICAgICAg ICAgICAgICAgMQ0KVkFMVUUgICBBY2N0X1N0YXR1c19UeXBlICAgICAgICBT dG9wICAgICAgICAgICAgICAgICAgICAyDQpWQUxVRSAgIEFjY3RfU3RhdHVz X1R5cGUgICAgICAgIEFsaXZlICAgICAgICAgICAgICAgICAgIDMNCg0KIyAg ICAgICBBdXRoZW50aWNhdGlvbiBUeXBlcw0KDQpWQUxVRSAgIEFjY3RfQXV0 aGVudGljICAgICAgICAgIE5vbmUgICAgICAgICAgICAgICAgICAgIDANClZB TFVFICAgQWNjdF9BdXRoZW50aWMgICAgICAgICAgUkFESVVTICAgICAgICAg ICAgICAgICAgMQ0KVkFMVUUgICBBY2N0X0F1dGhlbnRpYyAgICAgICAgICBM b2NhbCAgICAgICAgICAgICAgICAgICAyDQoNCiMgICAgICAgIEFjY3RfVGVy bWluYXRlX0NhdXNlDQpWQUxVRSBBY2N0X1Rlcm1pbmF0ZV9DYXVzZSBBQ0NU X1RFUk1fVVNFUl9SRVFVRVNUICAgICAgIDENClZBTFVFIEFjY3RfVGVybWlu YXRlX0NhdXNlIEFDQ1RfVEVSTV9MT1NUX0NBUlJJRVIgICAgICAgMg0KVkFM VUUgQWNjdF9UZXJtaW5hdGVfQ2F1c2UgQUNDVF9URVJNX0xPU1RfU0VSVklD RSAgICAgICAzDQpWQUxVRSBBY2N0X1Rlcm1pbmF0ZV9DYXVzZSBBQ0NUX1RF Uk1fSURMRV9USU1FT1VUICAgICAgIDQNClZBTFVFIEFjY3RfVGVybWluYXRl X0NhdXNlIEFDQ1RfVEVSTV9TRVNTSU9OX1RJTUVPVVQgICAgNQ0KVkFMVUUg QWNjdF9UZXJtaW5hdGVfQ2F1c2UgQUNDVF9URVJNX0FETUlOX1JFU0VUICAg ICAgICA2DQpWQUxVRSBBY2N0X1Rlcm1pbmF0ZV9DYXVzZSBBQ0NUX1RFUk1f QURNSU5fUkVCT09UICAgICAgIDcNClZBTFVFIEFjY3RfVGVybWluYXRlX0Nh dXNlIEFDQ1RfVEVSTV9QT1JUX0VSUk9SICAgICAgICAgOA0KVkFMVUUgQWNj dF9UZXJtaW5hdGVfQ2F1c2UgQUNDVF9URVJNX05BU19FUlJPUiAgICAgICAg ICA5DQpWQUxVRSBBY2N0X1Rlcm1pbmF0ZV9DYXVzZSBBQ0NUX1RFUk1fTkFT X1JFUVVFU1QgICAgICAgIDEwDQpWQUxVRSBBY2N0X1Rlcm1pbmF0ZV9DYXVz ZSBBQ0NUX1RFUk1fTkFTX1JFQk9PVCAgICAgICAgIDExDQpWQUxVRSBBY2N0 X1Rlcm1pbmF0ZV9DYXVzZSBBQ0NUX1RFUk1fUE9SVF9VTk5FRURFRCAgICAg IDEyDQpWQUxVRSBBY2N0X1Rlcm1pbmF0ZV9DYXVzZSBBQ0NUX1RFUk1fUE9S VF9QUkVFTVBURUQgICAgIDEzDQpWQUxVRSBBY2N0X1Rlcm1pbmF0ZV9DYXVz ZSBBQ0NUX1RFUk1fUE9SVF9TVVNQRU5ERUQgICAgIDE0DQpWQUxVRSBBY2N0 X1Rlcm1pbmF0ZV9DYXVzZSBBQ0NUX1RFUk1fU0VSVklDRV9VTkFWQUlMICAg IDE1DQpWQUxVRSBBY2N0X1Rlcm1pbmF0ZV9DYXVzZSBBQ0NUX1RFUk1fQ0FM TEJBQ0sgICAgICAgICAgIDE2DQpWQUxVRSBBY2N0X1Rlcm1pbmF0ZV9DYXVz ZSBBQ0NUX1RFUk1fVVNFUl9FUlJPUiAgICAgICAgIDE3DQpWQUxVRSBBY2N0 X1Rlcm1pbmF0ZV9DYXVzZSBBQ0NUX1RFUk1fSE9TVF9SRVFVRVNUICAgICAg IDE4DQoNCiMgICAgICAgRXZlbnQgSW5kZW50aWZpZXJzDQoNClZBTFVFICAg RXZlbnRfSWQgICAgICAgIE1vZHVsZV9JbnNlcnRlZCAgICAgICAgICAgICAg ICAgNg0KVkFMVUUgICBFdmVudF9JZCAgICAgICAgTW9kdWxlX1JlbW92ZWQg ICAgICAgICAgICAgICAgICA3DQpWQUxVRSAgIEV2ZW50X0lkICAgICAgICBQ U1VfVm9sdGFnZV9BbGFybSAgICAgICAgICAgICAgIDgNClZBTFVFICAgRXZl bnRfSWQgICAgICAgIFBTVV9GYWlsZWQgICAgICAgICAgICAgICAgICAgICAg OQ0KVkFMVUUgICBFdmVudF9JZCAgICAgICAgSFVCX1RlbXBfT3V0X29mX1Jh bmdlICAgICAgICAgICAxMA0KVkFMVUUgICBFdmVudF9JZCAgICAgICAgRmFu X0ZhaWxlZCAgICAgICAgICAgICAgICAgICAgICAxMQ0KVkFMVUUgICBFdmVu dF9JZCAgICAgICAgV2F0Y2hkb2dfVGltZW91dCAgICAgICAgICAgICAgICAx Mg0KVkFMVUUgICBFdmVudF9JZCAgICAgICAgTWdtdF9CdXNfRmFpbHVyZSAg ICAgICAgICAgICAgICAxMw0KVkFMVUUgICBFdmVudF9JZCAgICAgICAgSW5f Q29ubmVjdGlvbl9Fc3QgICAgICAgICAgICAgICAxNA0KVkFMVUUgICBFdmVu dF9JZCAgICAgICAgT3V0X0Nvbm5lY3Rpb25fRXN0ICAgICAgICAgICAgICAx NQ0KVkFMVUUgICBFdmVudF9JZCAgICAgICAgSW5fQ29ubmVjdGlvbl9UZXJt ICAgICAgICAgICAgICAxNg0KVkFMVUUgICBFdmVudF9JZCAgICAgICAgT3V0 X0Nvbm5lY3Rpb25fVGVybSAgICAgICAgICAgICAxNw0KVkFMVUUgICBFdmVu dF9JZCAgICAgICAgQ29ubmVjdGlvbl9GYWlsZWQgICAgICAgICAgICAgICAx OA0KVkFMVUUgICBFdmVudF9JZCAgICAgICAgQ29ubmVjdGlvbl9UaW1lb3V0 ICAgICAgICAgICAgICAxOQ0KVkFMVUUgICBFdmVudF9JZCAgICAgICAgRFRF X1RyYW5zbWl0X0lkbGUgICAgICAgICAgICAgICAyMA0KVkFMVUUgICBFdmVu dF9JZCAgICAgICAgRFRSX1RydWUgICAgICAgICAgICAgICAgICAgICAgICAy MQ0KVkFMVUUgICBFdmVudF9JZCAgICAgICAgRFRSX0ZhbHNlICAgICAgICAg ICAgICAgICAgICAgICAyMg0KVkFMVUUgICBFdmVudF9JZCAgICAgICAgQmxv Y2tfRXJyb3JfYXRfVGhyZXNob2xkICAgICAgICAyMw0KVkFMVUUgICBFdmVu dF9JZCAgICAgICAgRmFsbGJhY2tzX2F0X1RocmVzaG9sZCAgICAgICAgICAy NA0KVkFMVUUgICBFdmVudF9JZCAgICAgICAgTm9fRGlhbF9Ub25lX0RldGVj dGVkICAgICAgICAgICAyNQ0KVkFMVUUgICBFdmVudF9JZCAgICAgICAgTm9f TG9vcF9DdXJyZW50X0RldGVjdGVkICAgICAgICAyNg0KVkFMVUUgICBFdmVu dF9JZCAgICAgICAgWWVsbG93X0FsYXJtICAgICAgICAgICAgICAgICAgICAy Nw0KVkFMVUUgICBFdmVudF9JZCAgICAgICAgUmVkX0FsYXJtICAgICAgICAg ICAgICAgICAgICAgICAyOA0KVkFMVUUgICBFdmVudF9JZCAgICAgICAgTG9z c19PZl9TaWduYWwgICAgICAgICAgICAgICAgICAyOQ0KVkFMVUUgICBFdmVu dF9JZCAgICAgICAgUmN2X0Fscm1fSW5kX1NpZ25hbCAgICAgICAgICAgICAz MA0KVkFMVUUgICBFdmVudF9JZCAgICAgICAgVGltaW5nX1NvdXJjZV9Td2l0 Y2ggICAgICAgICAgICAzMQ0KVkFMVUUgICBFdmVudF9JZCAgICAgICAgTW9k ZW1fUmVzZXRfYnlfRFRFICAgICAgICAgICAgICAzMg0KVkFMVUUgICBFdmVu dF9JZCAgICAgICAgTW9kZW1fUmluZ19Ob19BbnN3ZXIgICAgICAgICAgICAz Mw0KVkFMVUUgICBFdmVudF9JZCAgICAgICAgRFRFX1JpbmdfTm9fQW5zd2Vy ICAgICAgICAgICAgICAzNA0KVkFMVUUgICBFdmVudF9JZCAgICAgICAgUGt0 X0J1c19TZXNzaW9uX0FjdGl2ZSAgICAgICAgICAzNQ0KVkFMVUUgICBFdmVu dF9JZCAgICAgICAgUGt0X0J1c19TZXNzaW9uX0Nvbmdlc3Rpb24gICAgICAz Ng0KVkFMVUUgICBFdmVudF9JZCAgICAgICAgUGt0X0J1c19TZXNzaW9uX0xv c3QgICAgICAgICAgICAzNw0KVkFMVUUgICBFdmVudF9JZCAgICAgICAgUGt0 X0J1c19TZXNzaW9uX0luYWN0aXZlICAgICAgICAzOA0KVkFMVUUgICBFdmVu dF9JZCAgICAgICAgVXNlcl9JbnRlcmZhY2VfUmVzZXQgICAgICAgICAgICAz OQ0KVkFMVUUgICBFdmVudF9JZCAgICAgICAgR2F0ZXdheV9Qb3J0X091dF9v Zl9TZXJ2aWNlICAgICA0MA0KVkFMVUUgICBFdmVudF9JZCAgICAgICAgR2F0 ZXdheV9Qb3J0X0xpbmtfQWN0aXZlICAgICAgICA0MQ0KVkFMVUUgICBFdmVu dF9JZCAgICAgICAgRGlhbF9PdXRfTG9naW5fRmFpbHVyZSAgICAgICAgICA0 Mg0KVkFMVUUgICBFdmVudF9JZCAgICAgICAgRGlhbF9Jbl9Mb2dpbl9GYWls dXJlICAgICAgICAgICA0Mw0KVkFMVUUgICBFdmVudF9JZCAgICAgICAgRGlh bF9PdXRfUmVzdHJpY3RlZF9OdW1iZXIgICAgICA0NA0KVkFMVUUgICBFdmVu dF9JZCAgICAgICAgRGlhbF9CYWNrX1Jlc3RyaWN0ZWRfTnVtYmVyICAgICA0 NQ0KVkFMVUUgICBFdmVudF9JZCAgICAgICAgVXNlcl9CbGFja2xpc3RlZCAg ICAgICAgICAgICAgICA0Ng0KVkFMVUUgICBFdmVudF9JZCAgICAgICAgQXR0 ZW1wdGVkX0xvZ2luX0JsYWNrbGlzdGVkICAgICA0Nw0KVkFMVUUgICBFdmVu dF9JZCAgICAgICAgUmVzcG9uc2VfQXR0ZW1wdF9MaW1pdF9FeGNlZWRlZCA0 OA0KVkFMVUUgICBFdmVudF9JZCAgICAgICAgTG9naW5fQXR0ZW1wdF9MaW1p dF9FeGNlZWRlZCAgICA0OQ0KVkFMVUUgICBFdmVudF9JZCAgICAgICAgRGlh bF9PdXRfQ2FsbF9EdXJhdGlvbiAgICAgICAgICA1MA0KVkFMVUUgICBFdmVu dF9JZCAgICAgICAgRGlhbF9Jbl9DYWxsX0R1cmF0aW9uICAgICAgICAgICA1 MQ0KVkFMVUUgICBFdmVudF9JZCAgICAgICAgUGt0X0J1c19TZXNzaW9uX0Vy cl9TdGF0dXMgICAgICA1Mg0KVkFMVUUgICBFdmVudF9JZCAgICAgICAgTk1D X0F1dG9SZXNwbnNlX1RyYXAgICAgICAgICAgICA1Mw0KVkFMVUUgICBFdmVu dF9JZCAgICAgICAgQWNjdF9TZXJ2ZXJfQ29udGFjdF9Mb3NzICAgICAgICA1 NA0KVkFMVUUgICBFdmVudF9JZCAgICAgICAgWWVsbG93X0FsYXJtX0NsZWFy ICAgICAgICAgICAgICA1NQ0KVkFMVUUgICBFdmVudF9JZCAgICAgICAgUmVk X0FsYXJtX0NsZWFyICAgICAgICAgICAgICAgICA1Ng0KVkFMVUUgICBFdmVu dF9JZCAgICAgICAgTG9zc19PZl9TaWduYWxfQ2xlYXIgICAgICAgICAgICA1 Nw0KVkFMVUUgICBFdmVudF9JZCAgICAgICAgUmN2X0Fscm1fSW5kX1NpZ25h bF9DbGVhciAgICAgICA1OA0KVkFMVUUgICBFdmVudF9JZCAgICAgICAgSW5j b21pbmdfQ29ubmVjdGlvbl9Fc3RhYmxpc2hlZCA1OQ0KVkFMVUUgICBFdmVu dF9JZCAgICAgICAgT3V0Z29pbmdfQ29ubmVjdGlvbl9Fc3RhYmxpc2hlZCA2 MA0KVkFMVUUgICBFdmVudF9JZCAgICAgICAgSW5jb21pbmdfQ29ubmVjdGlv bl9UZXJtaW5hdGVkICA2MQ0KVkFMVUUgICBFdmVudF9JZCAgICAgICAgT3V0 Z29pbmdfQ29ubmVjdGlvbl9UZXJtaW5hdGVkICA2Mg0KVkFMVUUgICBFdmVu dF9JZCAgICAgICAgQ29ubmVjdGlvbl9BdHRlbXB0X0ZhaWx1cmUgICAgICA2 Mw0KVkFMVUUgICBFdmVudF9JZCAgICAgICAgQ29udGludW91c19DUkNfQWxh cm0gICAgICAgICAgICA2NA0KVkFMVUUgICBFdmVudF9JZCAgICAgICAgQ29u dGludW91c19DUkNfQWxhcm1fQ2xlYXIgICAgICA2NQ0KVkFMVUUgICBFdmVu dF9JZCAgICAgICAgUGh5c2ljYWxfU3RhdGVfQ2hhbmdlICAgICAgICAgICA2 Ng0KVkFMVUUgICBFdmVudF9JZCAgICAgICAgR2F0ZXdheV9OZXR3b3JrX0Zh aWxlZCAgICAgICAgICA3MQ0KVkFMVUUgICBFdmVudF9JZCAgICAgICAgR2F0 ZXdheV9OZXR3b3JrX1Jlc3RvcmVkICAgICAgICA3Mg0KVkFMVUUgICBFdmVu dF9JZCAgICAgICAgUGFja2V0X0J1c19DbG9ja19Mb3N0ICAgICAgICAgICA3 Mw0KVkFMVUUgICBFdmVudF9JZCAgICAgICAgUGFja2V0X0J1c19DbG9ja19S ZXN0b3JlZCAgICAgICA3NA0KVkFMVUUgICBFdmVudF9JZCAgICAgICAgRF9D aGFubmVsX0luX1NlcnZpY2UgICAgICAgICAgICA3NQ0KVkFMVUUgICBFdmVu dF9JZCAgICAgICAgRF9DaGFubmVsX091dF9vZl9TZXJ2aWNlICAgICAgICA3 Ng0KVkFMVUUgICBFdmVudF9JZCAgICAgICAgRFMwc19Jbl9TZXJ2aWNlICAg ICAgICAgICAgICAgICA3Nw0KVkFMVUUgICBFdmVudF9JZCAgICAgICAgRFMw c19PdXRfb2ZfU2VydmljZSAgICAgICAgICAgICA3OA0KVkFMVUUgICBFdmVu dF9JZCAgICAgICAgVDEvVDFQUkkvRTFQUklfQ2FsbF9FdmVudCAgICAgICA3 OQ0KVkFMVUUgICBFdmVudF9JZCAgICAgICAgUHN1X0luY29tcGF0aWJsZSAg ICAgICAgICAgICAgICA4MA0KVkFMVUUgICBFdmVudF9JZCAgICAgICAgVDEs VDEtRTEvUFJJLUNhbGwtQXJyaXZlLUV2ZW50ICA4MQ0KVkFMVUUgICBFdmVu dF9JZCAgICAgICAgVDEsVDEtRTEvUFJJLUNhbGwtQ29ubmVjdC1FdmVudCA4 Mg0KVkFMVUUgICBFdmVudF9JZCAgICAgICAgVDEsVDEtRTEvUFJJLUNhbGwt VGVybWluYS1FdmVudCA4Mw0KVkFMVUUgICBFdmVudF9JZCAgICAgICAgVDEs VDEtRTEvUFJJLUNhbGwtRmFpbGVkLUV2ZW50ICA4NA0KDQoNCg0KVkFMVUUg ICBDYXJkX1R5cGUgICAgICAgU2xvdEVtcHR5ICAgICAgICAgICAgICAgICAg ICAgICAxDQpWQUxVRSAgIENhcmRfVHlwZSAgICAgICBTbG90VW5rbm93biAg ICAgICAgICAgICAgICAgICAgIDINClZBTFVFICAgQ2FyZF9UeXBlICAgICAg IE5ldHdNZ3RDYXJkICAgICAgICAgICAgICAgICAgICAgMw0KVkFMVUUgICBD YXJkX1R5cGUgICAgICAgRHVhbFQxTkFDICAgICAgICAgICAgICAgICAgICAg ICA0DQpWQUxVRSAgIENhcmRfVHlwZSAgICAgICBEdWFsTW9kZW1OQUMgICAg ICAgICAgICAgICAgICAgIDUNClZBTFVFICAgQ2FyZF9UeXBlICAgICAgIFF1 YWRNb2RlbU5BQyAgICAgICAgICAgICAgICAgICAgNg0KVkFMVUUgICBDYXJk X1R5cGUgICAgICAgVHJHYXRld2F5TkFDICAgICAgICAgICAgICAgICAgICA3 DQpWQUxVRSAgIENhcmRfVHlwZSAgICAgICBYMjVHYXRld2F5TkFDICAgICAg ICAgICAgICAgICAgIDgNClZBTFVFICAgQ2FyZF9UeXBlICAgICAgIER1YWxW MzRNb2RlbU5BQyAgICAgICAgICAgICAgICAgOQ0KVkFMVUUgICBDYXJkX1R5 cGUgICAgICAgUXVhZFYzMkRpZ2l0YWxNb2RlbU5BQyAgICAgICAgICAxMA0K VkFMVUUgICBDYXJkX1R5cGUgICAgICAgUXVhZFYzMkFuYWxvZ01vZGVtTkFD ICAgICAgICAgICAxMQ0KVkFMVUUgICBDYXJkX1R5cGUgICAgICAgUXVhZFYz MkRpZ0FubE1vZGVtTkFDICAgICAgICAgICAxMg0KVkFMVUUgICBDYXJkX1R5 cGUgICAgICAgUXVhZFYzNERpZ01vZGVtTkFDICAgICAgICAgICAgICAxMw0K VkFMVUUgICBDYXJkX1R5cGUgICAgICAgUXVhZFYzNEFubE1vZGVtTkFDICAg ICAgICAgICAgICAxNA0KVkFMVUUgICBDYXJkX1R5cGUgICAgICAgUXVhZFYz NERpZ0FubE1vZGVtTkFDICAgICAgICAgICAxNQ0KVkFMVUUgICBDYXJkX1R5 cGUgICAgICAgU2luZ2xlVDFOQUMgICAgICAgICAgICAgICAgICAgICAxNg0K VkFMVUUgICBDYXJkX1R5cGUgICAgICAgRXRoZXJuZXRHYXRld2F5TkFDICAg ICAgICAgICAgICAxNw0KVkFMVUUgICBDYXJkX1R5cGUgICAgICAgQWNjZXNz U2VydmVyICAgICAgICAgICAgICAgICAgICAxOA0KVkFMVUUgICBDYXJkX1R5 cGUgICAgICAgNDg2VHJHYXRld2F5TkFDICAgICAgICAgICAgICAgICAxOQ0K VkFMVUUgICBDYXJkX1R5cGUgICAgICAgNDg2RXRoZXJuZXRHYXRld2F5TkFD ICAgICAgICAgICAyMA0KVkFMVUUgICBDYXJkX1R5cGUgICAgICAgRHVhbFJT MjMyTkFDICAgICAgICAgICAgICAgICAgICAyMg0KVkFMVUUgICBDYXJkX1R5 cGUgICAgICAgNDg2WDI1R2F0ZXdheU5BQyAgICAgICAgICAgICAgICAyMw0K VkFMVUUgICBDYXJkX1R5cGUgICAgICAgQXBwbGljYXRpb25TZXJ2ZXJOQUMg ICAgICAgICAgICAyNQ0KVkFMVUUgICBDYXJkX1R5cGUgICAgICAgSVNETkdh dGV3YXlOQUMgICAgICAgICAgICAgICAgICAyNg0KVkFMVUUgICBDYXJkX1R5 cGUgICAgICAgSVNETnByaVQxTkFDICAgICAgICAgICAgICAgICAgICAyNw0K VkFMVUUgICBDYXJkX1R5cGUgICAgICAgQ2xrZWROZXRNZ3RDYXJkICAgICAg ICAgICAgICAgICAyOA0KVkFMVUUgICBDYXJkX1R5cGUgICAgICAgTW9kZW1Q b29sTWFuYWdlbWVudE5BQyAgICAgICAgICAyOQ0KVkFMVUUgICBDYXJkX1R5 cGUgICAgICAgTW9kZW1Qb29sTmV0c2VydmVyTkFDICAgICAgICAgICAzMA0K VkFMVUUgICBDYXJkX1R5cGUgICAgICAgTW9kZW1Qb29sVjM0TW9kZW1OQUMg ICAgICAgICAgICAzMQ0KVkFMVUUgICBDYXJkX1R5cGUgICAgICAgTW9kZW1Q b29sSVNETk5BQyAgICAgICAgICAgICAgICAzMg0KVkFMVUUgICBDYXJkX1R5 cGUgICAgICAgTlRTZXJ2ZXJOQUMgICAgICAgICAgICAgICAgICAgICAzMw0K VkFMVUUgICBDYXJkX1R5cGUgICAgICAgUXVhZFYzNERpZ2l0YWxHMk5BQyAg ICAgICAgICAgICAzNA0KVkFMVUUgICBDYXJkX1R5cGUgICAgICAgUXVhZFYz NEFuYWxvZ0cyTkFDICAgICAgICAgICAgICAzNQ0KVkFMVUUgICBDYXJkX1R5 cGUgICAgICAgUXVhZFYzNERpZ0FubGdHMk5BQyAgICAgICAgICAgICAzNg0K VkFMVUUgICBDYXJkX1R5cGUgICAgICAgTkVUU2VydmVyRnJhbWVSZWxheU5B QyAgICAgICAgICAzNw0KVkFMVUUgICBDYXJkX1R5cGUgICAgICAgTkVUU2Vy dmVyVG9rZW5SaW5nTkFDICAgICAgICAgICAzOA0KVkFMVUUgICBDYXJkX1R5 cGUgICAgICAgWDI1MjRDaGFubmVsTkFDICAgICAgICAgICAgICAgICAzOQ0K VkFMVUUgICBDYXJkX1R5cGUgICAgICAgV2lyZWxlc3NHYXRld2F5TmFjICAg ICAgICAgICAgICA0Mg0KDQpWQUxVRSAgIENhcmRfVHlwZSAgICAgICBFbmhh bmNlZEFjY2Vzc1NlcnZlciAgICAgICAgICAgIDQ0DQpWQUxVRSAgIENhcmRf VHlwZSAgICAgICBFbmhhbmNlZElTRE5HYXRld2F5TkFDICAgICAgICAgIDQ1 DQoNClZBTFVFICAgQ2FyZF9UeXBlICAgICAgIER1YWxUMU5JQyAgICAgICAg ICAgICAgICAgICAgICAgMTAwMQ0KVkFMVUUgICBDYXJkX1R5cGUgICAgICAg RHVhbEFsb2dNZG1OSUMgICAgICAgICAgICAgICAgICAxMDAyDQpWQUxVRSAg IENhcmRfVHlwZSAgICAgICBRdWFkRGd0bE1kbU5JQyAgICAgICAgICAgICAg ICAgIDEwMDMNClZBTFVFICAgQ2FyZF9UeXBlICAgICAgIFF1YWRBbG9nRGd0 bE1kbU5JQyAgICAgICAgICAgICAgMTAwNA0KVkFMVUUgICBDYXJkX1R5cGUg ICAgICAgVG9rZW5SaW5nTklDICAgICAgICAgICAgICAgICAgICAxMDA1DQpW QUxVRSAgIENhcmRfVHlwZSAgICAgICBTaW5nbGVUMU5JQyAgICAgICAgICAg ICAgICAgICAgIDEwMDYNClZBTFVFICAgQ2FyZF9UeXBlICAgICAgIEV0aGVy bmV0TklDICAgICAgICAgICAgICAgICAgICAgMTAwNw0KVkFMVUUgICBDYXJk X1R5cGUgICAgICAgU2hvcnRIYXVsRHVhbFQxTklDICAgICAgICAgICAgICAx MDA4DQpWQUxVRSAgIENhcmRfVHlwZSAgICAgICBEdWFsQWxvZ01nZEludGxN ZG1OSUMgICAgICAgICAgIDEwMDkNClZBTFVFICAgQ2FyZF9UeXBlICAgICAg IFgyNU5JQyAgICAgICAgICAgICAgICAgICAgICAgICAgMTAxMA0KVkFMVUUg ICBDYXJkX1R5cGUgICAgICAgUXVhZEFsb2dOb25NZ2RNZG1OSUMgICAgICAg ICAgICAxMDExDQpWQUxVRSAgIENhcmRfVHlwZSAgICAgICBRdWFkQWxvZ01n ZEludGxNZG1OSUMgICAgICAgICAgIDEwMTINClZBTFVFICAgQ2FyZF9UeXBl ICAgICAgIFF1YWRBbG9nTm9uTWdkSW50bE1kbU5JQyAgICAgICAgMTAxMw0K VkFMVUUgICBDYXJkX1R5cGUgICAgICAgUXVhZExzZExpTWdkTWRtTklDICAg ICAgICAgICAgICAxMDE0DQpWQUxVRSAgIENhcmRfVHlwZSAgICAgICBRdWFk THNkTGlOb25NZ2RNZG1OSUMgICAgICAgICAgIDEwMTUNClZBTFVFICAgQ2Fy ZF9UeXBlICAgICAgIFF1YWRMc2RMaU1nZEludGxNZG1OSUMgICAgICAgICAg MTAxNg0KVkFMVUUgICBDYXJkX1R5cGUgICAgICAgUXVhZExzZExpTm9uTWdk SW50bE1kbU5JQyAgICAgICAxMDE3DQpWQUxVRSAgIENhcmRfVHlwZSAgICAg ICBIU0V0aGVybmV0V2l0aFYzNU5JQyAgICAgICAgICAgIDEwMTgNClZBTFVF ICAgQ2FyZF9UeXBlICAgICAgIEhTRXRoZXJuZXRXaXRob3V0VjM1TklDICAg ICAgICAgMTAxOQ0KVkFMVUUgICBDYXJkX1R5cGUgICAgICAgRHVhbEhpZ2hT cGVlZFYzNU5JQyAgICAgICAgICAgICAxMDIwDQpWQUxVRSAgIENhcmRfVHlw ZSAgICAgICBRdWFkVjM1UlMyMzJMb3dTcGVlZE5JQyAgICAgICAgIDEwMjEN ClZBTFVFICAgQ2FyZF9UeXBlICAgICAgIER1YWxFMU5JQyAgICAgICAgICAg ICAgICAgICAgICAgICAxMDIyDQpWQUxVRSAgIENhcmRfVHlwZSAgICAgICBT aG9ydEhhdWxEdWFsRTFOSUMgICAgICAgICAgICAgICAgIDEwMjMNClZBTFVF ICAgQ2FyZF9UeXBlICAgICAgIEJlbGxjb3JlTG9uZ0hhdWxEdWFsVDFOSUMg ICAgICAgICAgMTAyNQ0KVkFMVUUgICBDYXJkX1R5cGUgICAgICAgQmVsbGNv cmVTaHJ0SGF1bER1YWxUMU5JQyAgICAgICAgICAxMDI2DQpWQUxVRSAgIENh cmRfVHlwZSAgICAgICBTQ1NJRWRnZVNlcnZlck5JQyAgICAgICAgICAgICAg ICAgIDEwMjcNCg0KDQpWQUxVRSAgICBEZWZhdWx0X0RURV9EYXRhX1JhdGUg ICAgICAgIDExMF9CUFMgICAgICAgICAxDQpWQUxVRSAgICBEZWZhdWx0X0RU RV9EYXRhX1JhdGUgICAgICAgIDMwMF9CUFMgICAgICAgICAyDQpWQUxVRSAg ICBEZWZhdWx0X0RURV9EYXRhX1JhdGUgICAgICAgIDYwMF9CUFMgICAgICAg ICAzDQpWQUxVRSAgICBEZWZhdWx0X0RURV9EYXRhX1JhdGUgICAgICAgIDEy MDBfQlBTICAgICAgICA0DQpWQUxVRSAgICBEZWZhdWx0X0RURV9EYXRhX1Jh dGUgICAgICAgIDI0MDBfQlBTICAgICAgICA1DQpWQUxVRSAgICBEZWZhdWx0 X0RURV9EYXRhX1JhdGUgICAgICAgIDQ4MDBfQlBTICAgICAgICA2DQpWQUxV RSAgICBEZWZhdWx0X0RURV9EYXRhX1JhdGUgICAgICAgIDcyMDBfQlBTICAg ICAgICA3DQpWQUxVRSAgICBEZWZhdWx0X0RURV9EYXRhX1JhdGUgICAgICAg IDk2MDBfQlBTICAgICAgICA4DQpWQUxVRSAgICBEZWZhdWx0X0RURV9EYXRh X1JhdGUgICAgICAgIDEyS19CUFMgICAgICAgICA5DQpWQUxVRSAgICBEZWZh dWx0X0RURV9EYXRhX1JhdGUgICAgICAgIDE0LjRLX0JQUyAgICAgICAxMA0K VkFMVUUgICAgRGVmYXVsdF9EVEVfRGF0YV9SYXRlICAgICAgICAxNi44X0JQ UyAgICAgICAgMTENClZBTFVFICAgIERlZmF1bHRfRFRFX0RhdGFfUmF0ZSAg ICAgICAgMTkuMktfQlBTICAgICAgIDEyDQpWQUxVRSAgICBEZWZhdWx0X0RU RV9EYXRhX1JhdGUgICAgICAgIDM4LjRLX0JQUyAgICAgICAxMw0KVkFMVUUg ICAgRGVmYXVsdF9EVEVfRGF0YV9SYXRlICAgICAgICA3NV9CUFMgICAgICAg ICAgMTQNClZBTFVFICAgIERlZmF1bHRfRFRFX0RhdGFfUmF0ZSAgICAgICAg NDUwX0JQUyAgICAgICAgIDE1DQpWQUxVRSAgICBEZWZhdWx0X0RURV9EYXRh X1JhdGUgICAgICAgIFVOS05PV05fQlBTICAgICAxNg0KVkFMVUUgICAgRGVm YXVsdF9EVEVfRGF0YV9SYXRlICAgICAgICA1Ny42S19CUFMgICAgICAgMTcN ClZBTFVFICAgIERlZmF1bHRfRFRFX0RhdGFfUmF0ZSAgICAgICAgMjEuNktf QlBTICAgICAgIDE4DQpWQUxVRSAgICBEZWZhdWx0X0RURV9EYXRhX1JhdGUg ICAgICAgIDI0S19CUFMgICAgICAgICAxOQ0KVkFMVUUgICAgRGVmYXVsdF9E VEVfRGF0YV9SYXRlICAgICAgICAyNktfQlBTICAgICAgICAgMjANClZBTFVF ICAgIERlZmF1bHRfRFRFX0RhdGFfUmF0ZSAgICAgICAgMjhLX0JQUyAgICAg ICAgIDIxDQpWQUxVRSAgICBEZWZhdWx0X0RURV9EYXRhX1JhdGUgICAgICAg IDExNUtfQlBTICAgICAgICAyMg0KDQpWQUxVRSAgIEluaXRpYWxfUnhfTGlu a19EYXRhX1JhdGUgICAgICAgMTEwX0JQUyAgICAgICAgIDENClZBTFVFICAg SW5pdGlhbF9SeF9MaW5rX0RhdGFfUmF0ZSAgICAgICAzMDBfQlBTICAgICAg ICAgMg0KVkFMVUUgICBJbml0aWFsX1J4X0xpbmtfRGF0YV9SYXRlICAgICAg IDYwMF9CUFMgICAgICAgICAzDQpWQUxVRSAgIEluaXRpYWxfUnhfTGlua19E YXRhX1JhdGUgICAgICAgMTIwMF9CUFMgICAgICAgIDQNClZBTFVFICAgSW5p dGlhbF9SeF9MaW5rX0RhdGFfUmF0ZSAgICAgICAyNDAwX1hCUFMgICAgICAg NQ0KVkFMVUUgICBJbml0aWFsX1J4X0xpbmtfRGF0YV9SYXRlICAgICAgIDQ4 MDBfQlBTICAgICAgICA2DQpWQUxVRSAgIEluaXRpYWxfUnhfTGlua19EYXRh X1JhdGUgICAgICAgNzIwMF9CUFMgICAgICAgIDcNClZBTFVFICAgSW5pdGlh bF9SeF9MaW5rX0RhdGFfUmF0ZSAgICAgICA5NjAwX0JQUyAgICAgICAgOA0K VkFMVUUgICBJbml0aWFsX1J4X0xpbmtfRGF0YV9SYXRlICAgICAgIDEyS19C UFMgICAgICAgICA5DQpWQUxVRSAgIEluaXRpYWxfUnhfTGlua19EYXRhX1Jh dGUgICAgICAgMTQuNEtfQlBTICAgICAgIDEwDQpWQUxVRSAgIEluaXRpYWxf UnhfTGlua19EYXRhX1JhdGUgICAgICAgMTYuOF9CUFMgICAgICAgIDExDQpW QUxVRSAgIEluaXRpYWxfUnhfTGlua19EYXRhX1JhdGUgICAgICAgMTkuMktf QlBTICAgICAgIDEyDQpWQUxVRSAgIEluaXRpYWxfUnhfTGlua19EYXRhX1Jh dGUgICAgICAgMzguNEtfQlBTICAgICAgIDEzDQpWQUxVRSAgIEluaXRpYWxf UnhfTGlua19EYXRhX1JhdGUgICAgICAgNzVfQlBTICAgICAgICAgIDE0DQpW QUxVRSAgIEluaXRpYWxfUnhfTGlua19EYXRhX1JhdGUgICAgICAgNDUwX0JQ UyAgICAgICAgIDE1DQpWQUxVRSAgIEluaXRpYWxfUnhfTGlua19EYXRhX1Jh dGUgICAgICAgVU5LTk9XTl9CUFMgICAgIDE2DQpWQUxVRSAgIEluaXRpYWxf UnhfTGlua19EYXRhX1JhdGUgICAgICAgNTcuNktfQlBTICAgICAgIDE3DQpW QUxVRSAgIEluaXRpYWxfUnhfTGlua19EYXRhX1JhdGUgICAgICAgMjEuNktf QlBTICAgICAgIDE4DQpWQUxVRSAgIEluaXRpYWxfUnhfTGlua19EYXRhX1Jh dGUgICAgICAgMjRLX0JQUyAgICAgICAgIDE5DQpWQUxVRSAgIEluaXRpYWxf UnhfTGlua19EYXRhX1JhdGUgICAgICAgMjZLX0JQUyAgICAgICAgIDIwDQpW QUxVRSAgIEluaXRpYWxfUnhfTGlua19EYXRhX1JhdGUgICAgICAgMjhLX0JQ UyAgICAgICAgIDIxDQpWQUxVRSAgICBJbml0aWFsX1J4X0xpbmtfRGF0YV9S YXRlICAgIDExNUtfQlBTICAgICAgICAyMg0KVkFMVUUgICBJbml0aWFsX1J4 X0xpbmtfRGF0YV9SYXRlICAgICAgIDMxS19CUFMgICAgICAgICAyMw0KVkFM VUUgICBJbml0aWFsX1J4X0xpbmtfRGF0YV9SYXRlICAgICAgIDMzS19CUFMg ICAgICAgICAyNA0KVkFMVUUgICBJbml0aWFsX1J4X0xpbmtfRGF0YV9SYXRl ICAgICAgIDI1MzMzX0JQUyAgICAgICAyNQ0KVkFMVUUgICBJbml0aWFsX1J4 X0xpbmtfRGF0YV9SYXRlICAgICAgIDI2NjY2X0JQUyAgICAgICAyNg0KVkFM VUUgICBJbml0aWFsX1J4X0xpbmtfRGF0YV9SYXRlICAgICAgIDI4MDAwX0JQ UyAgICAgICAyNw0KVkFMVUUgICBJbml0aWFsX1J4X0xpbmtfRGF0YV9SYXRl ICAgICAgIDI5MzMzX0JQUyAgICAgICAyOA0KVkFMVUUgICBJbml0aWFsX1J4 X0xpbmtfRGF0YV9SYXRlICAgICAgIDMwNjY2X0JQUyAgICAgICAyOQ0KVkFM VUUgICBJbml0aWFsX1J4X0xpbmtfRGF0YV9SYXRlICAgICAgIDMyMDAwX0JQ UyAgICAgICAzMA0KVkFMVUUgICBJbml0aWFsX1J4X0xpbmtfRGF0YV9SYXRl ICAgICAgIDMzMzMzX0JQUyAgICAgICAzMQ0KVkFMVUUgICBJbml0aWFsX1J4 X0xpbmtfRGF0YV9SYXRlICAgICAgIDM0NjY2X0JQUyAgICAgICAzMg0KVkFM VUUgICBJbml0aWFsX1J4X0xpbmtfRGF0YV9SYXRlICAgICAgIDM2MDAwX0JQ UyAgICAgICAzMw0KVkFMVUUgICBJbml0aWFsX1J4X0xpbmtfRGF0YV9SYXRl ICAgICAgIDM3MzMzX0JQUyAgICAgICAzNA0KVkFMVUUgICBJbml0aWFsX1J4 X0xpbmtfRGF0YV9SYXRlICAgICAgIDM4NjY2X0JQUyAgICAgICAzNQ0KVkFM VUUgICBJbml0aWFsX1J4X0xpbmtfRGF0YV9SYXRlICAgICAgIDQwMDAwX0JQ UyAgICAgICAzNg0KVkFMVUUgICBJbml0aWFsX1J4X0xpbmtfRGF0YV9SYXRl ICAgICAgIDQxMzMzX0JQUyAgICAgICAzNw0KVkFMVUUgICBJbml0aWFsX1J4 X0xpbmtfRGF0YV9SYXRlICAgICAgIDQyNjY2X0JQUyAgICAgICAzOA0KVkFM VUUgICBJbml0aWFsX1J4X0xpbmtfRGF0YV9SYXRlICAgICAgIDQ0MDAwX0JQ UyAgICAgICAzOQ0KVkFMVUUgICBJbml0aWFsX1J4X0xpbmtfRGF0YV9SYXRl ICAgICAgIDQ1MzMzX0JQUyAgICAgICA0MA0KVkFMVUUgICBJbml0aWFsX1J4 X0xpbmtfRGF0YV9SYXRlICAgICAgIDQ2NjY2X0JQUyAgICAgICA0MQ0KVkFM VUUgICBJbml0aWFsX1J4X0xpbmtfRGF0YV9SYXRlICAgICAgIDQ4MDAwX0JQ UyAgICAgICA0Mg0KVkFMVUUgICBJbml0aWFsX1J4X0xpbmtfRGF0YV9SYXRl ICAgICAgIDQ5MzMzX0JQUyAgICAgICA0Mw0KVkFMVUUgICBJbml0aWFsX1J4 X0xpbmtfRGF0YV9SYXRlICAgICAgIDUwNjY2X0JQUyAgICAgICA0NA0KVkFM VUUgICBJbml0aWFsX1J4X0xpbmtfRGF0YV9SYXRlICAgICAgIDUyMDAwX0JQ UyAgICAgICA0NQ0KVkFMVUUgICBJbml0aWFsX1J4X0xpbmtfRGF0YV9SYXRl ICAgICAgIDUzMzMzX0JQUyAgICAgICA0Ng0KVkFMVUUgICBJbml0aWFsX1J4 X0xpbmtfRGF0YV9SYXRlICAgICAgIDU0NjY2X0JQUyAgICAgICA0Nw0KVkFM VUUgICBJbml0aWFsX1J4X0xpbmtfRGF0YV9SYXRlICAgICAgIDU2MDAwX0JQ UyAgICAgICA0OA0KVkFMVUUgICBJbml0aWFsX1J4X0xpbmtfRGF0YV9SYXRl ICAgICAgIDU3MzMzX0JQUyAgICAgICA0OQ0KVkFMVUUgICBJbml0aWFsX1J4 X0xpbmtfRGF0YV9SYXRlICAgICAgIDU4NjY2X0JQUyAgICAgICA1MA0KVkFM VUUgICBJbml0aWFsX1J4X0xpbmtfRGF0YV9SYXRlICAgICAgIDYwMDAwX0JQ UyAgICAgICA1MQ0KVkFMVUUgICBJbml0aWFsX1J4X0xpbmtfRGF0YV9SYXRl ICAgICAgIDYxMzMzX0JQUyAgICAgICA1Mg0KVkFMVUUgICBJbml0aWFsX1J4 X0xpbmtfRGF0YV9SYXRlICAgICAgIDYyNjY2X0JQUyAgICAgICA1Mw0KVkFM VUUgICBJbml0aWFsX1J4X0xpbmtfRGF0YV9SYXRlICAgICAgIDY0MDAwX0JQ UyAgICAgICA1NA0KDQpWQUxVRSAgIEZpbmFsX1J4X0xpbmtfRGF0YV9SYXRl ICAgICAgICAgMTEwX0JQUyAgICAgICAgIDENClZBTFVFICAgRmluYWxfUnhf TGlua19EYXRhX1JhdGUgICAgICAgICAzMDBfQlBTICAgICAgICAgMg0KVkFM VUUgICBGaW5hbF9SeF9MaW5rX0RhdGFfUmF0ZSAgICAgICAgIDYwMF9CUFMg ICAgICAgICAzDQpWQUxVRSAgIEZpbmFsX1J4X0xpbmtfRGF0YV9SYXRlICAg ICAgICAgMTIwMF9CUFMgICAgICAgIDQNClZBTFVFICAgRmluYWxfUnhfTGlu a19EYXRhX1JhdGUgICAgICAgICAyNDAwX0JQUyAgICAgICAgNQ0KVkFMVUUg ICBGaW5hbF9SeF9MaW5rX0RhdGFfUmF0ZSAgICAgICAgIDQ4MDBfQlBTICAg ICAgICA2DQpWQUxVRSAgIEZpbmFsX1J4X0xpbmtfRGF0YV9SYXRlICAgICAg ICAgNzIwMF9CUFMgICAgICAgIDcNClZBTFVFICAgRmluYWxfUnhfTGlua19E YXRhX1JhdGUgICAgICAgICA5NjAwX0JQUyAgICAgICAgOA0KVkFMVUUgICBG aW5hbF9SeF9MaW5rX0RhdGFfUmF0ZSAgICAgICAgIDEyS19CUFMgICAgICAg ICA5DQpWQUxVRSAgIEZpbmFsX1J4X0xpbmtfRGF0YV9SYXRlICAgICAgICAg MTQuNEtfQlBTICAgICAgIDEwDQpWQUxVRSAgIEZpbmFsX1J4X0xpbmtfRGF0 YV9SYXRlICAgICAgICAgMTYuOF9CUFMgICAgICAgIDExDQpWQUxVRSAgIEZp bmFsX1J4X0xpbmtfRGF0YV9SYXRlICAgICAgICAgMTkuMktfQlBTICAgICAg IDEyDQpWQUxVRSAgIEZpbmFsX1J4X0xpbmtfRGF0YV9SYXRlICAgICAgICAg MzguNEtfQlBTICAgICAgIDEzDQpWQUxVRSAgIEZpbmFsX1J4X0xpbmtfRGF0 YV9SYXRlICAgICAgICAgNzVfQlBTICAgICAgICAgIDE0DQpWQUxVRSAgIEZp bmFsX1J4X0xpbmtfRGF0YV9SYXRlICAgICAgICAgNDUwX0JQUyAgICAgICAg IDE1DQpWQUxVRSAgIEZpbmFsX1J4X0xpbmtfRGF0YV9SYXRlICAgICAgICAg VU5LTk9XTl9CUFMgICAgIDE2DQpWQUxVRSAgIEZpbmFsX1J4X0xpbmtfRGF0 YV9SYXRlICAgICAgICAgNTcuNktfQlBTICAgICAgIDE3DQpWQUxVRSAgIEZp bmFsX1J4X0xpbmtfRGF0YV9SYXRlICAgICAgICAgMjEuNktfQlBTICAgICAg IDE4DQpWQUxVRSAgIEZpbmFsX1J4X0xpbmtfRGF0YV9SYXRlICAgICAgICAg MjRLX0JQUyAgICAgICAgIDE5DQpWQUxVRSAgIEZpbmFsX1J4X0xpbmtfRGF0 YV9SYXRlICAgICAgICAgMjZLX0JQUyAgICAgICAgIDIwDQpWQUxVRSAgIEZp bmFsX1J4X0xpbmtfRGF0YV9SYXRlICAgICAgICAgMjhLX0JQUyAgICAgICAg IDIxDQpWQUxVRSAgICBGaW5hbF9SeF9MaW5rX0RhdGFfUmF0ZSAgICAgICAg MTE1S19CUFMgICAgICAgIDIyDQpWQUxVRSAgIEZpbmFsX1J4X0xpbmtfRGF0 YV9SYXRlICAgICAgICAgMzFLX0JQUyAgICAgICAgIDIzDQpWQUxVRSAgIEZp bmFsX1J4X0xpbmtfRGF0YV9SYXRlICAgICAgICAgMzNLX0JQUyAgICAgICAg IDI0DQpWQUxVRSAgIEZpbmFsX1J4X0xpbmtfRGF0YV9SYXRlICAgICAgICAg MjUzMzNfQlBTICAgICAgIDI1DQpWQUxVRSAgIEZpbmFsX1J4X0xpbmtfRGF0 YV9SYXRlICAgICAgICAgMjY2NjZfQlBTICAgICAgIDI2DQpWQUxVRSAgIEZp bmFsX1J4X0xpbmtfRGF0YV9SYXRlICAgICAgICAgMjgwMDBfQlBTICAgICAg IDI3DQpWQUxVRSAgIEZpbmFsX1J4X0xpbmtfRGF0YV9SYXRlICAgICAgICAg MjkzMzNfQlBTICAgICAgIDI4DQpWQUxVRSAgIEZpbmFsX1J4X0xpbmtfRGF0 YV9SYXRlICAgICAgICAgMzA2NjZfQlBTICAgICAgIDI5DQpWQUxVRSAgIEZp bmFsX1J4X0xpbmtfRGF0YV9SYXRlICAgICAgICAgMzIwMDBfQlBTICAgICAg IDMwDQpWQUxVRSAgIEZpbmFsX1J4X0xpbmtfRGF0YV9SYXRlICAgICAgICAg MzMzMzNfQlBTICAgICAgIDMxDQpWQUxVRSAgIEZpbmFsX1J4X0xpbmtfRGF0 YV9SYXRlICAgICAgICAgMzQ2NjZfQlBTICAgICAgIDMyDQpWQUxVRSAgIEZp bmFsX1J4X0xpbmtfRGF0YV9SYXRlICAgICAgICAgMzYwMDBfQlBTICAgICAg IDMzDQpWQUxVRSAgIEZpbmFsX1J4X0xpbmtfRGF0YV9SYXRlICAgICAgICAg MzczMzNfQlBTICAgICAgIDM0DQpWQUxVRSAgIEZpbmFsX1J4X0xpbmtfRGF0 YV9SYXRlICAgICAgICAgMzg2NjZfQlBTICAgICAgIDM1DQpWQUxVRSAgIEZp bmFsX1J4X0xpbmtfRGF0YV9SYXRlICAgICAgICAgNDAwMDBfQlBTICAgICAg IDM2DQpWQUxVRSAgIEZpbmFsX1J4X0xpbmtfRGF0YV9SYXRlICAgICAgICAg NDEzMzNfQlBTICAgICAgIDM3DQpWQUxVRSAgIEZpbmFsX1J4X0xpbmtfRGF0 YV9SYXRlICAgICAgICAgNDI2NjZfQlBTICAgICAgIDM4DQpWQUxVRSAgIEZp bmFsX1J4X0xpbmtfRGF0YV9SYXRlICAgICAgICAgNDQwMDBfQlBTICAgICAg IDM5DQpWQUxVRSAgIEZpbmFsX1J4X0xpbmtfRGF0YV9SYXRlICAgICAgICAg NDUzMzNfQlBTICAgICAgIDQwDQpWQUxVRSAgIEZpbmFsX1J4X0xpbmtfRGF0 YV9SYXRlICAgICAgICAgNDY2NjZfQlBTICAgICAgIDQxDQpWQUxVRSAgIEZp bmFsX1J4X0xpbmtfRGF0YV9SYXRlICAgICAgICAgNDgwMDBfQlBTICAgICAg IDQyDQpWQUxVRSAgIEZpbmFsX1J4X0xpbmtfRGF0YV9SYXRlICAgICAgICAg NDkzMzNfQlBTICAgICAgIDQzDQpWQUxVRSAgIEZpbmFsX1J4X0xpbmtfRGF0 YV9SYXRlICAgICAgICAgNTA2NjZfQlBTICAgICAgIDQ0DQpWQUxVRSAgIEZp bmFsX1J4X0xpbmtfRGF0YV9SYXRlICAgICAgICAgNTIwMDBfQlBTICAgICAg IDQ1DQpWQUxVRSAgIEZpbmFsX1J4X0xpbmtfRGF0YV9SYXRlICAgICAgICAg NTMzMzNfQlBTICAgICAgIDQ2DQpWQUxVRSAgIEZpbmFsX1J4X0xpbmtfRGF0 YV9SYXRlICAgICAgICAgNTQ2NjZfQlBTICAgICAgIDQ3DQpWQUxVRSAgIEZp bmFsX1J4X0xpbmtfRGF0YV9SYXRlICAgICAgICAgNTYwMDBfQlBTICAgICAg IDQ4DQpWQUxVRSAgIEZpbmFsX1J4X0xpbmtfRGF0YV9SYXRlICAgICAgICAg NTczMzNfQlBTICAgICAgIDQ5DQpWQUxVRSAgIEZpbmFsX1J4X0xpbmtfRGF0 YV9SYXRlICAgICAgICAgNTg2NjZfQlBTICAgICAgIDUwDQpWQUxVRSAgIEZp bmFsX1J4X0xpbmtfRGF0YV9SYXRlICAgICAgICAgNjAwMDBfQlBTICAgICAg IDUxDQpWQUxVRSAgIEZpbmFsX1J4X0xpbmtfRGF0YV9SYXRlICAgICAgICAg NjEzMzNfQlBTICAgICAgIDUyDQpWQUxVRSAgIEZpbmFsX1J4X0xpbmtfRGF0 YV9SYXRlICAgICAgICAgNjI2NjZfQlBTICAgICAgIDUzDQpWQUxVRSAgIEZp bmFsX1J4X0xpbmtfRGF0YV9SYXRlICAgICAgICAgNjQwMDBfQlBTICAgICAg IDU0DQoNClZBTFVFICAgSW5pdGlhbF9UeF9MaW5rX0RhdGFfUmF0ZSAgICAg ICAxMTBfQlBTICAgICAgICAgMQ0KVkFMVUUgICBJbml0aWFsX1R4X0xpbmtf RGF0YV9SYXRlICAgICAgIDMwMF9CUFMgICAgICAgICAyDQpWQUxVRSAgIElu aXRpYWxfVHhfTGlua19EYXRhX1JhdGUgICAgICAgNjAwX0JQUyAgICAgICAg IDMNClZBTFVFICAgSW5pdGlhbF9UeF9MaW5rX0RhdGFfUmF0ZSAgICAgICAx MjAwX0JQUyAgICAgICAgNA0KVkFMVUUgICBJbml0aWFsX1R4X0xpbmtfRGF0 YV9SYXRlICAgICAgIDI0MDBfQlBTICAgICAgICA1DQpWQUxVRSAgIEluaXRp YWxfVHhfTGlua19EYXRhX1JhdGUgICAgICAgNDgwMF9CUFMgICAgICAgIDYN ClZBTFVFICAgSW5pdGlhbF9UeF9MaW5rX0RhdGFfUmF0ZSAgICAgICA3MjAw X0JQUyAgICAgICAgNw0KVkFMVUUgICBJbml0aWFsX1R4X0xpbmtfRGF0YV9S YXRlICAgICAgIDk2MDBfQlBTICAgICAgICA4DQpWQUxVRSAgIEluaXRpYWxf VHhfTGlua19EYXRhX1JhdGUgICAgICAgMTJLX0JQUyAgICAgICAgIDkNClZB TFVFICAgSW5pdGlhbF9UeF9MaW5rX0RhdGFfUmF0ZSAgICAgICAxNC40S19C UFMgICAgICAgMTANClZBTFVFICAgSW5pdGlhbF9UeF9MaW5rX0RhdGFfUmF0 ZSAgICAgICAxNi44X0JQUyAgICAgICAgMTENClZBTFVFICAgSW5pdGlhbF9U eF9MaW5rX0RhdGFfUmF0ZSAgICAgICAxOS4yS19CUFMgICAgICAgMTINClZB TFVFICAgSW5pdGlhbF9UeF9MaW5rX0RhdGFfUmF0ZSAgICAgICAzOC40S19C UFMgICAgICAgMTMNClZBTFVFICAgSW5pdGlhbF9UeF9MaW5rX0RhdGFfUmF0 ZSAgICAgICA3NV9CUFMgICAgICAgICAgMTQNClZBTFVFICAgSW5pdGlhbF9U eF9MaW5rX0RhdGFfUmF0ZSAgICAgICA0NTBfQlBTICAgICAgICAgMTUNClZB TFVFICAgSW5pdGlhbF9UeF9MaW5rX0RhdGFfUmF0ZSAgICAgICBVTktOT1dO X0JQUyAgICAgMTYNClZBTFVFICAgSW5pdGlhbF9UeF9MaW5rX0RhdGFfUmF0 ZSAgICAgICA1Ny42S19CUFMgICAgICAgMTcNClZBTFVFICAgSW5pdGlhbF9U eF9MaW5rX0RhdGFfUmF0ZSAgICAgICAyMS42S19CUFMgICAgICAgMTgNClZB TFVFICAgSW5pdGlhbF9UeF9MaW5rX0RhdGFfUmF0ZSAgICAgICAyNEtfQlBT ICAgICAgICAgMTkNClZBTFVFICAgSW5pdGlhbF9UeF9MaW5rX0RhdGFfUmF0 ZSAgICAgICAyNktfQlBTICAgICAgICAgMjANClZBTFVFICAgSW5pdGlhbF9U eF9MaW5rX0RhdGFfUmF0ZSAgICAgICAyOEtfQlBTICAgICAgICAgMjENClZB TFVFICAgIEluaXRpYWxfVHhfTGlua19EYXRhX1JhdGUgICAgMTE1S19CUFMg ICAgMjINClZBTFVFICAgSW5pdGlhbF9UeF9MaW5rX0RhdGFfUmF0ZSAgICAg ICAzMUtfQlBTICAgICAgICAgMjMgICAgICANClZBTFVFICAgSW5pdGlhbF9U eF9MaW5rX0RhdGFfUmF0ZSAgICAgICAzM0tfQlBTICAgICAgICAgMjQNClZB TFVFICAgSW5pdGlhbF9UeF9MaW5rX0RhdGFfUmF0ZSAgICAgICAyNTMzM19C UFMgICAgICAgMjUNClZBTFVFICAgSW5pdGlhbF9UeF9MaW5rX0RhdGFfUmF0 ZSAgICAgICAyNjY2Nl9CUFMgICAgICAgMjYNClZBTFVFICAgSW5pdGlhbF9U eF9MaW5rX0RhdGFfUmF0ZSAgICAgICAyODAwMF9CUFMgICAgICAgMjcNClZB TFVFICAgSW5pdGlhbF9UeF9MaW5rX0RhdGFfUmF0ZSAgICAgICAyOTMzM19C UFMgICAgICAgMjgNClZBTFVFICAgSW5pdGlhbF9UeF9MaW5rX0RhdGFfUmF0 ZSAgICAgICAzMDY2Nl9CUFMgICAgICAgMjkNClZBTFVFICAgSW5pdGlhbF9U eF9MaW5rX0RhdGFfUmF0ZSAgICAgICAzMjAwMF9CUFMgICAgICAgMzANClZB TFVFICAgSW5pdGlhbF9UeF9MaW5rX0RhdGFfUmF0ZSAgICAgICAzMzMzM19C UFMgICAgICAgMzENClZBTFVFICAgSW5pdGlhbF9UeF9MaW5rX0RhdGFfUmF0 ZSAgICAgICAzNDY2Nl9CUFMgICAgICAgMzINClZBTFVFICAgSW5pdGlhbF9U eF9MaW5rX0RhdGFfUmF0ZSAgICAgICAzNjAwMF9CUFMgICAgICAgMzMNClZB TFVFICAgSW5pdGlhbF9UeF9MaW5rX0RhdGFfUmF0ZSAgICAgICAzNzMzM19C UFMgICAgICAgMzQNClZBTFVFICAgSW5pdGlhbF9UeF9MaW5rX0RhdGFfUmF0 ZSAgICAgICAzODY2Nl9CUFMgICAgICAgMzUNClZBTFVFICAgSW5pdGlhbF9U eF9MaW5rX0RhdGFfUmF0ZSAgICAgICA0MDAwMF9CUFMgICAgICAgMzYNClZB TFVFICAgSW5pdGlhbF9UeF9MaW5rX0RhdGFfUmF0ZSAgICAgICA0MTMzM19C UFMgICAgICAgMzcNClZBTFVFICAgSW5pdGlhbF9UeF9MaW5rX0RhdGFfUmF0 ZSAgICAgICA0MjY2Nl9CUFMgICAgICAgMzgNClZBTFVFICAgSW5pdGlhbF9U eF9MaW5rX0RhdGFfUmF0ZSAgICAgICA0NDAwMF9CUFMgICAgICAgMzkNClZB TFVFICAgSW5pdGlhbF9UeF9MaW5rX0RhdGFfUmF0ZSAgICAgICA0NTMzM19C UFMgICAgICAgNDANClZBTFVFICAgSW5pdGlhbF9UeF9MaW5rX0RhdGFfUmF0 ZSAgICAgICA0NjY2Nl9CUFMgICAgICAgNDENClZBTFVFICAgSW5pdGlhbF9U eF9MaW5rX0RhdGFfUmF0ZSAgICAgICA0ODAwMF9CUFMgICAgICAgNDINClZB TFVFICAgSW5pdGlhbF9UeF9MaW5rX0RhdGFfUmF0ZSAgICAgICA0OTMzM19C UFMgICAgICAgNDMNClZBTFVFICAgSW5pdGlhbF9UeF9MaW5rX0RhdGFfUmF0 ZSAgICAgICA1MDY2Nl9CUFMgICAgICAgNDQNClZBTFVFICAgSW5pdGlhbF9U eF9MaW5rX0RhdGFfUmF0ZSAgICAgICA1MjAwMF9CUFMgICAgICAgNDUNClZB TFVFICAgSW5pdGlhbF9UeF9MaW5rX0RhdGFfUmF0ZSAgICAgICA1MzMzM19C UFMgICAgICAgNDYNClZBTFVFICAgSW5pdGlhbF9UeF9MaW5rX0RhdGFfUmF0 ZSAgICAgICA1NDY2Nl9CUFMgICAgICAgNDcNClZBTFVFICAgSW5pdGlhbF9U eF9MaW5rX0RhdGFfUmF0ZSAgICAgICA1NjAwMF9CUFMgICAgICAgNDgNClZB TFVFICAgSW5pdGlhbF9UeF9MaW5rX0RhdGFfUmF0ZSAgICAgICA1NzMzM19C UFMgICAgICAgNDkNClZBTFVFICAgSW5pdGlhbF9UeF9MaW5rX0RhdGFfUmF0 ZSAgICAgICA1ODY2Nl9CUFMgICAgICAgNTANClZBTFVFICAgSW5pdGlhbF9U eF9MaW5rX0RhdGFfUmF0ZSAgICAgICA2MDAwMF9CUFMgICAgICAgNTENClZB TFVFICAgSW5pdGlhbF9UeF9MaW5rX0RhdGFfUmF0ZSAgICAgICA2MTMzM19C UFMgICAgICAgNTINClZBTFVFICAgSW5pdGlhbF9UeF9MaW5rX0RhdGFfUmF0 ZSAgICAgICA2MjY2Nl9CUFMgICAgICAgNTMNClZBTFVFICAgSW5pdGlhbF9U eF9MaW5rX0RhdGFfUmF0ZSAgICAgICA2NDAwMF9CUFMgICAgICAgNTQNCg0K VkFMVUUgICBGaW5hbF9UeF9MaW5rX0RhdGFfUmF0ZSAgICAgICAgIDExMF9C UFMgICAgICAgICAxDQpWQUxVRSAgIEZpbmFsX1R4X0xpbmtfRGF0YV9SYXRl ICAgICAgICAgMzAwX0JQUyAgICAgICAgIDINClZBTFVFICAgRmluYWxfVHhf TGlua19EYXRhX1JhdGUgICAgICAgICA2MDBfQlBTICAgICAgICAgMw0KVkFM VUUgICBGaW5hbF9UeF9MaW5rX0RhdGFfUmF0ZSAgICAgICAgIDEyMDBfQlBT ICAgICAgICA0DQpWQUxVRSAgIEZpbmFsX1R4X0xpbmtfRGF0YV9SYXRlICAg ICAgICAgMjQwMF9CUFMgICAgICAgIDUNClZBTFVFICAgRmluYWxfVHhfTGlu a19EYXRhX1JhdGUgICAgICAgICA0ODAwX0JQUyAgICAgICAgNg0KVkFMVUUg ICBGaW5hbF9UeF9MaW5rX0RhdGFfUmF0ZSAgICAgICAgIDcyMDBfQlBTICAg ICAgICA3DQpWQUxVRSAgIEZpbmFsX1R4X0xpbmtfRGF0YV9SYXRlICAgICAg ICAgOTYwMF9CUFMgICAgICAgIDgNClZBTFVFICAgRmluYWxfVHhfTGlua19E YXRhX1JhdGUgICAgICAgICAxMktfQlBTICAgICAgICAgOQ0KVkFMVUUgICBG aW5hbF9UeF9MaW5rX0RhdGFfUmF0ZSAgICAgICAgIDE0LjRLX0JQUyAgICAg ICAxMA0KVkFMVUUgICBGaW5hbF9UeF9MaW5rX0RhdGFfUmF0ZSAgICAgICAg IDE2LjhfQlBTICAgICAgICAxMQ0KVkFMVUUgICBGaW5hbF9UeF9MaW5rX0Rh dGFfUmF0ZSAgICAgICAgIDE5LjJLX0JQUyAgICAgICAxMg0KVkFMVUUgICBG aW5hbF9UeF9MaW5rX0RhdGFfUmF0ZSAgICAgICAgIDM4LjRLX0JQUyAgICAg ICAxMw0KVkFMVUUgICBGaW5hbF9UeF9MaW5rX0RhdGFfUmF0ZSAgICAgICAg IDc1X0JQUyAgICAgICAgICAxNA0KVkFMVUUgICBGaW5hbF9UeF9MaW5rX0Rh dGFfUmF0ZSAgICAgICAgIDQ1MF9CUFMgICAgICAgICAxNQ0KVkFMVUUgICBG aW5hbF9UeF9MaW5rX0RhdGFfUmF0ZSAgICAgICAgIFVOS05PV05fQlBTICAg ICAxNg0KVkFMVUUgICBGaW5hbF9UeF9MaW5rX0RhdGFfUmF0ZSAgICAgICAg IDU3LjZLX0JQUyAgICAgICAxNw0KVkFMVUUgICBGaW5hbF9UeF9MaW5rX0Rh dGFfUmF0ZSAgICAgICAgIDIxLjZLX0JQUyAgICAgICAxOA0KVkFMVUUgICBG aW5hbF9UeF9MaW5rX0RhdGFfUmF0ZSAgICAgICAgIDI0S19CUFMgICAgICAg ICAxOQ0KVkFMVUUgICBGaW5hbF9UeF9MaW5rX0RhdGFfUmF0ZSAgICAgICAg IDI2S19CUFMgICAgICAgICAyMA0KVkFMVUUgICBGaW5hbF9UeF9MaW5rX0Rh dGFfUmF0ZSAgICAgICAgIDI4S19CUFMgICAgICAgICAyMQ0KVkFMVUUgICBG aW5hbF9UeF9MaW5rX0RhdGFfUmF0ZSAgICAgICAgMTE1S19CUFMgICAgICAg ICAyMg0KVkFMVUUgICBGaW5hbF9UeF9MaW5rX0RhdGFfUmF0ZSAgICAgICAg IDMxS19CUFMgICAgICAgICAyMw0KVkFMVUUgICBGaW5hbF9UeF9MaW5rX0Rh dGFfUmF0ZSAgICAgICAgIDMzS19CUFMgICAgICAgICAyNA0KVkFMVUUgICBG aW5hbF9UeF9MaW5rX0RhdGFfUmF0ZSAgICAgICAgIDI1MzMzX0JQUyAgICAg ICAyNQ0KVkFMVUUgICBGaW5hbF9UeF9MaW5rX0RhdGFfUmF0ZSAgICAgICAg IDI2NjY2X0JQUyAgICAgICAyNg0KVkFMVUUgICBGaW5hbF9UeF9MaW5rX0Rh dGFfUmF0ZSAgICAgICAgIDI4MDAwX0JQUyAgICAgICAyNw0KVkFMVUUgICBG aW5hbF9UeF9MaW5rX0RhdGFfUmF0ZSAgICAgICAgIDI5MzMzX0JQUyAgICAg ICAyOA0KVkFMVUUgICBGaW5hbF9UeF9MaW5rX0RhdGFfUmF0ZSAgICAgICAg IDMwNjY2X0JQUyAgICAgICAyOQ0KVkFMVUUgICBGaW5hbF9UeF9MaW5rX0Rh dGFfUmF0ZSAgICAgICAgIDMyMDAwX0JQUyAgICAgICAzMA0KVkFMVUUgICBG aW5hbF9UeF9MaW5rX0RhdGFfUmF0ZSAgICAgICAgIDMzMzMzX0JQUyAgICAg ICAzMQ0KVkFMVUUgICBGaW5hbF9UeF9MaW5rX0RhdGFfUmF0ZSAgICAgICAg IDM0NjY2X0JQUyAgICAgICAzMg0KVkFMVUUgICBGaW5hbF9UeF9MaW5rX0Rh dGFfUmF0ZSAgICAgICAgIDM2MDAwX0JQUyAgICAgICAzMw0KVkFMVUUgICBG aW5hbF9UeF9MaW5rX0RhdGFfUmF0ZSAgICAgICAgIDM3MzMzX0JQUyAgICAg ICAzNA0KVkFMVUUgICBGaW5hbF9UeF9MaW5rX0RhdGFfUmF0ZSAgICAgICAg IDM4NjY2X0JQUyAgICAgICAzNQ0KVkFMVUUgICBGaW5hbF9UeF9MaW5rX0Rh dGFfUmF0ZSAgICAgICAgIDQwMDAwX0JQUyAgICAgICAzNg0KVkFMVUUgICBG aW5hbF9UeF9MaW5rX0RhdGFfUmF0ZSAgICAgICAgIDQxMzMzX0JQUyAgICAg ICAzNw0KVkFMVUUgICBGaW5hbF9UeF9MaW5rX0RhdGFfUmF0ZSAgICAgICAg IDQyNjY2X0JQUyAgICAgICAzOA0KVkFMVUUgICBGaW5hbF9UeF9MaW5rX0Rh dGFfUmF0ZSAgICAgICAgIDQ0MDAwX0JQUyAgICAgICAzOQ0KVkFMVUUgICBG aW5hbF9UeF9MaW5rX0RhdGFfUmF0ZSAgICAgICAgIDQ1MzMzX0JQUyAgICAg ICA0MA0KVkFMVUUgICBGaW5hbF9UeF9MaW5rX0RhdGFfUmF0ZSAgICAgICAg IDQ2NjY2X0JQUyAgICAgICA0MQ0KVkFMVUUgICBGaW5hbF9UeF9MaW5rX0Rh dGFfUmF0ZSAgICAgICAgIDQ4MDAwX0JQUyAgICAgICA0Mg0KVkFMVUUgICBG aW5hbF9UeF9MaW5rX0RhdGFfUmF0ZSAgICAgICAgIDQ5MzMzX0JQUyAgICAg ICA0Mw0KVkFMVUUgICBGaW5hbF9UeF9MaW5rX0RhdGFfUmF0ZSAgICAgICAg IDUwNjY2X0JQUyAgICAgICA0NA0KVkFMVUUgICBGaW5hbF9UeF9MaW5rX0Rh dGFfUmF0ZSAgICAgICAgIDUyMDAwX0JQUyAgICAgICA0NQ0KVkFMVUUgICBG aW5hbF9UeF9MaW5rX0RhdGFfUmF0ZSAgICAgICAgIDUzMzMzX0JQUyAgICAg ICA0Ng0KVkFMVUUgICBGaW5hbF9UeF9MaW5rX0RhdGFfUmF0ZSAgICAgICAg IDU0NjY2X0JQUyAgICAgICA0Nw0KVkFMVUUgICBGaW5hbF9UeF9MaW5rX0Rh dGFfUmF0ZSAgICAgICAgIDU2MDAwX0JQUyAgICAgICA0OA0KVkFMVUUgICBG aW5hbF9UeF9MaW5rX0RhdGFfUmF0ZSAgICAgICAgIDU3MzMzX0JQUyAgICAg ICA0OQ0KVkFMVUUgICBGaW5hbF9UeF9MaW5rX0RhdGFfUmF0ZSAgICAgICAg IDU4NjY2X0JQUyAgICAgICA1MA0KVkFMVUUgICBGaW5hbF9UeF9MaW5rX0Rh dGFfUmF0ZSAgICAgICAgIDYwMDAwX0JQUyAgICAgICA1MQ0KVkFMVUUgICBG aW5hbF9UeF9MaW5rX0RhdGFfUmF0ZSAgICAgICAgIDYxMzMzX0JQUyAgICAg ICA1Mg0KVkFMVUUgICBGaW5hbF9UeF9MaW5rX0RhdGFfUmF0ZSAgICAgICAg IDYyNjY2X0JQUyAgICAgICA1Mw0KVkFMVUUgICBGaW5hbF9UeF9MaW5rX0Rh dGFfUmF0ZSAgICAgICAgIDY0MDAwX0JQUyAgICAgICA1NA0KDQoNCiMNCg0K VkFMVUUgICBTeW5jX0FzeW5jX01vZGUgICAgICAgICAgICAgICAgIEFzeW5j aHJvbm91cyAgICAgICAgICAgIDENClZBTFVFICAgU3luY19Bc3luY19Nb2Rl ICAgICAgICAgU3luY2hyb25vdXMgICAgICAgICAgICAgICAgICAgICAyDQoN ClZBTFVFICAgT3JpZ2luYXRlX0Fuc3dlcl9Nb2RlICAgT3JpZ2luYXRlX2lu X09yaWdpbmF0ZV9Nb2RlICAgICAgICAgICAgIDENClZBTFVFICAgT3JpZ2lu YXRlX0Fuc3dlcl9Nb2RlICAgT3JpZ2luYXRlX2luX0Fuc3dlcl9Nb2RlICAg ICAgICAgICAgICAgIDINClZBTFVFICAgT3JpZ2luYXRlX0Fuc3dlcl9Nb2Rl ICAgQW5zd2VyX2luX09yaWdpbmF0ZV9Nb2RlICAgICAgICAzDQpWQUxVRSAg IE9yaWdpbmF0ZV9BbnN3ZXJfTW9kZSAgIEFuc3dlcl9pbl9BbnN3ZXJfTW9k ZSAgICAgICAgICAgNA0KDQoNClZBTFVFICAgTW9kdWxhdGlvbl9UeXBlICAg ICAgICAgdXNSb2JvdGljc0hTVCAgICAgICAgICAgICAgICAgICAxDQpWQUxV RSAgIE1vZHVsYXRpb25fVHlwZSAgICAgICAgIGNjaXR0VjMyICAgICAgICAg ICAgICAgICAgICAgICAgMg0KVkFMVUUgICBNb2R1bGF0aW9uX1R5cGUgICAg ICAgICBjY2l0dFYyMmJpcyAgICAgICAgICAgICAgICAgICAgIDMNClZBTFVF ICAgTW9kdWxhdGlvbl9UeXBlICAgICAgICAgYmVsbDEwMyAgICAgICAgICAg ICAgICAgICAgICAgICA0DQpWQUxVRSAgIE1vZHVsYXRpb25fVHlwZSAgICAg ICAgIGNjaXR0VjIxICAgICAgICAgICAgICAgICAgICAgICAgNQ0KVkFMVUUg ICBNb2R1bGF0aW9uX1R5cGUgICAgICAgICBiZWxsMjEyICAgICAgICAgICAg ICAgICAgICAgICAgIDYNClZBTFVFICAgTW9kdWxhdGlvbl9UeXBlICAgICAg ICAgY2NpdHRWMzJiaXMgICAgICAgICAgICAgICAgICAgICA3DQpWQUxVRSAg IE1vZHVsYXRpb25fVHlwZSAgICAgICAgIGNjaXR0VjIzICAgICAgICAgICAg ICAgICAgICAgICAgOA0KVkFMVUUgICBNb2R1bGF0aW9uX1R5cGUgICAgICAg ICBuZWdvdGlhdGlvbkZhaWxlZCAgICAgICAgICAgICAgIDkNClZBTFVFICAg TW9kdWxhdGlvbl9UeXBlICAgICAgICAgYmVsbDIwOGIgICAgICAgICAgICAg ICAgICAgICAgICAxMA0KVkFMVUUgICBNb2R1bGF0aW9uX1R5cGUgICAgICAg ICB2MjFGYXhDbGFzczEgICAgICAgICAgICAgICAgICAgIDExDQpWQUxVRSAg IE1vZHVsYXRpb25fVHlwZSAgICAgICAgIHYyN0ZheENsYXNzMSAgICAgICAg ICAgICAgICAgICAgMTINClZBTFVFICAgTW9kdWxhdGlvbl9UeXBlICAgICAg ICAgdjI5RmF4Q2xhc3MxICAgICAgICAgICAgICAgICAgICAxMw0KVkFMVUUg ICBNb2R1bGF0aW9uX1R5cGUgICAgICAgICB2MTdGYXhDbGFzczEgICAgICAg ICAgICAgICAgICAgIDE0DQpWQUxVRSAgIE1vZHVsYXRpb25fVHlwZSAgICAg ICAgIHYyMUZheENsYXNzMiAgICAgICAgICAgICAgICAgICAgMTUNClZBTFVF ICAgTW9kdWxhdGlvbl9UeXBlICAgICAgICAgdjI3RmF4Q2xhc3MyICAgICAg ICAgICAgICAgICAgICAxNg0KVkFMVUUgICBNb2R1bGF0aW9uX1R5cGUgICAg ICAgICB2MjlGYXhDbGFzczIgICAgICAgICAgICAgICAgICAgIDE3DQpWQUxV RSAgIE1vZHVsYXRpb25fVHlwZSAgICAgICAgIHYxN0ZheENsYXNzMiAgICAg ICAgICAgICAgICAgICAgMTgNClZBTFVFICAgTW9kdWxhdGlvbl9UeXBlICAg ICAgICAgdjMyVGVyYm8gICAgICAgICAgICAgICAgICAgICAgICAxOQ0KVkFM VUUgICBNb2R1bGF0aW9uX1R5cGUgICAgICAgICB2MzQgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIDIwDQpWQUxVRSAgIE1vZHVsYXRpb25fVHlwZSAg ICAgICAgIHZGQyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgMjENClZB TFVFICAgTW9kdWxhdGlvbl9UeXBlICAgICAgICAgdjM0cGx1cyAgICAgICAg ICAgICAgICAgICAgICAgICAyMg0KVkFMVUUgICBNb2R1bGF0aW9uX1R5cGUg ICAgICAgICB4MiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDIzIA0K VkFMVUUgICBNb2R1bGF0aW9uX1R5cGUgICAgICAgICB2MTEwICAgICAgICAg ICAgICAgICAgICAgICAgICAgIDI0DQpWQUxVRSAgIE1vZHVsYXRpb25fVHlw ZSAgICAgICAgIHYxMjAgICAgICAgICAgICAgICAgICAgICAgICAgICAgMjUN ClZBTFVFICAgTW9kdWxhdGlvbl9UeXBlICAgICAgICAgeDc1ICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAyNg0KVkFMVUUgICBNb2R1bGF0aW9uX1R5 cGUgICAgICAgICBheW5jU3luY1BQUCAgICAgICAgICAgICAgICAgICAgIDI3 DQpWQUxVRSAgIE1vZHVsYXRpb25fVHlwZSAgICAgICAgIGNsZWFyQ2hhbm5l bCAgICAgICAgICAgICAgICAgICAgMjgNClZBTFVFICAgTW9kdWxhdGlvbl9U eXBlICAgICAgICAgeDJjbGllbnQgICAgICAgICAgICAgICAgICAgICAgICAy OQ0KVkFMVUUgICBNb2R1bGF0aW9uX1R5cGUgICAgICAgICB4MnN5bW1ldHJp YyAgICAgICAgICAgICAgICAgICAgIDMwDQpWQUxVRSAgIE1vZHVsYXRpb25f VHlwZSAgICAgICAgIHBpYWZzICAgICAgICAgICAgICAgICAgICAgICAgICAg MzEgICANCg0KVkFMVUUgICBDb25uZWN0X1Rlcm1fUmVhc29uICAgICBkdHJE cm9wICAgICAgICAgICAgICAgICAgICAgICAgIDENClZBTFVFICAgQ29ubmVj dF9UZXJtX1JlYXNvbiAgICAgZXNjYXBlU2VxdWVuY2UgICAgICAgICAgICAg ICAgICAyDQpWQUxVRSAgIENvbm5lY3RfVGVybV9SZWFzb24gICAgIGF0aENv bW1hbmQgICAgICAgICAgICAgICAgICAgICAgMw0KVkFMVUUgICBDb25uZWN0 X1Rlcm1fUmVhc29uICAgICBjYXJyaWVyTG9zcyAgICAgICAgICAgICAgICAg ICAgIDQNClZBTFVFICAgQ29ubmVjdF9UZXJtX1JlYXNvbiAgICAgaW5hY3Rp dml0eVRpbW91dCAgICAgICAgICAgICAgICA1DQpWQUxVRSAgIENvbm5lY3Rf VGVybV9SZWFzb24gICAgIG1ucEluY29tcGF0aWJsZSAgICAgICAgICAgICAg ICAgNg0KVkFMVUUgICBDb25uZWN0X1Rlcm1fUmVhc29uICAgICB1bmRlZmlu ZWQgICAgICAgICAgICAgICAgICAgICAgIDcNClZBTFVFICAgQ29ubmVjdF9U ZXJtX1JlYXNvbiAgICAgcmVtb3RlUGFzc3dvcmQgICAgICAgICAgICAgICAg ICA4DQpWQUxVRSAgIENvbm5lY3RfVGVybV9SZWFzb24gICAgIGxpbmtQYXNz d29yZCAgICAgICAgICAgICAgICAgICAgOQ0KVkFMVUUgICBDb25uZWN0X1Rl cm1fUmVhc29uICAgICByZXRyYW5zbWl0TGltaXQgICAgICAgICAgICAgICAg IDEwDQpWQUxVRSAgIENvbm5lY3RfVGVybV9SZWFzb24gICAgIGxpbmtEaXNj b25uZWN0TXNnUmVjZWl2ZWQgICAgICAgMTENClZBTFVFICAgQ29ubmVjdF9U ZXJtX1JlYXNvbiAgICAgbm9Mb29wQ3VycmVudCAgICAgICAgICAgICAgICAg ICAxMg0KVkFMVUUgICBDb25uZWN0X1Rlcm1fUmVhc29uICAgICBpbnZhbGlk U3BlZWQgICAgICAgICAgICAgICAgICAgIDEzDQpWQUxVRSAgIENvbm5lY3Rf VGVybV9SZWFzb24gICAgIHVuYWJsZVRvUmV0cmFpbiAgICAgICAgICAgICAg ICAgMTQNClZBTFVFICAgQ29ubmVjdF9UZXJtX1JlYXNvbiAgICAgbWFuYWdl bWVudENvbW1hbmQgICAgICAgICAgICAgICAxNQ0KVkFMVUUgICBDb25uZWN0 X1Rlcm1fUmVhc29uICAgICBub0RpYWxUb25lICAgICAgICAgICAgICAgICAg ICAgIDE2DQpWQUxVRSAgIENvbm5lY3RfVGVybV9SZWFzb24gICAgIGtleUFi b3J0ICAgICAgICAgICAgICAgICAgICAgICAgMTcNClZBTFVFICAgQ29ubmVj dF9UZXJtX1JlYXNvbiAgICAgbGluZUJ1c3kgICAgICAgICAgICAgICAgICAg ICAgICAxOA0KVkFMVUUgICBDb25uZWN0X1Rlcm1fUmVhc29uICAgICBub0Fu c3dlciAgICAgICAgICAgICAgICAgICAgICAgIDE5DQpWQUxVRSAgIENvbm5l Y3RfVGVybV9SZWFzb24gICAgIHZvaWNlICAgICAgICAgICAgICAgICAgICAg ICAgICAgMjANClZBTFVFICAgQ29ubmVjdF9UZXJtX1JlYXNvbiAgICAgbm9B bnN3ZXJUb25lICAgICAgICAgICAgICAgICAgICAyMQ0KVkFMVUUgICBDb25u ZWN0X1Rlcm1fUmVhc29uICAgICBub0NhcnJpZXIgICAgICAgICAgICAgICAg ICAgICAgIDIyDQpWQUxVRSAgIENvbm5lY3RfVGVybV9SZWFzb24gICAgIHVu ZGV0ZXJtaW5lZCAgICAgICAgICAgICAgICAgICAgMjMNClZBTFVFICAgQ29u bmVjdF9UZXJtX1JlYXNvbiAgICAgdjQyU2FibWVUaW1lb3V0ICAgICAgICAg ICAgICAgICAyNA0KVkFMVUUgICBDb25uZWN0X1Rlcm1fUmVhc29uICAgICB2 NDJCcmVha1RpbWVvdXQgICAgICAgICAgICAgICAgIDI1DQpWQUxVRSAgIENv bm5lY3RfVGVybV9SZWFzb24gICAgIHY0MkRpc2Nvbm5lY3RDbWQgICAgICAg ICAgICAgICAgMjYNClZBTFVFICAgQ29ubmVjdF9UZXJtX1JlYXNvbiAgICAg djQySWRFeGNoYW5nZUZhaWwgICAgICAgICAgICAgICAyNw0KVkFMVUUgICBD b25uZWN0X1Rlcm1fUmVhc29uICAgICB2NDJCYWRTZXR1cCAgICAgICAgICAg ICAgICAgICAgIDI4DQpWQUxVRSAgIENvbm5lY3RfVGVybV9SZWFzb24gICAg IHY0MkludmFsaWRDb2RlV29yZCAgICAgICAgICAgICAgMjkNClZBTFVFICAg Q29ubmVjdF9UZXJtX1JlYXNvbiAgICAgdjQyU3RyaW5nVG9Mb25nICAgICAg ICAgICAgICAgICAzMA0KVkFMVUUgICBDb25uZWN0X1Rlcm1fUmVhc29uICAg ICB2NDJJbnZhbGlkQ29tbWFuZCAgICAgICAgICAgICAgIDMxDQpWQUxVRSAg IENvbm5lY3RfVGVybV9SZWFzb24gICAgIG5vbmUgICAgICAgICAgICAgICAg ICAgICAgICAgICAgMzIgICAgICANClZBTFVFICAgQ29ubmVjdF9UZXJtX1Jl YXNvbiAgICAgdjMyQ2xlYXJkb3duICAgICAgICAgICAgICAgICAgICAzMw0K VkFMVUUgICBDb25uZWN0X1Rlcm1fUmVhc29uICAgICBkaWFsU2VjdXJpdHkg ICAgICAgICAgICAgICAgICAgIDM0DQpWQUxVRSAgIENvbm5lY3RfVGVybV9S ZWFzb24gICAgIHJlbW90ZUFjY2Vzc0RlbmllZCAgICAgICAgICAgICAgMzUN ClZBTFVFICAgQ29ubmVjdF9UZXJtX1JlYXNvbiAgICAgbG9vcExvc3MgICAg ICAgICAgICAgICAgICAgICAgICAzNg0KVkFMVUUgICBDb25uZWN0X1Rlcm1f UmVhc29uICAgICBkczBUZWFyZG93biAgICAgICAgICAgICAgICAgICAgIDM3 DQpWQUxVRSAgIENvbm5lY3RfVGVybV9SZWFzb24gICAgIHByb21wdE5vdEVu YWJsZWQgICAgICAgICAgICAgICAgMzgNClZBTFVFICAgQ29ubmVjdF9UZXJt X1JlYXNvbiAgICAgbm9Qcm9tcHRpbmdJblN5bmMgICAgICAgICAgICAgICAz OQ0KVkFMVUUgICBDb25uZWN0X1Rlcm1fUmVhc29uICAgICBub25BcnFNb2Rl ICAgICAgICAgICAgICAgICAgICAgIDQwDQpWQUxVRSAgIENvbm5lY3RfVGVy bV9SZWFzb24gICAgIG1vZGVJbmNvbXBhdGlibGUgICAgICAgICAgICAgICAg NDENClZBTFVFICAgQ29ubmVjdF9UZXJtX1JlYXNvbiAgICAgbm9Qcm9tcHRJ bk5vbkFSUSAgICAgICAgICAgICAgICA0Mg0KVkFMVUUgICBDb25uZWN0X1Rl cm1fUmVhc29uICAgICBkaWFsQmFja0xpbmsgICAgICAgICAgICAgICAgICAg IDQzDQpWQUxVRSAgIENvbm5lY3RfVGVybV9SZWFzb24gICAgIGxpbmtBYm9y dCAgICAgICAgICAgICAgICAgICAgICAgNDQNClZBTFVFICAgQ29ubmVjdF9U ZXJtX1JlYXNvbiAgICAgYXV0b3Bhc3NGYWlsZWQgICAgICAgICAgICAgICAg ICA0NQ0KVkFMVUUgICBDb25uZWN0X1Rlcm1fUmVhc29uICAgICBwYkdlbmVy aWNFcnJvciAgICAgICAgICAgICAgICAgIDQ2DQpWQUxVRSAgIENvbm5lY3Rf VGVybV9SZWFzb24gICAgIHBiTGlua0VyclR4UHJlQWNrICAgICAgICAgICAg ICAgNDcNClZBTFVFICAgQ29ubmVjdF9UZXJtX1JlYXNvbiAgICAgcGJMaW5r RXJyVHhUYXJkeUFDSyAgICAgICAgICAgICA0OA0KVkFMVUUgICBDb25uZWN0 X1Rlcm1fUmVhc29uICAgICBwYlRyYW5zbWl0QnVzVGltZW91dCAgICAgICAg ICAgIDQ5DQpWQUxVRSAgIENvbm5lY3RfVGVybV9SZWFzb24gICAgIHBiUmVj ZWl2ZUJ1c1RpbWVvdXQgICAgICAgICAgICAgNTANClZBTFVFICAgQ29ubmVj dF9UZXJtX1JlYXNvbiAgICAgcGJMaW5rRXJyVHhUQUwgICAgICAgICAgICAg ICAgICA1MQ0KVkFMVUUgICBDb25uZWN0X1Rlcm1fUmVhc29uICAgICBwYkxp bmtFcnJSeFRBTCAgICAgICAgICAgICAgICAgIDUyDQpWQUxVRSAgIENvbm5l Y3RfVGVybV9SZWFzb24gICAgIHBiVHJhbnNtaXRNYXN0ZXJUaW1lb3V0ICAg ICAgICAgNTMNClZBTFVFICAgQ29ubmVjdF9UZXJtX1JlYXNvbiAgICAgcGJD bG9ja01pc3NpbmcgICAgICAgICAgICAgICAgICA1NA0KVkFMVUUgICBDb25u ZWN0X1Rlcm1fUmVhc29uICAgICBwYlJlY2VpdmVkTHNXaGlsZUxpbmtVcCAg ICAgICAgIDU1DQpWQUxVRSAgIENvbm5lY3RfVGVybV9SZWFzb24gICAgIHBi T3V0T2ZTZXF1ZW5jZUZyYW1lICAgICAgICAgICAgNTYNClZBTFVFICAgQ29u bmVjdF9UZXJtX1JlYXNvbiAgICAgcGJCYWRGcmFtZSAgICAgICAgICAgICAg ICAgICAgICA1Nw0KVkFMVUUgICBDb25uZWN0X1Rlcm1fUmVhc29uICAgICBw YkFja1dhaXRUaW1lb3V0ICAgICAgICAgICAgICAgIDU4DQpWQUxVRSAgIENv bm5lY3RfVGVybV9SZWFzb24gICAgIHBiUmVjZWl2ZWRBY2tTZXFFcnIgICAg ICAgICAgICAgNTkNClZBTFVFICAgQ29ubmVjdF9UZXJtX1JlYXNvbiAgICAg cGJSZWNlaXZlT3ZyZmx3Uk5SRmFpbCAgICAgICAgICA2MA0KVkFMVUUgICBD b25uZWN0X1Rlcm1fUmVhc29uICAgICBwYlJlY2VpdmVNc2dCdWZPdnJmbHcg ICAgICAgICAgIDYxDQpWQUxVRSAgIENvbm5lY3RfVGVybV9SZWFzb24gICAg IHJjdmRHYXRld2F5RGlzY0NtZCAgICAgICAgICAgICAgNjINClZBTFVFICAg Q29ubmVjdF9UZXJtX1JlYXNvbiAgICAgdG9rZW5QYXNzaW5nVGltZW91dCAg ICAgICAgICAgICA2Mw0KVkFMVUUgICBDb25uZWN0X1Rlcm1fUmVhc29uICAg ICBkc3BJbnRlcnJ1cHRUaW1lb3V0ICAgICAgICAgICAgIDY0DQpWQUxVRSAg IENvbm5lY3RfVGVybV9SZWFzb24gICAgIG1ucFByb3RvY29sVmlvbGF0aW9u ICAgICAgICAgICAgNjUNClZBTFVFICAgQ29ubmVjdF9UZXJtX1JlYXNvbiAg ICAgY2xhc3MyRmF4SGFuZ3VwQ21kICAgICAgICAgICAgICA2Ng0KVkFMVUUg ICBDb25uZWN0X1Rlcm1fUmVhc29uICAgICBoc3RTcGVlZFN3aXRjaFRpbWVv dXQgICAgICAgICAgIDY3DQpWQUxVRQkgIENvbm5lY3RfVGVybV9SZWFzb24J ICB0b29NYW55VW5hY2tlZAkgICAgICAgICAgICAgICAgNjgNClZBTFVFCSAg Q29ubmVjdF9UZXJtX1JlYXNvbgkgIHRpbWVyRXhwaXJlZAkgICAgICAgICAg ICAgICAgNjkNClZBTFVFCSAgQ29ubmVjdF9UZXJtX1JlYXNvbgkgIHQxR2xh cmUJICAgICAgICAgICAgICAgICAgICAgIDcwDQpWQUxVRQkgIENvbm5lY3Rf VGVybV9SZWFzb24JICBwcmlEaWFsb3V0UnFUaW1lb3V0ICAgICAgICAgICAg IDcxDQpWQUxVRQkgIENvbm5lY3RfVGVybV9SZWFzb24JICBhYm9ydEFubGdE c3RPdnJJc2RuCSAgICAgICAgICA3Mg0KVkFMVUUJICBDb25uZWN0X1Rlcm1f UmVhc29uCSAgbm9ybWFsVXNlckNhbGxDbGVhcgkgICAgICAgICAgNzMNClZB TFVFCSAgQ29ubmVjdF9UZXJtX1JlYXNvbgkgIG5vcm1hbFVuc3BlY2lmaWVk CSAgICAgICAgICA3NA0KVkFMVUUJICBDb25uZWN0X1Rlcm1fUmVhc29uCSAg YmVhcmVySW5jb21wYXRpYmlsaXR5CSAgICAgICAgICA3NQ0KVkFMVUUJICBD b25uZWN0X1Rlcm1fUmVhc29uCSAgcHJvdG9jb2xFcnJvckV2ZW50CSAgICAg ICAgICA3Ng0KVkFMVUUJICBDb25uZWN0X1Rlcm1fUmVhc29uCSAgYWJub3Jt YWxEaXNjb25uZWN0CSAgICAgICAgICA3Nw0KVkFMVUUJICBDb25uZWN0X1Rl cm1fUmVhc29uCSAgaW52YWxpZENhdXNlVmFsdWUJICAgICAgICAgIDc4DQoN Cg0KVkFMVUUgICBGYWlsdXJlX3RvX0Nvbm5lY3RfUmVhc29uICAgICAgIGR0 ckRyb3AgICAgICAgICAgICAgICAgIDENClZBTFVFICAgRmFpbHVyZV90b19D b25uZWN0X1JlYXNvbiAgICAgICBlc2NhcGVTZXF1ZW5jZSAgICAgICAgICAy DQpWQUxVRSAgIEZhaWx1cmVfdG9fQ29ubmVjdF9SZWFzb24gICAgICAgYXRo Q29tbWFuZCAgICAgICAgICAgICAgMw0KVkFMVUUgICBGYWlsdXJlX3RvX0Nv bm5lY3RfUmVhc29uICAgICAgIGNhcnJpZXJMb3NzICAgICAgICAgICAgIDQN ClZBTFVFICAgRmFpbHVyZV90b19Db25uZWN0X1JlYXNvbiAgICAgICBpbmFj dGl2aXR5VGltb3V0ICAgICAgICA1DQpWQUxVRSAgIEZhaWx1cmVfdG9fQ29u bmVjdF9SZWFzb24gICAgICAgbW5wSW5jb21wYXRpYmxlICAgICAgICAgNg0K VkFMVUUgICBGYWlsdXJlX3RvX0Nvbm5lY3RfUmVhc29uICAgICAgIHVuZGVm aW5lZCAgICAgICAgICAgICAgIDcNClZBTFVFICAgRmFpbHVyZV90b19Db25u ZWN0X1JlYXNvbiAgICAgICByZW1vdGVQYXNzd29yZCAgICAgICAgICA4DQpW QUxVRSAgIEZhaWx1cmVfdG9fQ29ubmVjdF9SZWFzb24gICAgICAgbGlua1Bh c3N3b3JkICAgICAgICAgICAgOQ0KVkFMVUUgICBGYWlsdXJlX3RvX0Nvbm5l Y3RfUmVhc29uICAgICAgIHJldHJhbnNtaXRMaW1pdCAgICAgICAgIDEwDQpW QUxVRSAgIEZhaWx1cmVfdG9fQ29ubmVjdF9SZWFzb24gICAgICAgbGlua0Rp c2Nvbm5lY3RNc2dSZWMgICAgMTENClZBTFVFICAgRmFpbHVyZV90b19Db25u ZWN0X1JlYXNvbiAgICAgICBub0xvb3BDdXJyZW50ICAgICAgICAgICAxMg0K VkFMVUUgICBGYWlsdXJlX3RvX0Nvbm5lY3RfUmVhc29uICAgICAgIGludmFs aWRTcGVlZCAgICAgICAgICAgIDEzDQpWQUxVRSAgIEZhaWx1cmVfdG9fQ29u bmVjdF9SZWFzb24gICAgICAgdW5hYmxlVG9SZXRyYWluICAgICAgICAgMTQN ClZBTFVFICAgRmFpbHVyZV90b19Db25uZWN0X1JlYXNvbiAgICAgICBtYW5h Z2VtZW50Q29tbWFuZCAgICAgICAxNQ0KVkFMVUUgICBGYWlsdXJlX3RvX0Nv bm5lY3RfUmVhc29uICAgICAgIG5vRGlhbFRvbmUgICAgICAgICAgICAgIDE2 DQpWQUxVRSAgIEZhaWx1cmVfdG9fQ29ubmVjdF9SZWFzb24gICAgICAga2V5 QWJvcnQgICAgICAgICAgICAgICAgMTcNClZBTFVFICAgRmFpbHVyZV90b19D b25uZWN0X1JlYXNvbiAgICAgICBsaW5lQnVzeSAgICAgICAgICAgICAgICAx OA0KVkFMVUUgICBGYWlsdXJlX3RvX0Nvbm5lY3RfUmVhc29uICAgICAgIG5v QW5zd2VyICAgICAgICAgICAgICAgIDE5DQpWQUxVRSAgIEZhaWx1cmVfdG9f Q29ubmVjdF9SZWFzb24gICAgICAgdm9pY2UgICAgICAgICAgICAgICAgICAg MjANClZBTFVFICAgRmFpbHVyZV90b19Db25uZWN0X1JlYXNvbiAgICAgICBu b0Fuc3dlclRvbmUgICAgICAgICAgICAyMQ0KVkFMVUUgICBGYWlsdXJlX3Rv X0Nvbm5lY3RfUmVhc29uICAgICAgIG5vQ2FycmllciAgICAgICAgICAgICAg IDIyDQpWQUxVRSAgIEZhaWx1cmVfdG9fQ29ubmVjdF9SZWFzb24gICAgICAg dW5kZXRlcm1pbmVkICAgICAgICAgICAgMjMNClZBTFVFICAgRmFpbHVyZV90 b19Db25uZWN0X1JlYXNvbiAgICAgICB2NDJTYWJtZVRpbWVvdXQgICAgICAg ICAyNA0KVkFMVUUgICBGYWlsdXJlX3RvX0Nvbm5lY3RfUmVhc29uICAgICAg IHY0MkJyZWFrVGltZW91dCAgICAgICAgIDI1DQpWQUxVRSAgIEZhaWx1cmVf dG9fQ29ubmVjdF9SZWFzb24gICAgICAgdjQyRGlzY29ubmVjdENtZCAgICAg ICAgMjYNClZBTFVFICAgRmFpbHVyZV90b19Db25uZWN0X1JlYXNvbiAgICAg ICB2NDJJZEV4Y2hhbmdlRmFpbCAgICAgICAyNw0KVkFMVUUgICBGYWlsdXJl X3RvX0Nvbm5lY3RfUmVhc29uICAgICAgIHY0MkJhZFNldHVwICAgICAgICAg ICAgIDI4DQpWQUxVRSAgIEZhaWx1cmVfdG9fQ29ubmVjdF9SZWFzb24gICAg ICAgdjQySW52YWxpZENvZGVXb3JkICAgICAgMjkNClZBTFVFICAgRmFpbHVy ZV90b19Db25uZWN0X1JlYXNvbiAgICAgICB2NDJTdHJpbmdUb0xvbmcgICAg ICAgICAzMA0KVkFMVUUgICBGYWlsdXJlX3RvX0Nvbm5lY3RfUmVhc29uICAg ICAgIHY0MkludmFsaWRDb21tYW5kICAgICAgIDMxDQpWQUxVRSAgIEZhaWx1 cmVfdG9fQ29ubmVjdF9SZWFzb24gICAgICAgbm9uZSAgICAgICAgICAgICAg ICAgICAgMzIgICAgICANClZBTFVFICAgRmFpbHVyZV90b19Db25uZWN0X1Jl YXNvbiAgICAgICB2MzJDbGVhcmRvd24gICAgICAgICAgICAzMw0KVkFMVUUg ICBGYWlsdXJlX3RvX0Nvbm5lY3RfUmVhc29uICAgICAgIGRpYWxTZWN1cml0 eSAgICAgICAgICAgIDM0DQpWQUxVRSAgIEZhaWx1cmVfdG9fQ29ubmVjdF9S ZWFzb24gICAgICAgcmVtb3RlQWNjZXNzRGVuaWVkICAgICAgMzUNClZBTFVF ICAgRmFpbHVyZV90b19Db25uZWN0X1JlYXNvbiAgICAgICBsb29wTG9zcyAg ICAgICAgICAgICAgICAzNg0KVkFMVUUgICBGYWlsdXJlX3RvX0Nvbm5lY3Rf UmVhc29uICAgICAgIGRzMFRlYXJkb3duICAgICAgICAgICAgIDM3DQpWQUxV RSAgIEZhaWx1cmVfdG9fQ29ubmVjdF9SZWFzb24gICAgICAgcHJvbXB0Tm90 RW5hYmxlZCAgICAgICAgMzgNClZBTFVFICAgRmFpbHVyZV90b19Db25uZWN0 X1JlYXNvbiAgICAgICBub1Byb21wdGluZ0luU3luYyAgICAgICAzOQ0KVkFM VUUgICBGYWlsdXJlX3RvX0Nvbm5lY3RfUmVhc29uICAgICAgIG5vbkFycU1v ZGUgICAgICAgICAgICAgIDQwDQpWQUxVRSAgIEZhaWx1cmVfdG9fQ29ubmVj dF9SZWFzb24gICAgICAgbW9kZUluY29tcGF0aWJsZSAgICAgICAgNDENClZB TFVFICAgRmFpbHVyZV90b19Db25uZWN0X1JlYXNvbiAgICAgICBub1Byb21w dEluTm9uQVJRICAgICAgICA0Mg0KVkFMVUUgICBGYWlsdXJlX3RvX0Nvbm5l Y3RfUmVhc29uICAgICAgIGRpYWxCYWNrTGluayAgICAgICAgICAgIDQzDQpW QUxVRSAgIEZhaWx1cmVfdG9fQ29ubmVjdF9SZWFzb24gICAgICAgbGlua0Fi b3J0ICAgICAgICAgICAgICAgNDQNClZBTFVFICAgRmFpbHVyZV90b19Db25u ZWN0X1JlYXNvbiAgICAgICBhdXRvcGFzc0ZhaWxlZCAgICAgICAgICA0NQ0K VkFMVUUgICBGYWlsdXJlX3RvX0Nvbm5lY3RfUmVhc29uICAgICAgIHBiR2Vu ZXJpY0Vycm9yICAgICAgICAgIDQ2DQpWQUxVRSAgIEZhaWx1cmVfdG9fQ29u bmVjdF9SZWFzb24gICAgICAgcGJMaW5rRXJyVHhQcmVBY2sgICAgICAgNDcN ClZBTFVFICAgRmFpbHVyZV90b19Db25uZWN0X1JlYXNvbiAgICAgICBwYkxp bmtFcnJUeFRhcmR5QUNLICAgICA0OA0KVkFMVUUgICBGYWlsdXJlX3RvX0Nv bm5lY3RfUmVhc29uICAgICAgIHBiVHJhbnNtaXRCdXNUaW1lb3V0ICAgIDQ5 DQpWQUxVRSAgIEZhaWx1cmVfdG9fQ29ubmVjdF9SZWFzb24gICAgICAgcGJS ZWNlaXZlQnVzVGltZW91dCAgICAgNTANClZBTFVFICAgRmFpbHVyZV90b19D b25uZWN0X1JlYXNvbiAgICAgICBwYkxpbmtFcnJUeFRBTCAgICAgICAgICA1 MQ0KVkFMVUUgICBGYWlsdXJlX3RvX0Nvbm5lY3RfUmVhc29uICAgICAgIHBi TGlua0VyclJ4VEFMICAgICAgICAgIDUyDQpWQUxVRSAgIEZhaWx1cmVfdG9f Q29ubmVjdF9SZWFzb24gICAgICAgcGJUcmFuc21pdE1hc3RlclRpbWVvdXQg NTMNClZBTFVFICAgRmFpbHVyZV90b19Db25uZWN0X1JlYXNvbiAgICAgICBw YkNsb2NrTWlzc2luZyAgICAgICAgICA1NA0KVkFMVUUgICBGYWlsdXJlX3Rv X0Nvbm5lY3RfUmVhc29uICAgICAgIHBiUmVjZWl2ZWRMc1doaWxlTGlua1Vw IDU1DQpWQUxVRSAgIEZhaWx1cmVfdG9fQ29ubmVjdF9SZWFzb24gICAgICAg cGJPdXRPZlNlcXVlbmNlRnJhbWUgICAgNTYNClZBTFVFICAgRmFpbHVyZV90 b19Db25uZWN0X1JlYXNvbiAgICAgICBwYkJhZEZyYW1lICAgICAgICAgICAg ICA1Nw0KVkFMVUUgICBGYWlsdXJlX3RvX0Nvbm5lY3RfUmVhc29uICAgICAg IHBiQWNrV2FpdFRpbWVvdXQgICAgICAgIDU4DQpWQUxVRSAgIEZhaWx1cmVf dG9fQ29ubmVjdF9SZWFzb24gICAgICAgcGJSZWNlaXZlZEFja1NlcUVyciAg ICAgNTkNClZBTFVFICAgRmFpbHVyZV90b19Db25uZWN0X1JlYXNvbiAgICAg ICBwYlJlY2VpdmVPdnJmbHdSTlJGYWlsICA2MA0KVkFMVUUgICBGYWlsdXJl X3RvX0Nvbm5lY3RfUmVhc29uICAgICAgIHBiUmVjZWl2ZU1zZ0J1Zk92cmZs dyAgIDYxDQpWQUxVRSAgIEZhaWx1cmVfdG9fQ29ubmVjdF9SZWFzb24gICAg ICAgcmN2ZEdhdGV3YXlEaXNjQ21kICAgICAgNjINClZBTFVFICAgRmFpbHVy ZV90b19Db25uZWN0X1JlYXNvbiAgICAgICB0b2tlblBhc3NpbmdUaW1lb3V0 ICAgICA2Mw0KVkFMVUUgICBGYWlsdXJlX3RvX0Nvbm5lY3RfUmVhc29uICAg ICAgIGRzcEludGVycnVwdFRpbWVvdXQgICAgIDY0DQpWQUxVRSAgIEZhaWx1 cmVfdG9fQ29ubmVjdF9SZWFzb24gICAgICAgbW5wUHJvdG9jb2xWaW9sYXRp b24gICAgNjUNClZBTFVFICAgRmFpbHVyZV90b19Db25uZWN0X1JlYXNvbiAg ICAgICBjbGFzczJGYXhIYW5ndXBDbWQgICAgICA2Ng0KVkFMVUUgICBGYWls dXJlX3RvX0Nvbm5lY3RfUmVhc29uICAgICAgIGhzdFNwZWVkU3dpdGNoVGlt ZW91dCAgIDY3DQpWQUxVRQkgIEZhaWx1cmVfdG9fQ29ubmVjdF9SZWFzb24J ICAgIHRvb01hbnlVbmFja2VkCSAgICA2OA0KVkFMVUUJICBGYWlsdXJlX3Rv X0Nvbm5lY3RfUmVhc29uICAgICAgIHRpbWVyRXhwaXJlZAkgICAgICAgICAg NjkNClZBTFVFCSAgRmFpbHVyZV90b19Db25uZWN0X1JlYXNvbgkgICAgdDFH bGFyZQkgICAgICAgICAgICAgICAgNzANClZBTFVFCSAgRmFpbHVyZV90b19D b25uZWN0X1JlYXNvbgkgICAgcHJpRGlhbG91dFJxVGltZW91dAkgICAgNzEN ClZBTFVFCSAgRmFpbHVyZV90b19Db25uZWN0X1JlYXNvbgkgICAgYWJvcnRB bmxnRHN0T3ZySXNkbgkgICAgNzINClZBTFVFCSAgRmFpbHVyZV90b19Db25u ZWN0X1JlYXNvbgkgICAgbm9ybWFsVXNlckNhbGxDbGVhcgkgICAgNzMNClZB TFVFCSAgRmFpbHVyZV90b19Db25uZWN0X1JlYXNvbgkgICAgbm9ybWFsVW5z cGVjaWZpZWQJICAgIDc0DQpWQUxVRQkgIEZhaWx1cmVfdG9fQ29ubmVjdF9S ZWFzb24JICAgIGJlYXJlckluY29tcGF0aWJpbGl0eSAgIDc1DQpWQUxVRQkg IEZhaWx1cmVfdG9fQ29ubmVjdF9SZWFzb24JICAgIHByb3RvY29sRXJyb3JF dmVudAkgICAgNzYNClZBTFVFCSAgRmFpbHVyZV90b19Db25uZWN0X1JlYXNv bgkgICAgYWJub3JtYWxEaXNjb25uZWN0CSAgICA3Nw0KVkFMVUUJICBGYWls dXJlX3RvX0Nvbm5lY3RfUmVhc29uCSAgICBpbnZhbGlkQ2F1c2VWYWx1ZQkg ICAgNzgNCg0KDQojICAgICAgIFNpbXBsaWZpZWRfTU5QX0xldmVscyBWYWx1 ZXMNClZBTFVFICAgU2ltcGxpZmllZF9NTlBfTGV2ZWxzICAgbm9uZSAgICAg ICAgICAgIDENClZBTFVFICAgU2ltcGxpZmllZF9NTlBfTGV2ZWxzICAgbW5w TGV2ZWwzICAgICAgIDINClZBTFVFICAgU2ltcGxpZmllZF9NTlBfTGV2ZWxz ICAgbW5wTGV2ZWw0ICAgICAgIDMNClZBTFVFICAgU2ltcGxpZmllZF9NTlBf TGV2ZWxzICAgY2NpdHRWNDIgICAgICAgIDQNClZBTFVFICAgU2ltcGxpZmll ZF9NTlBfTGV2ZWxzICAgdXNSb2JvdGljc0hTVCAgIDUNClZBTFVFICAgU2lt cGxpZmllZF9NTlBfTGV2ZWxzICAgc3luY2hyb25vdXNOb25lIDYNClZBTFVF ICAgU2ltcGxpZmllZF9NTlBfTGV2ZWxzICAgbW5wTGV2ZWwyICAgICAgIDcN ClZBTFVFICAgU2ltcGxpZmllZF9NTlBfTGV2ZWxzICAgbW5wMTAgICAgICAg ICAgIDgNClZBTFVFICAgU2ltcGxpZmllZF9NTlBfTGV2ZWxzICAgdjQyRXRj ICAgICAgICAgIDkNClZBTFVFCSAgU2ltcGxpZmllZF9NTlBfTGV2ZWxzCSAg bW5wMTBFYwkgICAgICAxMA0KVkFMVUUJICBTaW1wbGlmaWVkX01OUF9MZXZl bHMJICBsYXBtRWMJICAgICAgMTENClZBTFVFCSAgU2ltcGxpZmllZF9NTlBf TGV2ZWxzCSAgdjQyRXRjMgkgICAgICAxMg0KVkFMVUUJICBTaW1wbGlmaWVk X01OUF9MZXZlbHMJICBjY2l0dFY0MlNSRUoJMTMNClZBTFVFICAgU2ltcGxp ZmllZF9NTlBfTGV2ZWxzICAgcGlhZnMgICAgICAgICAgIDE0DQoNCiMgICAg ICAgU2ltcGxpZmllZF9WNDJiaXNfVXNhZ2UgVmFsdWVzDQpWQUxVRSAgIFNp bXBsaWZpZWRfVjQyYmlzX1VzYWdlIG5vbmUgICAgICAgICAgICAxDQpWQUxV RSAgIFNpbXBsaWZpZWRfVjQyYmlzX1VzYWdlIGNjaXR0VjQyYmlzICAgICAy DQpWQUxVRSAgIFNpbXBsaWZpZWRfVjQyYmlzX1VzYWdlIG1ucExldmVsNSAg ICAgICAzDQoNClZBTFVFICAgRXF1YWxpemF0aW9uX1R5cGUgICAgICAgICAg ICAgICBMb25nICAgICAgICAgICAgMQ0KVkFMVUUgICBFcXVhbGl6YXRpb25f VHlwZSAgICAgICAgICAgICAgIFNob3J0ICAgICAgICAgICAyDQoNCg0KVkFM VUUgICBGYWxsYmFja19FbmFibGVkICAgICAgICAgICAgICAgIERpc2FibGVk ICAgICAgICAxDQpWQUxVRSAgIEZhbGxiYWNrX0VuYWJsZWQgICAgICAgICAg ICAgICAgRW5hYmxlZCAgICAgICAgIDINCg0KDQpWQUxVRSAgIEJhY2tfQ2hh bm5lbF9EYXRhX1JhdGUgICAgICAgICAgNDUwQlBTICAgICAgICAgIDENClZB TFVFICAgQmFja19DaGFubmVsX0RhdGFfUmF0ZSAgICAgICAgICAzMDBCUFMg ICAgICAgICAgMg0KVkFMVUUgICBCYWNrX0NoYW5uZWxfRGF0YV9SYXRlICAg ICAgICAgIE5vbmUgICAgICAgICAgICAzDQoNClZBTFVFICAgRGV2aWNlX0Nv bm5lY3RlZF9UbyAgICAgICAgICAgICBOb25lICAgICAgICAgICAgMQ0KVkFM VUUgICBEZXZpY2VfQ29ubmVjdGVkX1RvICAgICAgICAgICAgIGlzZG5HYXRl d2F5ICAgICAyDQpWQUxVRSAgIERldmljZV9Db25uZWN0ZWRfVG8gICAgICAg ICAgICAgcXVhZE1vZGVtICAgICAgIDMNCg0KVkFMVUUgICBDYWxsX0V2ZW50 X0NvZGUgICAgICAgICAgICAgICAgIG5vdFN1cHBvcnRlZCAgICAgICAgICAx DQpWQUxVRSAgIENhbGxfRXZlbnRfQ29kZSAgICAgICAgICAgICAgICAgc2V0 dXAgICAgICAgICAgICAgICAgIDINClZBTFVFICAgQ2FsbF9FdmVudF9Db2Rl ICAgICAgICAgICAgICAgICB1c3JTZXR1cCAgICAgICAgICAgICAgMw0KVkFM VUUgICBDYWxsX0V2ZW50X0NvZGUgICAgICAgICAgICAgICAgIHRlbGNvRGlz Y29ubmVjdCAgICAgICA0DQpWQUxVRSAgIENhbGxfRXZlbnRfQ29kZSAgICAg ICAgICAgICAgICAgdXNyRGlzY29ubmVjdCAgICAgICAgIDUNClZBTFVFICAg Q2FsbF9FdmVudF9Db2RlICAgICAgICAgICAgICAgICBub0ZyZWVNb2RlbSAg ICAgICAgICAgNg0KVkFMVUUgICBDYWxsX0V2ZW50X0NvZGUgICAgICAgICAg ICAgICAgIG1vZGVtc05vdEFsbG93ZWQgICAgICA3DQpWQUxVRSAgIENhbGxf RXZlbnRfQ29kZSAgICAgICAgICAgICAgICAgbW9kZW1zUmVqZWN0Q2FsbCAg ICAgIDgNClZBTFVFICAgQ2FsbF9FdmVudF9Db2RlICAgICAgICAgICAgICAg ICBtb2RlbVNldHVwVGltZW91dCAgICAgOQ0KVkFMVUUgICBDYWxsX0V2ZW50 X0NvZGUgICAgICAgICAgICAgICAgIG5vRnJlZUlHVyAgICAgICAgICAgICAx MA0KVkFMVUUgICBDYWxsX0V2ZW50X0NvZGUgICAgICAgICAgICAgICAgIGln d1JlamVjdENhbGwgICAgICAgICAxMQ0KVkFMVUUgICBDYWxsX0V2ZW50X0Nv ZGUgICAgICAgICAgICAgICAgIGlnd1NldHVwVGltZW91dCAgICAgICAxMg0K VkFMVUUgICBDYWxsX0V2ZW50X0NvZGUgICAgICAgICAgICAgICAgIG5vRnJl ZVRkbXRzICAgICAgICAgICAxMw0KVkFMVUUgICBDYWxsX0V2ZW50X0NvZGUg ICAgICAgICAgICAgICAgIGJjUmVqZWN0ICAgICAgICAgICAgICAxNA0KVkFM VUUgICBDYWxsX0V2ZW50X0NvZGUgICAgICAgICAgICAgICAgIGllUmVqZWN0 ICAgICAgICAgICAgICAxNQ0KVkFMVUUgICBDYWxsX0V2ZW50X0NvZGUgICAg ICAgICAgICAgICAgIGNoaWRSZWplY3QgICAgICAgICAgICAxNg0KVkFMVUUg ICBDYWxsX0V2ZW50X0NvZGUgICAgICAgICAgICAgICAgIHByb2dSZWplY3Qg ICAgICAgICAgICAxNw0KVkFMVUUgICBDYWxsX0V2ZW50X0NvZGUgICAgICAg ICAgICAgICAgIGNhbGxpbmdQYXJ0eVJlamVjdCAgICAxOA0KVkFMVUUgICBD YWxsX0V2ZW50X0NvZGUgICAgICAgICAgICAgICAgIGNhbGxlZFBhcnR5UmVq ZWN0ICAgICAxOQ0KVkFMVUUgICBDYWxsX0V2ZW50X0NvZGUgICAgICAgICAg ICAgICAgIGJsb2NrZWQgICAgICAgICAgICAgICAyMA0KVkFMVUUgICBDYWxs X0V2ZW50X0NvZGUgICAgICAgICAgICAgICAgIGFuYWxvZ0Jsb2NrZWQgICAg ICAgICAyMQ0KVkFMVUUgICBDYWxsX0V2ZW50X0NvZGUgICAgICAgICAgICAg ICAgIGRpZ2l0YWxCbG9ja2VkICAgICAgICAyMg0KVkFMVUUgICBDYWxsX0V2 ZW50X0NvZGUgICAgICAgICAgICAgICAgIG91dE9mU2VydmljZSAgICAgICAg ICAyMw0KVkFMVUUgICBDYWxsX0V2ZW50X0NvZGUgICAgICAgICAgICAgICAg IGJ1c3kgICAgICAgICAgICAgICAgICAyNA0KVkFMVUUgICBDYWxsX0V2ZW50 X0NvZGUgICAgICAgICAgICAgICAgIGNvbmdlc3Rpb24gICAgICAgICAgICAy NQ0KVkFMVUUgICBDYWxsX0V2ZW50X0NvZGUgICAgICAgICAgICAgICAgIHBy b3RvY29sRXJyb3IgICAgICAgICAyNiANClZBTFVFICAgQ2FsbF9FdmVudF9D b2RlICAgICAgICAgICAgICAgICBub0ZyZWVCY2hhbm5lbCAgICAgICAgMjcN ClZBTFVFICAgQ2FsbF9FdmVudF9Db2RlICAgICAgICAgICAgICAgICBpbk91 dENhbGxDb2xsaXNpb24gICAgMjgNClZBTFVFICAgQ2FsbF9FdmVudF9Db2Rl ICAgICAgICAgICAgICAgICBpbkNhbGxBcnJpdmFsCSAgICAgICAgMjkNClZB TFVFICAgQ2FsbF9FdmVudF9Db2RlICAgICAgICAgICAgICAgICBvdXRDYWxs QXJyaXZhbAkgIDMwDQpWQUxVRSAgIENhbGxfRXZlbnRfQ29kZSAgICAgICAg ICAgICAgICAgaW5DYWxsQ29ubmVjdAkgICAgICAgIDMxDQpWQUxVRSAgIENh bGxfRXZlbnRfQ29kZSAgICAgICAgICAgICAgICAgb3V0Q2FsbENvbm5lY3QJ ICAzMg0KDQoNCiMjIyMjIyMjIyMjIyBTZWN1cml0eSBPbmx5ICMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIw0KDQojIyMjIFRoZXNlIGhhdmUgYmVl biBhZGRlZCBieSBVUyBSb2JvdGljcyBmb3IgZGlhbCBzZWN1cml0eQ0KIyMj IyBFYXJsaWVyIHZlcnNpb24gb2YgdGhlIFJBRElVUyBkcmFmdCBzdGF0ZWQ6 DQojIyMjDQojIyMjIEJlbG93IDE5MiBhcmUgImFzc2lnbmVkIiBudW1iZXJz DQojIyMjIDE5Mi0yMjMgYXJlIHJlc2VydmVkIGZvciBleHBlcmltZW50YWwg dXNlDQojIyMjIDIyNC0yNDAgZm9yIGltcGxlbWVudGF0aW9uLXNwZWNpZmlj IHVzZXINCiMjIyMgMjQxLTI1NSBhcmUgcmVzZXJ2ZWQgYW5kIHNob3VsZCBu b3QgYmUgdXNlZA0KIyMjIw0KIyMjIyAgVXNlZCBieSB0aGUgTk1DIENhcmQN CkFUVFJJQlVURSAgICAgICBVc2VyX0dyb3VwX05hbWUgICAgICAgICAyMjMg ICAgIHN0cmluZw0KQVRUUklCVVRFICAgICAgIERpYWxfSW5fU2VjX01vZGUg ICAgICAgIDIyNCAgICAgaW50ZWdlcg0KQVRUUklCVVRFICAgICAgIFJlcV9E Yl9NZG1fU2VsICAgICAgICAgIDIyNSAgICAgaW50ZWdlcg0KQVRUUklCVVRF ICAgICAgIFJlcV9EYl9Mb2dpbl9WYWxpZCAgICAgIDIyNiAgICAgaW50ZWdl cg0KQVRUUklCVVRFICAgICAgIERpYWxiYWNrX0dyb3VwX05hbWVzICAgIDIy NyAgICAgc3RyaW5nDQpBVFRSSUJVVEUgICAgICAgRGlhbF9Jbl9DYWxsX1Jl c3QgICAgICAgMjI4ICAgICBzdHJpbmcNCkFUVFJJQlVURSAgICAgICBEaWFs X091dF9DYWxsX1Jlc3QgICAgICAyMjkgICAgIHN0cmluZw0KQVRUUklCVVRF ICAgICAgIExvZ2luc19CZWZvcmVfQmxhY2tsaXN0IDIzMCAgICAgaW50ZWdl cg0KQVRUUklCVVRFICAgICAgIEZhaWxlZF9Mb2dpbnMgICAgICAgICAgIDIz MSAgICAgaW50ZWdlcg0KQVRUUklCVVRFICAgICAgIEFsbG93ZWRfREJfTW9k ZW1zICAgICAgIDIzMyAgICAgc3RyaW5nDQoNCiMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIw0KIw0K IyBQc2V1ZG8gYXR0cmlidXRlcyB1c2VkIGJ5IHRoZSBzY3JpcHQgYmFzZWQN CiMgU2VjdXJpdHkvQWNjb3VudGluZyBTZXJ2ZXIgdG8gaWRlbnRpZnkgUkFE SVVTIHBhY2tldCB0eXBlcy4NCiMNCkFUVFJJQl9OTUMgICAgICAgIFJlcXVl c3RfVHlwZSAgICAgICAgICAgIDB4RjAwMSAgICBpbnRlZ2VyDQoNClZBTFVF ICAgIFJlcXVlc3RfVHlwZSAgICBBY2Nlc3NfUmVxdWVzdCAgICAgICAgICAg IDENClZBTFVFICAgIFJlcXVlc3RfVHlwZSAgICBBY2Nlc3NfQWNjZXB0ICAg ICAgICAgICAgIDINClZBTFVFICAgIFJlcXVlc3RfVHlwZSAgICBBY2Nlc3Nf UmVqZWN0ICAgICAgICAgICAgIDMNClZBTFVFICAgIFJlcXVlc3RfVHlwZSAg ICBBY2NvdW50aW5nX1JlcXVlc3QgICAgICAgIDQNClZBTFVFICAgIFJlcXVl c3RfVHlwZSAgICBBY2NvdW50aW5nX1Jlc3BvbnNlICAgICAgIDUNCg0KIyBU aGUgbmV4dCB0aHJlZSBub24gc3RhbmRhcmQgcGFja2V0IHR5cGVzIGFyZSB1 c2VkIGJ5DQojIFVTIFJvYm90aWNzIFNlY3VyaXR5L0FjY291bnRpbmcgU2Vy dmVyDQpWQUxVRSAgICBSZXF1ZXN0X1R5cGUgICAgQWNjZXNzX1Bhc3N3b3Jk X0NoYW5nZSAgICA3DQpWQUxVRSAgICBSZXF1ZXN0X1R5cGUgICAgQWNjZXNz X1Bhc3N3b3JkX0FjayAgICAgICA4DQpWQUxVRSAgICBSZXF1ZXN0X1R5cGUg ICAgQWNjZXNzX1Bhc3N3b3JkX1JlamVjdCAgICA5DQoNClZBTFVFICAgIFJl cXVlc3RfVHlwZSAgICBBY2Nlc3NfQ2hhbGxlbmdlICAgICAgICAgIDExDQpW QUxVRSAgICBSZXF1ZXN0X1R5cGUgICAgU3RhdHVzX1NlcnZlciAgICAgICAg ICAgICAxMg0KVkFMVUUgICAgUmVxdWVzdF9UeXBlICAgIFN0YXR1c19DbGll bnQgICAgICAgICAgICAgMTMNCg0KIyBOb24gc3RhbmRhcmQgcGFja2V0IHR5 cGVzIHVzZWQgYnkgTmV0U2VydmVyIHRvIGltcGxlbWVudA0KIyByZXNvdXJj ZSBtYW5hZ2VtZW50IGFuZCBOQVMgcmVib290IGNvbmRpdGlvbnMNClZBTFVF ICAgIFJlcXVlc3RfVHlwZSAgICBSZXNvdXJjZV9GcmVlX1JlcXVlc3QgICAg IDIxDQpWQUxVRSAgICBSZXF1ZXN0X1R5cGUgICAgUmVzb3VyY2VfRnJlZV9S ZXNwb25zZSAgICAyMg0KVkFMVUUgICAgUmVxdWVzdF9UeXBlICAgIFJlc291 cmNlX1F1ZXJ5X1JlcXVlc3QgICAgMjMNClZBTFVFICAgIFJlcXVlc3RfVHlw ZSAgICBSZXNvdXJjZV9RdWVyeV9SZXNwb25zZSAgIDI0DQpWQUxVRSAgICBS ZXF1ZXN0X1R5cGUgICAgRGlzY29ubmVjdF9Vc2VyICAJCSAgIDI1DQpWQUxV RSAgICBSZXF1ZXN0X1R5cGUgICAgTkFTX1JlYm9vdF9SZXF1ZXN0ICAJICAg MjYNClZBTFVFICAgIFJlcXVlc3RfVHlwZSAgICBOQVNfUmVib290X1Jlc3Bv bnNlICAJICAgMjcNCg0KIyBUaGlzIHZhbHVlIGlzIHVzZWQgZm9yIFRhY2Fj cyBQbHVzIHRyYW5zbGF0aW9uDQpWQUxVRSAgICBSZXF1ZXN0X1R5cGUgICAg VGFjYWNzX01lc3NhZ2UgICAgICAgICAgICAyNTMNClZBTFVFICAgIFJlcXVl c3RfVHlwZSAgICBSZXNlcnZlZCAgICAgICAgICAgICAgICAgIDI1NQ0KDQpW QUxVRSAgIFJlcV9EYl9NZG1fU2VsICAgICAgICBObyAgICAgICAgICAgICAg ICAgICAwDQpWQUxVRSAgIFJlcV9EYl9NZG1fU2VsICAgICAgICBZZXMgICAg ICAgICAgICAgICAgICAxDQoNCg0KVkFMVUUgICBSZXFfRGJfTG9naW5fVmFs aWQgICAgTm8gICAgICAgICAgICAgICAgICAgMA0KVkFMVUUgICBSZXFfRGJf TG9naW5fVmFsaWQgICAgWWVzICAgICAgICAgICAgICAgICAgMQ0KDQpWQUxV RSAgIERpYWxfSW5fU2VjX01vZGUgICAgUGFzc19UaHJvdWdoICAgICAgICAg ICAwDQpWQUxVRSAgIERpYWxfSW5fU2VjX01vZGUgICAgRGlhbGJhY2tfRW50 ZXJlZCAgICAgICAxDQpWQUxVRSAgIERpYWxfSW5fU2VjX01vZGUgICAgRGlh bGJhY2tfU3RvcmVkICAgICAgICAyDQoNClZBTFVFICAgTkFTX1BvcnRfVHlw ZSAgICAgICAgIEFzeW5jICAgICAgICAgICAgICAgIDANClZBTFVFICAgTkFT X1BvcnRfVHlwZSAgICAgICAgIFN5bmMgICAgICAgICAgICAgICAgIDENClZB TFVFICAgTkFTX1BvcnRfVHlwZSAgICAgICAgIElTRE5fU3luYyAgICAgICAg ICAgIDINClZBTFVFICAgTkFTX1BvcnRfVHlwZSAgICAgICAgIElTRE5fQXN5 bmNfVl8xMjAgICAgIDMNClZBTFVFICAgTkFTX1BvcnRfVHlwZSAgICAgICAg IElTRE5fQXN5bmNfVl8xMTAgICAgIDQNClZBTFVFICAgTkFTX1BvcnRfVHlw ZSAgICAgICAgIFZpcnR1YWwgICAgICAgICAgICAgIDUNCg0KVkFMVUUgICBQ cm9tcHQJCQlOb19FY2hvCQkgICAwDQpWQUxVRSAgIFByb21wdAkJCUVjaG8J CQkgICAxICAgDQoNClZBTFVFICAgQVJBUF9ab25lX0FjY2VzcyAgICAgIGRl ZmF1bHRfem9uZV9vbmx5ICAgICAgMQ0KVkFMVUUgICBBUkFQX1pvbmVfQWNj ZXNzICAgICAgem9uZV9maWx0ZXJfaW5jbHVzaXZlICAyDQpWQUxVRSAgIEFS QVBfWm9uZV9BY2Nlc3MgICAgICB6b25lX2ZpbHRlcl9leGNsdXNpdmUgIDQN ClZBTFVFCVBXX0ZyYW1lZF9Sb3V0aW5nX1YyCU9mZgkJCQkJMAkJCQkNClZB TFVFCVBXX0ZyYW1lZF9Sb3V0aW5nX1YyCU9uCQkJCQkxCQkJCQ0KDQpWQUxV RQlTeXNsb2dfVGFwCQkJCU9mZgkJCQkJMA0KVkFMVUUJU3lzbG9nX1RhcAkJ CQlSYXcJCQkJCTENClZBTFVFCVN5c2xvZ19UYXAJCQkJRnJhbWVkCQkJCTIN Cg0KIw0KIyBUQUNBQ1MgUGx1cyBpbXBsZW1lbnRhdGlvbi4gIFRoZSB2YWx1 ZXMgZ2l2ZW4gYXJlIHJlYWxseSBvZmZzZXRzDQojIGludG8gYSBmdW5jdGlv biB0YWJsZSwgaW5kaWNhdGluZyBob3cgdG8gaGFuZGxlIGEgZ2l2ZW4gZmll bGQuDQojIEZvciBleGFtcGxlLCB0byBoYW5kbGUgdGhlIGZpZWxkICdTdGFy dF9TZXJ2aWNlJywgdXNlIGZ1bmN0aW9uDQojIDMuDQojDQojIFRoZSBudW1i ZXIgcHJlZml4IG9uIHNvbWUgbmFtZXMgaXMgbmVlZGVkIHRvIGluc3VyZSBh bHBoYWJldGljYWwNCiMgdXNhZ2UuKEluIG9yZGVyIHRvIGluc3VyZSB0aWdo dCBwYWNraW5nIG9mIG11bHRpcGxlIHZhcmlhYmxlIGxlbmd0aA0KIyBmaWVs ZHMsIHRoZSBmaWVsZHMgbXVzdCBiZSBpbnNlcnRlZCBpbiBvcmRlciwgaGVu Y2UsIGFscGhhYmV0aWNhbCkNCiMNCkFUVFJJQl9UQUNBQ1MgICBUYWNfQXR0 cmliICAgICAgICAgICAgICAweEZGMDAgICAgICBpbnRlZ2VyDQoNCiMgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgVGFjYWNzKyBGaWVsZCBO YW1lICAgICAgICAgICBGdW5jdGlvbiAjDQojICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIC0tLS0tLS0tLS0tLS0tLS0tLSAgICAgICAgICAg LS0tLS0tLS0tLQ0KVEFDQUNTX1ZBTFVFICAgVGFjX0F0dHJpYiAgICAgICAg ICBTdGFydF9BY3Rpb24gICAgICAgICAgICAgICAgIDANClRBQ0FDU19WQUxV RSAgIFRhY19BdHRyaWIgICAgICAgICAgU3RhcnRfUHJpdl9MdmwgICAgICAg ICAgICAgICAxDQpUQUNBQ1NfVkFMVUUgICBUYWNfQXR0cmliICAgICAgICAg IFN0YXJ0X0F1dGhlbl9UeXBlICAgICAgICAgICAgMg0KVEFDQUNTX1ZBTFVF ICAgVGFjX0F0dHJpYiAgICAgICAgICBTdGFydF9TZXJ2aWNlICAgICAgICAg ICAgICAgIDMNClRBQ0FDU19WQUxVRSAgIFRhY19BdHRyaWIgICAgICAgICAg MTFTdGFydF9Vc2VyICAgICAgICAgICAgICAgICA5IA0KVEFDQUNTX1ZBTFVF ICAgVGFjX0F0dHJpYiAgICAgICAgICAxMlN0YXJ0X1BvcnQgICAgICAgICAg ICAgICAgIDkNClRBQ0FDU19WQUxVRSAgIFRhY19BdHRyaWIgICAgICAgICAg MTNTdGFydF9SZW1fQWRkciAgICAgICAgICAgICA5DQpUQUNBQ1NfVkFMVUUg ICBUYWNfQXR0cmliICAgICAgICAgIENvbnRpbnVlX0ZsYWdzICAgICAgICAg ICAgICAgNA0KVEFDQUNTX1ZBTFVFICAgVGFjX0F0dHJpYiAgICAgICAgICAx MUNvbnRpbnVlX1VzZXJfTXNnICAgICAgICAgIDEwDQpUQUNBQ1NfVkFMVUUg ICBUYWNfQXR0cmliICAgICAgICAgIDEyQ29udGludWVfRGF0YSAgICAgICAg ICAgICAgMTANClRBQ0FDU19WQUxVRSAgIFRhY19BdHRyaWIgICAgICAgICAg QXV0aFJlcXVlc3RfQXV0aGVuX01ldGhvZCAgICAwDQpUQUNBQ1NfVkFMVUUg ICBUYWNfQXR0cmliICAgICAgICAgIEF1dGhSZXF1ZXN0X1ByaXZfTHZsICAg ICAgICAgMQ0KVEFDQUNTX1ZBTFVFICAgVGFjX0F0dHJpYiAgICAgICAgICBB dXRoUmVxdWVzdF9BdXRoZW5fVHlwZSAgICAgIDINClRBQ0FDU19WQUxVRSAg IFRhY19BdHRyaWIgICAgICAgICAgQXV0aFJlcXVlc3RfQXV0aGVuX1NlcnZp Y2UgICAzDQpUQUNBQ1NfVkFMVUUgICBUYWNfQXR0cmliICAgICAgICAgIDEx QXV0aFJlcXVlc3RfVXNlciAgICAgICAgICAgMTENClRBQ0FDU19WQUxVRSAg IFRhY19BdHRyaWIgICAgICAgICAgMTJBdXRoUmVxdWVzdF9Qb3J0ICAgICAg ICAgICAxMQ0KVEFDQUNTX1ZBTFVFICAgVGFjX0F0dHJpYiAgICAgICAgICAx M0F1dGhSZXF1ZXN0X1JlbV9BZGRyICAgICAgIDExDQpUQUNBQ1NfVkFMVUUg ICBUYWNfQXR0cmliICAgICAgICAgIEF1dGhSZXF1ZXN0X0NtZCAgICAgICAg ICAgICAgMTENClRBQ0FDU19WQUxVRSAgIFRhY19BdHRyaWIgICAgICAgICAg QXV0aFJlcXVlc3RfU2VydmljZSAgICAgICAgICAxMQ0KDQo= --416219727-215727185-873979618=:9012--

Garry Shtern said once upon a time: >If for instance a static ip user logs into tc1, then disconnects and >instantenously reconnects to tc2, he won't be able to go anywhere until the >information in my cisco's rip tables get wiped out about tc1s route. What >I do not understand is why doesn't tc2 send the rip packet on the network >telling cisco to route the ip address to it as soon as the person connects. > To overcome that problem, I have enable both broadcast and listen routing >on the net0 interface. However, it seems like a band-aid to the problem >and not a real solution. I have called USR tech support which were not of >much use. > >If anyone else has that problem and figured out a solution, please let me >know. Thanks. I ran around circles with Cisco on this. The problem exists in the "holddown" for RIP on a Cisco. There is no way eliminate it. By changing the RIP timers, you can minimize it: timers basic 30 90 0 90 Yet it will still initiate a holddown of around 30 seconds in this case. I pleaded with Cisco to come out with a way to eliminate it, but they felt that they were wiser than I and essentially ignored my suggestion. What is odd is that you can get rid of holddown for EIGRP. So Cisco feels that their own protocol is deserving of this treatment, but not others. The only solution I'm looking for in the future is OSPF from USR.

Garry Shtern said once upon a time: >Btw, did you enable Proxy ARP on your tcs? Because at one point during the >conversation with tech support, they suggested using proxy ARP for routing. > I didn't find it much useful, since I would have to flush the ARP tables >every 30 seconds on the CISCO in order to use this approach and that >doesn't sound too good. That and the fact that you'd need to setup statics for all your subnet sizes. We're running subnets in the jillions here, and RIPv2 is the only option for us with USR.

Garry Shtern said once upon a time: >Hmm.. I will try that.. Also, isn't there a sleep time as the 5th parameter >in IOS 11.2? I set that to 300 which seems to work fine. Otherwise, it >seems as though RIP process takes a lot of CPU time on my 7206. What does the sleep timer do? RIP takes a huge amount of time on my 7000, and I wish there was an easy way to minimize it.

Garry Shtern said once upon a time: > >At 03:35 PM 9/11/97 -0400, Jeff Mcadams wrote: >> >>RIPV2 also adds the ability to deal with classless addressing (ie, >>204.255.229.33/27) > >How exactly do you enable ripv2 on total controls? RIPv2 is only supported in 3.4.x and higher. To use it enter these commands in your netserver: set ripv2 on set net0 routing broadcast The second command may be different if you want your netserver to listen to routes, which usually isn't the case with stub networks.

Just a question for you since I really don;t know Cisco's but I know BayNetworks..RIP2 is available and the netserver is able to also use it why not try that? as it is supposed to be faster than RIP1 maybe they did not install that holddown on that one...??? >Garry Shtern said once upon a time: > >>If for instance a static ip user logs into tc1, then disconnects and >>instantenously reconnects to tc2, he won't be able to go anywhere until the >>information in my cisco's rip tables get wiped out about tc1s route. What >>I do not understand is why doesn't tc2 send the rip packet on the network >>telling cisco to route the ip address to it as soon as the person connects. >> To overcome that problem, I have enable both broadcast and listen routing >>on the net0 interface. However, it seems like a band-aid to the problem >>and not a real solution. I have called USR tech support which were not of >>much use. >> >>If anyone else has that problem and figured out a solution, please let me >>know. Thanks. > >I ran around circles with Cisco on this. The problem exists in the >"holddown" for RIP on a Cisco. There is no way eliminate it. By changing >the RIP timers, you can minimize it: > > timers basic 30 90 0 90 > >Yet it will still initiate a holddown of around 30 seconds in this case. I >pleaded with Cisco to come out with a way to eliminate it, but they felt >that they were wiser than I and essentially ignored my suggestion. > >What is odd is that you can get rid of holddown for EIGRP. So Cisco feels >that their own protocol is deserving of this treatment, but not others. > >The only solution I'm looking for in the future is OSPF from USR. Brian Trader Iowa Network Services WAN Technician 515-830-0494

> If for instance a static ip user logs into tc1, then disconnects and > instantenously reconnects to tc2, he won't be able to go anywhere until the > information in my cisco's rip tables get wiped out about tc1s route. What > I do not understand is why doesn't tc2 send the rip packet on the network > telling cisco to route the ip address to it as soon as the person connects. > To overcome that problem, I have enable both broadcast and listen routing > on the net0 interface. However, it seems like a band-aid to the problem > and not a real solution. I have called USR tech support which were not of > much use. I run broadcast only. I had some problems with the USR TC's listening to eachothers network routes and getting things all screwed up. Brian > > If anyone else has that problem and figured out a solution, please let me > know. Thanks. > > > > Garry Shtern shterng@akula.com > Akula Communications (212) 292-8892 > /-------------------------- signal@shreve.net -----------------------------\ | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | | Systems Administrator | Perl, Linux | Web hosting, online stores, | | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | | 89 CRX, Akimoto intake, DC |-=*:Quake:*=-| http://www.shreve.net/ | | headers, Eurosport exhaust |LordSignal/SN| Quake server: 208.206.76.3 | \-------------------------- 318-222-2638 x109 -----------------------------/

Hello, I have the following setup and I am trying to figure out the best way of dealing with the situation. I have 2 total control hubs, each of them has a pool of 48 ip addresses. I have them setup to read all the authentication information from merit radius server. In addition, I have static ip users which get assigned the same ip address every time they login. However, this is the problem. If for instance a static ip user logs into tc1, then disconnects and instantenously reconnects to tc2, he won't be able to go anywhere until the information in my cisco's rip tables get wiped out about tc1s route. What I do not understand is why doesn't tc2 send the rip packet on the network telling cisco to route the ip address to it as soon as the person connects. To overcome that problem, I have enable both broadcast and listen routing on the net0 interface. However, it seems like a band-aid to the problem and not a real solution. I have called USR tech support which were not of much use. If anyone else has that problem and figured out a solution, please let me know. Thanks. Garry Shtern shterng@akula.com Akula Communications (212) 292-8892

Thus spake Pete Ashdown >Garry Shtern said once upon a time: >>If for instance a static ip user logs into tc1, then disconnects and >>instantenously reconnects to tc2, he won't be able to go anywhere until the >>information in my cisco's rip tables get wiped out about tc1s route. What >>I do not understand is why doesn't tc2 send the rip packet on the network >>telling cisco to route the ip address to it as soon as the person connects. >> To overcome that problem, I have enable both broadcast and listen routing >>on the net0 interface. However, it seems like a band-aid to the problem >>and not a real solution. I have called USR tech support which were not of >>much use. >> >>If anyone else has that problem and figured out a solution, please let me >>know. Thanks. >I ran around circles with Cisco on this. The problem exists in the >"holddown" for RIP on a Cisco. There is no way eliminate it. By changing >the RIP timers, you can minimize it: > timers basic 30 90 0 90 We did: timers basic 30 90 5 120 and this keeps the hold down to a shorter period than it takes me to hang up and redial with ISDN. I suspect that a setting of zero defaults back up to 30 seconds, but a non-zero setting less that 30 seconds will go to the setting entered (ie, its not a minimum of 30, but a zero setting will default to 30). -- Jeff McAdams Email: jeffm@iglou.com Chief Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Thus spake Brian Trader -- WAN Technician >Just a question for you since I really don;t know Cisco's but I know >BayNetworks..RIP2 is available and the netserver is able to also use it >why not try that? as it is supposed to be faster than RIP1 maybe they did >not install that holddown on that one...??? Uhm....I sent in my suggestion already...but just to cover this territory, we are using ripv2 already...still had the problem. -- Jeff McAdams Email: jeffm@iglou.com Chief Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

At 01:09 PM 9/11/97 -0600, Pete Ashdown wrote: >I ran around circles with Cisco on this. The problem exists in the >"holddown" for RIP on a Cisco. There is no way eliminate it. By changing >the RIP timers, you can minimize it: > > timers basic 30 90 0 90 > >Yet it will still initiate a holddown of around 30 seconds in this case. I >pleaded with Cisco to come out with a way to eliminate it, but they felt >that they were wiser than I and essentially ignored my suggestion. > >What is odd is that you can get rid of holddown for EIGRP. So Cisco feels >that their own protocol is deserving of this treatment, but not others. Yeah, I know. I installed it as soon as I ran across the option in IOS. However, here is the question. Isn't holddown value for routes that are "dead". This still begs the question, when exactly is USR going to come up with a better solution for routing than RIP? Btw, did you enable Proxy ARP on your tcs? Because at one point during the conversation with tech support, they suggested using proxy ARP for routing. I didn't find it much useful, since I would have to flush the ARP tables every 30 seconds on the CISCO in order to use this approach and that doesn't sound too good. Thanks for your help. Garry Shtern shterng@akula.com Akula Communications (212) 292-8892

At 03:15 PM 9/11/97 -0400, Jeff Mcadams wrote: >We did: > timers basic 30 90 5 120 > >and this keeps the hold down to a shorter period than it takes me to >hang up and redial with ISDN. I suspect that a setting of zero defaults >back up to 30 seconds, but a non-zero setting less that 30 seconds will >go to the setting entered (ie, its not a minimum of 30, but a zero >setting will default to 30). >-- Hmm.. I will try that.. Also, isn't there a sleep time as the 5th parameter in IOS 11.2? I set that to 300 which seems to work fine. Otherwise, it seems as though RIP process takes a lot of CPU time on my 7206. Garry Shtern shterng@akula.com Akula Communications (212) 292-8892

Garry Shtern said once upon a time: >Now.. here is an interesting problem. When I view my routing table on a >CISCO, I do not see any routes from the second tc, only from the first one. You'll only see routes from the TC if someone connects to it with a static network. Therefore, if there is no activity on the second TC, you won't see any routes.

At 02:19 PM 9/11/97 -0500, Brian Trader -- WAN Technician wrote: > >Just a question for you since I really don;t know Cisco's but I know >BayNetworks..RIP2 is available and the netserver is able to also use it >why not try that? as it is supposed to be faster than RIP1 maybe they did >not install that holddown on that one...??? I never dealt with RIP2, but as far as I understand the only difference is the authentication mechanism. I may be wrong.. Garry Shtern shterng@akula.com Akula Communications (212) 292-8892

Thus spake Garry Shtern >At 03:15 PM 9/11/97 -0400, Jeff Mcadams wrote: >>We did: >> timers basic 30 90 5 120 >>and this keeps the hold down to a shorter period than it takes me to >>hang up and redial with ISDN. I suspect that a setting of zero defaults >>back up to 30 seconds, but a non-zero setting less that 30 seconds will >>go to the setting entered (ie, its not a minimum of 30, but a zero >>setting will default to 30). >Hmm.. I will try that.. Also, isn't there a sleep time as the 5th parameter >in IOS 11.2? I set that to 300 which seems to work fine. Otherwise, it >seems as though RIP process takes a lot of CPU time on my 7206. Dunno about a sleep timer...we're using 11.1(9) here....incidentally, on a 4700-M. -- Jeff McAdams Email: jeffm@iglou.com Chief Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Thus spake Garry Shtern >At 02:19 PM 9/11/97 -0500, Brian Trader -- WAN Technician wrote: >>Just a question for you since I really don;t know Cisco's but I know >>BayNetworks..RIP2 is available and the netserver is able to also use it >>why not try that? as it is supposed to be faster than RIP1 maybe they did >>not install that holddown on that one...??? >I never dealt with RIP2, but as far as I understand the only difference is >the authentication mechanism. I may be wrong.. RIPV2 also adds the ability to deal with classless addressing (ie, 204.255.229.33/27) -- Jeff McAdams Email: jeffm@iglou.com Chief Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

At 01:49 PM 9/11/97 -0600, Pete Ashdown wrote: >Garry Shtern said once upon a time: > >What does the sleep timer do? RIP takes a huge amount of time on my 7000, >and I wish there was an easy way to minimize it. I am not really sure but when I put it inplace, my cpu utilization went down from 10% to about 2. Garry Shtern shterng@akula.com Chief Network Administrator tel. (212) 292-8892 Akula Communications Corp. fax. (212) 378-4096

At 03:35 PM 9/11/97 -0400, Jeff Mcadams wrote: > >RIPV2 also adds the ability to deal with classless addressing (ie, >204.255.229.33/27) How exactly do you enable ripv2 on total controls? Garry Shtern shterng@akula.com Chief Network Administrator tel. (212) 292-8892 Akula Communications Corp. fax. (212) 378-4096

Thus spake Garry Shtern >At 03:35 PM 9/11/97 -0400, Jeff Mcadams wrote: >>RIPV2 also adds the ability to deal with classless addressing (ie, >>204.255.229.33/27) >How exactly do you enable ripv2 on total controls? set ripv2 on -- Jeff McAdams Email: jeffm@iglou.com Chief Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

I have a NetServer Card, and I need to see some user's password that is register in the Card. How can I see it? Is it possible? Thanks. Rizzi

I have a NetServer Card, and I need to see some user's password that is register in the Card. How can I see it? Is it possible? Thanks. Rizzi

At 04:02 PM 9/11/97 -0400, Jeff Mcadams wrote: >>How exactly do you enable ripv2 on total controls? > >set ripv2 on Thanks.. Garry Shtern shterng@akula.com Chief Network Administrator tel. (212) 292-8892 Akula Communications Corp. fax. (212) 378-4096

At 02:07 PM 9/11/97 -0600, Pete Ashdown wrote: > >set ripv2 on >set net0 routing broadcast > > Thanks... Garry Shtern shterng@akula.com Chief Network Administrator tel. (212) 292-8892 Akula Communications Corp. fax. (212) 378-4096

At 02:07 PM 9/11/97 -0600, Pete Ashdown wrote: >Garry Shtern said once upon a time: >> >>At 03:35 PM 9/11/97 -0400, Jeff Mcadams wrote: >>> >>>RIPV2 also adds the ability to deal with classless addressing (ie, >>>204.255.229.33/27) >> >>How exactly do you enable ripv2 on total controls? > >RIPv2 is only supported in 3.4.x and higher. To use it enter these >commands in your netserver: > >set ripv2 on >set net0 routing broadcast > Now.. here is an interesting problem. When I view my routing table on a CISCO, I do not see any routes from the second tc, only from the first one. Garry Shtern shterng@akula.com Chief Network Administrator tel. (212) 292-8892 Akula Communications Corp. fax. (212) 378-4096

At 03:31 PM 9/11/97 -0600, Pete Ashdown wrote: >Garry Shtern said once upon a time: > >>Now.. here is an interesting problem. When I view my routing table on a >>CISCO, I do not see any routes from the second tc, only from the first one. > >You'll only see routes from the TC if someone connects to it with a static >network. Therefore, if there is no activity on the second TC, you won't >see any routes. I understand that.. However, this is what happens. If I delete all the rip-originated routes from cisco it loads them back. But the routes that appear there only originate from tc1, there are no routes from tc2. If I enable broad/listen algorithm on net0 on tc1, I will see rip updates from tc2. Garry Shtern shterng@akula.com Chief Network Administrator tel. (212) 292-8892 Akula Communications Corp. fax. (212) 378-4096

We have the identical problem, but fortunately our static IP users are patient when we explain what that they have to stay connected long enough for the routing protocol to work when they re-login. We have shortened the arp cache timeout in the router, also. -CH On Thu, 11 Sep 1997, Garry Shtern wrote: > Hello, > > I have the following setup and I am trying to figure out the best way of > dealing with the situation. I have 2 total control hubs, each of them has > a pool of 48 ip addresses. I have them setup to read all the > authentication information from merit radius server. In addition, I have > static ip users which get assigned the same ip address every time they > login. However, this is the problem. > > If for instance a static ip user logs into tc1, then disconnects and > instantenously reconnects to tc2, he won't be able to go anywhere until the > information in my cisco's rip tables get wiped out about tc1s route. What > I do not understand is why doesn't tc2 send the rip packet on the network > telling cisco to route the ip address to it as soon as the person connects. > To overcome that problem, I have enable both broadcast and listen routing > on the net0 interface. However, it seems like a band-aid to the problem > and not a real solution. I have called USR tech support which were not of > much use. > > If anyone else has that problem and figured out a solution, please let me > know. Thanks. > > > > Garry Shtern shterng@akula.com > Akula Communications (212) 292-8892 > >

Use Netserver Manager to save the settings to disk. The user table (part of the .ncf file) includes the passwords in clear text. -CH On Thu, 11 Sep 1997, Ricardo Rizzi wrote: > > I have a NetServer Card, and I need to see some user's password that is > register in the Card. > How can I see it? Is it possible? > > Thanks. > > Rizzi > > >

Using TCS 2.5.1, T1/E1 cards. I've configured the cards, saved configs, saved NVRAM. The cards run fine for a few days, and then boom, they stop answering. Logon to tc rack, and the ports show: S4 I I - on 0.0.0.0 Login/Ne IDLE 0 0 0 S5 A R P on 0.0.0.0 Login/Ne IDLE 11 101 0 S6 I I P on 0.0.0.0 Login/Ne IDLE 11 101 0 (S5 I just did another set active/save/reset s5 on. It was in the I I state). I can find nothing different. I have a set of these using older TCS 2.5.0 code and it works fine, never seen this problem. I am leery of upgrading my other sites until I get this resolved.

We had these problems before.. Here is what you basically have to do. In TCM, you should select all the modems, and load the default configuration into NVRAM, then save that configuration and restart. I don't know but that solved the problems. Also try upgrade to 5.6.7 code for the modems. -Garry On Fri, 12 Sep 1997, Jaye Mathisen wrote: > > > Using TCS 2.5.1, T1/E1 cards. > > I've configured the cards, saved configs, saved NVRAM. The cards run fine > for a few days, and then boom, they stop answering. Logon to tc rack, > and the ports show: > > S4 I I - on 0.0.0.0 Login/Ne IDLE 0 0 > 0 > S5 A R P on 0.0.0.0 Login/Ne IDLE 11 101 > 0 > S6 I I P on 0.0.0.0 Login/Ne IDLE 11 101 > 0 > > > (S5 I just did another set active/save/reset s5 on. It was in the I I > state). > > I can find nothing different. I have a set of these using older TCS 2.5.0 > code and it works fine, never seen this problem. > > I am leery of upgrading my other sites until I get this resolved. > > > > >

On Fri, 12 Sep 1997, Jaye Mathisen wrote: > > > Using TCS 2.5.1, T1/E1 cards. > > I've configured the cards, saved configs, saved NVRAM. The cards run fine > for a few days, and then boom, they stop answering. Logon to tc rack, > and the ports show: > > S4 I I - on 0.0.0.0 Login/Ne IDLE 0 0 > 0 > S5 A R P on 0.0.0.0 Login/Ne IDLE 11 101 > 0 > S6 I I P on 0.0.0.0 Login/Ne IDLE 11 101 > 0 > > > (S5 I just did another set active/save/reset s5 on. It was in the I I > state). > > I can find nothing different. I have a set of these using older TCS 2.5.0 > code and it works fine, never seen this problem. > > I am leery of upgrading my other sites until I get this resolved. > Thru TCM, get things the way you want, then select NMC card and do "Save chassis to NVRAM"........not saying it will work, just a thought. Brian > > > > /-------------------------- signal@shreve.net -----------------------------\ | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | | Systems Administrator | Perl, Linux | Web hosting, online stores, | | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | | 89 CRX, Akimoto intake, DC |-=*:Quake:*=-| http://www.shreve.net/ | | headers, Eurosport exhaust |LordSignal/SN| Quake server: 208.206.76.3 | \-------------------------- 318-222-2638 x109 -----------------------------/

Hi all. I finally took delivery of my new TC hub and I am in the process of configuring it. I am using Merit Radius 2.3 and I am authenticating using realms. The only major problem so far is that when I define a user as Login, the TC hub disallows the authentication even though it was okayed by radius. Framed users authenticate just fine and PPP starts up properly. Anyone seen this before? Thanks. > Colin McFadyen > Carleton University CCS > 409 Robertson Hall > voice: 613-520-2600 ext. 3721 fax: 613-520-4448 >

At 04:42 PM 9/12/97 -0400, Colin_McFadyen wrote: >Hi all. > >I finally took delivery of my new TC hub and I am in the process of >configuring it. > >I am using Merit Radius 2.3 and I am authenticating using realms. > >The only major problem so far is that when I define a user as Login, the >TC hub disallows the authentication even though it was okayed by radius. >Framed users authenticate just fine and PPP starts up properly. > >Anyone seen this before? you have to set each port to Login/Network instead of just Network -Garry Garry Shtern shterng@akula.com Chief Network Administrator tel. (212) 292-8892 Akula Communications Corp. fax. (212) 378-4096

At 04:42 PM 9/12/97 -0400, Colin_McFadyen wrote: >Hi all. > >I finally took delivery of my new TC hub and I am in the process of >configuring it. > >I am using Merit Radius 2.3 and I am authenticating using realms. > >The only major problem so far is that when I define a user as Login, the >TC hub disallows the authentication even though it was okayed by radius. >Framed users authenticate just fine and PPP starts up properly. > >Anyone seen this before? you have to set each port to Login/Network instead of just Network -Garry Garry Shtern shterng@akula.com Chief Network Administrator tel. (212) 292-8892 Akula Communications Corp. fax. (212) 378-4096

Once upon a time G. Douglas Davidson shaped the electrons to say... >it to me and another that told me to call Livingston. I don't feel >comfortable calling Livingston to ask them for USR's attribute >definitions. I thought that USR would probably be a bit better able to We don't have them anyway. -MZ -- Livingston Enterprises - Chair, Department of Interstitial Affairs Phone: 800-458-9966 510-737-2100 FAX: 510-737-2110 megazone@livingston.com For support requests: support@livingston.com <http://www.livingston.com/> Snail mail: 4464 Willow Road, Pleasanton, CA 94588

Once upon a time Garry Shtern shaped the electrons to say... >I never dealt with RIP2, but as far as I understand the only difference is >the authentication mechanism. I may be wrong.. RIPv2 allows for VLSM & CIDR, RIPv1 does not. THAT is the major difference. -MZ -- Livingston Enterprises - Chair, Department of Interstitial Affairs Phone: 800-458-9966 510-737-2100 FAX: 510-737-2110 megazone@livingston.com For support requests: support@livingston.com <http://www.livingston.com/> Snail mail: 4464 Willow Road, Pleasanton, CA 94588

Log on to the NETServer as !root and set the modems as follows set all login network dialin reset all save all. Remember if you do a reset all users loged in will get disconnected so make sure that you do this when users are not logged in krish \ T.S.V. Krishnan \ \ Network System Engineer \ ( : - : ) \ 3Com ............ \ ----------------------------------------------/ tkrishna@bubba.ae.usr.com ----------------------------/ http://interproc.ae.usr.com ----/ Any Sufficiently advanced bug is indistinguishable for a feature. - Rick Kulawiec On Fri, 12 Sep 1997, Colin_McFadyen wrote: > Hi all. > > I finally took delivery of my new TC hub and I am in the process of > configuring it. > > I am using Merit Radius 2.3 and I am authenticating using realms. > > The only major problem so far is that when I define a user as Login, the > TC hub disallows the authentication even though it was okayed by radius. > Framed users authenticate just fine and PPP starts up properly. > > Anyone seen this before? > > Thanks. > > > > Colin McFadyen > > Carleton University CCS > > 409 Robertson Hall > > voice: 613-520-2600 ext. 3721 fax: 613-520-4448 > > >

I don't think that is possible with out using radius, but I could be wrong. The ADD NETUSER commands are great for corporate LAN's that don't publish their dial in number. If you want to look at passwords, limit the time a user stay's online and even make sure you only allow logon's from a specific phone number. You might want to consider installing the Radius server. Mike Hamrich Technical Director DrFast.Net, Inc,

On Friday, September 12, 1997 9:26 PM, G. Douglas Davidson [SMTP:douglas@city-net.com] wrote: > > On Fri, 12 Sep 1997, MegaZone wrote: > > > Once upon a time G. Douglas Davidson shaped the electrons to say... > > >it to me and another that told me to call Livingston. I don't feel > > >comfortable calling Livingston to ask them for USR's attribute > > >definitions. I thought that USR would probably be a bit better able to > > > > We don't have them anyway. > > > > -MZ > > I was ripping on USR a bit. > > I think a visit to "totalservice.usr.com" followed by a visit to the > support section of "www.livingston.com" pretty much says it all. > > These guys (USR) ought to invest in documentation and the web site. There > should not be any restriction to those wishing to access their web site > (it took me days to prove that I was worthy) and they should give away the > tools necessary to to configure their box or improve the text interface. > > An example: > > To get tech support, you need to fax in your agreement with the serial > numbers for each of the various cards that make up your system. Try > getting these numbers without with the SMTP manager. You have to take apart > the system! What a waste of time! > > This is after spending $2,000 on tech support. The SMTP tool is $1,500. > > Or how about configuring your dual analog/digital modems to be > "recognized" by the T1s? I think it was "atd1". How many people need to > do this? Kind of makes sense to put together some sort of documentation. > Maybe something like Livingston's "Basic ISP Setup". What a breeze that > was. > > I am giving up on the "rlogin" issue. It ain't radius related, the > problem continues when I verify via a user on the box. I've been > through three "Netserver" cards and "Liz from Logistics" is tired of me. > I am going to have to move over to telnet. > > The box seems to be working quite well other than the setup and rlogin > issues. > > I believe that if USR quit charging for tech support they would be > incentified to provide a better web site, better documentation, and the > tools (not windows based, include more versions of unix) necessary to > configure the box. Gee. Sounds like Livingston. > > End of Tirade. First. Make sure you are using the 2.0 or 2.0.1 of the dictionary file if using Livingston Rad 2.0.x: /etc/raddb/dictionary # @(#)dictionary 1.3 10/1/96 Copyright 1991 Livingston Enterprises Inc Second. Make sure the users file entry looks a lot like this: /etc/raddb/users tootbug Auth-Type = System, User-Service-Type = Login-User, Login-Host = "host.mydomain.com", Login-Service = Rlogin Thirdly, make sure the ports on the NETSERVER are configured similar to this: set all security on set all login network dialin set all prompt login: <for that UNIX look and feel!> That should just about do it. Make sure the /etc/hosts.equiv and/or hosts.allow if using TCPD have the host.mydomain.com in them. Something like: /etc/hosts.equiv ts1.jxn.netdoor.com + ts2.jxn.netdoor.com + ... /etc/hosts.allow in.rlogind: .mydomain.com Please e-mail me directly if you need to. Marshall Morgan President Internet Doorway, Inc. http://www.netdoor.com 601.969.1434 | 800.952.1570 | 601.969.3838 Fax

On Fri, 12 Sep 1997, MegaZone wrote: > Once upon a time G. Douglas Davidson shaped the electrons to say... > >it to me and another that told me to call Livingston. I don't feel > >comfortable calling Livingston to ask them for USR's attribute > >definitions. I thought that USR would probably be a bit better able to > > We don't have them anyway. > > -MZ I was ripping on USR a bit. I think a visit to "totalservice.usr.com" followed by a visit to the support section of "www.livingston.com" pretty much says it all. These guys (USR) ought to invest in documentation and the web site. There should not be any restriction to those wishing to access their web site (it took me days to prove that I was worthy) and they should give away the tools necessary to to configure their box or improve the text interface. An example: To get tech support, you need to fax in your agreement with the serial numbers for each of the various cards that make up your system. Try getting these numbers without with the SMTP manager. You have to take apart the system! What a waste of time! This is after spending $2,000 on tech support. The SMTP tool is $1,500. Or how about configuring your dual analog/digital modems to be "recognized" by the T1s? I think it was "atd1". How many people need to do this? Kind of makes sense to put together some sort of documentation. Maybe something like Livingston's "Basic ISP Setup". What a breeze that was. I am giving up on the "rlogin" issue. It ain't radius related, the problem continues when I verify via a user on the box. I've been through three "Netserver" cards and "Liz from Logistics" is tired of me. I am going to have to move over to telnet. The box seems to be working quite well other than the setup and rlogin issues. I believe that if USR quit charging for tech support they would be incentified to provide a better web site, better documentation, and the tools (not windows based, include more versions of unix) necessary to configure the box. Gee. Sounds like Livingston. End of Tirade.

We are switching from livingston PM's to TC racks wholesale here. I could've sworn in my initial tests that it did, but now it appears it doesn't. I am not envious of the job of converting a whole truckload of customers to new dns numbers... :(

On Fri, 12 Sep 1997, G. Douglas Davidson wrote: [snip] > I believe that if USR quit charging for tech support they would be > incentified to provide a better web site, better documentation, and the > tools (not windows based, include more versions of unix) necessary to > configure the box. Gee. Sounds like Livingston. > > End of Tirade. > We could also press the issue by helping each other by maintaining a FAQ from this list. I just got here and I haven't gotten my TC hubs yet, but I'll be happy to share anything I learn in the process of getting them going. We could pressure 3COM to get better about supporting us and they might listen better if the see us getting more cooperative with each other...ala portmaster-users My $.02 ========================================================================= Jeffrey A. Lynch, President 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 Sat, 13 Sep 1997, Jaye Mathisen wrote: > > > We are switching from livingston PM's to TC racks wholesale here. > > I could've sworn in my initial tests that it did, but now it appears it > doesn't. I am not envious of the job of converting a whole truckload of > customers to new dns numbers... :( I am assuming you are using radius verification here. There is a mistake in the radius dictionary file from USR in that it lists the PRIMARY_DNS and SECONDARY_DNS as string, while infact they should be listed as ipaddr. /--------------------------- David Crabtree -------------------------------\ | Vice Pres/Sys Admin | Dialup 56K | Quake - [GI] Scream | | WSNetworxx Inc. | Dialup ISDN | http://www.wsnet.com/~quake | | 448 South Lawrence Street | Ded. ISDN/T1 |-------------------------------| | Montgomery, AL, 36104 | Web Hosting | SysAdmin - WebMaster/Designer | | http://www.wsnet.com | Web Design | Graphics - Programmer | \------- mailto:wolfcub@wsnet.com -- http://www.wsnet.com/~wolfcub --------/

Thus spake Jaye Mathisen >We are switching from livingston PM's to TC racks wholesale here. >I could've sworn in my initial tests that it did, but now it appears it >doesn't. I am not envious of the job of converting a whole truckload of >customers to new dns numbers... :( Do a show global and at the bottom, if it says "Send DNS Info: On" or something like that, then windoze95 should pick up the DNS info....*if* its set to server assigned DNS servers. -- Jeff McAdams Email: jeffm@iglou.com Chief Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

When setting up MPIP do you have to reboot the netservers? I turned mpipserver ON on tchub#1 set tchubs#2-#3 to use tchyb#2 as there mpipserver added tchubs #1-#3 to the mpipclients table set a time server on all 3 hubs that should be it correct? it doesnt appear to be working and was wondering if I need to restart the netservers maybe? Brian /-------------------------- signal@shreve.net -----------------------------\ | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | | Systems Administrator | Perl, Linux | Web hosting, online stores, | | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | | 89 CRX, Akimoto intake, DC |-=*:Quake:*=-| http://www.shreve.net/ | | headers, Eurosport exhaust |LordSignal/SN| Quake server: 208.206.76.3 | \-------------------------- 318-222-2638 x109 -----------------------------/

On Sat, 13 Sep 1997, Brian wrote: > When setting up MPIP do you have to reboot the netservers? > I turned mpipserver ON on tchub#1 > > set tchubs#2-#3 to use tchyb#2 as there mpipserver > added tchubs #1-#3 to the mpipclients table > set a time server on all 3 hubs > Type "reset time" on each netserver to synch the clocks. -CH

Make sure that you have time servers set on all the NETServers, check the time on all the NETServers. krish \ T.S.V. Krishnan \ \ Network System Engineer \ ( : - : ) \ 3Com ............ \ ----------------------------------------------/ tkrishna@bubba.ae.usr.com ----------------------------/ http://interproc.ae.usr.com ----/ Any Sufficiently advanced bug is indistinguishable for a feature. - Rick Kulawiec On Sat, 13 Sep 1997, Brian wrote: > > When setting up MPIP do you have to reboot the netservers? > > > I turned mpipserver ON on tchub#1 > > set tchubs#2-#3 to use tchyb#2 as there mpipserver > added tchubs #1-#3 to the mpipclients table > set a time server on all 3 hubs > > that should be it correct? it doesnt appear to be working and was > wondering if I need to restart the netservers maybe? > > Brian > > /-------------------------- signal@shreve.net -----------------------------\ > | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | > | Systems Administrator | Perl, Linux | Web hosting, online stores, | > | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | > | 89 CRX, Akimoto intake, DC |-=*:Quake:*=-| http://www.shreve.net/ | > | headers, Eurosport exhaust |LordSignal/SN| Quake server: 208.206.76.3 | > \-------------------------- 318-222-2638 x109 -----------------------------/ > > >

On Sat, 13 Sep 1997, Jeff Lynch wrote: > On Fri, 12 Sep 1997, G. Douglas Davidson wrote: > > [snip] > > I believe that if USR quit charging for tech support they would be > > incentified to provide a better web site, better documentation, and the > > tools (not windows based, include more versions of unix) necessary to > > configure the box. Gee. Sounds like Livingston. > > > > End of Tirade. > > > > We could also press the issue by helping each other by maintaining a FAQ > from this list. I just got here and I haven't gotten my TC hubs yet, but > I'll be happy to share anything I learn in the process of getting them > going. We could pressure 3COM to get better about supporting us and > they might listen better if the see us getting more cooperative with > each other...ala portmaster-users > > My $.02 > Your ideas to improve the web site is welcome. Currently the total service Web site has FAQ's and some good important documentation - To get to these information you need not login - You need no username or password. The web site needs login since it also get you access to reports and tracker information. The rlogin problem for example. This is a bug. It has been fixed in 3.6.x beta release. Please give us your suggesstion to improve the same. krish \ T.S.V. Krishnan \ \ Network System Engineer \ ( : - : ) \ 3Com ............ \ ----------------------------------------------/ tkrishna@bubba.ae.usr.com ----------------------------/ http://interproc.ae.usr.com ----/ Any Sufficiently advanced bug is indistinguishable for a feature. - Rick Kulawiec > ========================================================================= > Jeffrey A. Lynch, President 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 > >

set the users Host as 255.255.255.255 This will prompt the user for a host IP. krish \ T.S.V. Krishnan \ \ Network System Engineer \ ( : - : ) \ 3Com ............ \ ----------------------------------------------/ tkrishna@bubba.ae.usr.com ----------------------------/ http://interproc.ae.usr.com ----/ Any Sufficiently advanced bug is indistinguishable for a feature. - Rick Kulawiec On Sun, 14 Sep 1997, Colin_McFadyen wrote: > Thanks, that did it. > > On a related note, what entry do I put in the radius Login-IP-Host line > so that the user can get the 'Host:' prompt rather than a forced connect > to a particular machine? > > Colin McFadyen > Carleton University CCS > 613-520-2600 ext. 3721 > > > ---------- > > From: Tatai SV Krishnan[SMTP:tkrishna@bubba.ae.usr.com] > > Sent: Friday, September 12, 1997 10:00 PM > > To: usr-tc@mail.xmission.com > > Subject: Re: (usr-tc) Help needed with Merit Radius prob. > > > > Log on to the NETServer as !root and set the modems as follows > > > > set all login network dialin > > reset all > > save all. > > > > Remember if you do a reset all users loged in will get disconnected so > > > > make sure that you do this when users are not logged in > > > > krish > > > > > > ----------------------------------------- > > \ T.S.V. Krishnan \ > > \ Network System Engineer \ ( : - : ) > > \ 3Com ............ \ > > ----------------------------------------------/ > > tkrishna@bubba.ae.usr.com > > ----------------------------/ http://interproc.ae.usr.com ----/ > > ---------------------------------------------------------------------- > > ---\ > > Any Sufficiently advanced bug is indistinguishable for a > > feature. > > - Rick Kulawiec > > ---------------------------------------------------------------------- > > ---/ > > > > On Fri, 12 Sep 1997, Colin_McFadyen wrote: > > > > > Hi all. > > > > > > I finally took delivery of my new TC hub and I am in the process of > > > configuring it. > > > > > > I am using Merit Radius 2.3 and I am authenticating using realms. > > > > > > The only major problem so far is that when I define a user as Login, > > the > > > TC hub disallows the authentication even though it was okayed by > > radius. > > > Framed users authenticate just fine and PPP starts up properly. > > > > > > Anyone seen this before? > > > > > > Thanks. > > > > > > > > > > Colin McFadyen > > > > Carleton University CCS > > > > 409 Robertson Hall > > > > voice: 613-520-2600 ext. 3721 fax: 613-520-4448 > > > > > > > > > >

On Sun, 14 Sep 1997, Garry Shtern wrote: > On Sat, 13 Sep 1997, Tatai SV Krishnan wrote: > > > Your ideas to improve the web site is welcome. Currently the total > > service Web site has FAQ's and some good important documentation - To get > > to these information you need not login - You need no username or > > password. The web site needs login since it also get you access to > > reports and tracker information. > > > > The rlogin problem for example. This is a bug. It has been fixed in > > 3.6.x beta release. Please give us your suggesstion to improve the same. > > > > Can you please explain to us why exactly don't you guys make your beta > code available to certain individuals who ask for it. For instance, if > you know that there is a bug and you guys fixed it in some newer version, > wouldn't it make sense to tell people like myself and others that there is > a newer version available, however it is in beta so use it at your own > risk. First of all, that would help a lot of us. Secondly, it will give > you guys a better beta testing environment since we are out here dealing > with real users and real problems. Just a thought. > > -Garry > The bug in Rlogin was with downloads. Giving out beta code is easier said than down. We are working towards open beta. This is a good suggestion and I shall make sure that the management hears about this krish \ T.S.V. Krishnan \ \ Network System Engineer \ ( : - : ) \ 3Com ............ \ ----------------------------------------------/ tkrishna@bubba.ae.usr.com ----------------------------/ http://interproc.ae.usr.com ----/ Any Sufficiently advanced bug is indistinguishable for a feature. - Rick Kulawiec >

Thanks, that did it. On a related note, what entry do I put in the radius Login-IP-Host line so that the user can get the 'Host:' prompt rather than a forced connect to a particular machine? Colin McFadyen Carleton University CCS 613-520-2600 ext. 3721 > ---------- > From: Tatai SV Krishnan[SMTP:tkrishna@bubba.ae.usr.com] > Sent: Friday, September 12, 1997 10:00 PM > To: usr-tc@mail.xmission.com > Subject: Re: (usr-tc) Help needed with Merit Radius prob. > > Log on to the NETServer as !root and set the modems as follows > > set all login network dialin > reset all > save all. > > Remember if you do a reset all users loged in will get disconnected so > > make sure that you do this when users are not logged in > > krish > > > ----------------------------------------- > \ T.S.V. Krishnan \ > \ Network System Engineer \ ( : - : ) > \ 3Com ............ \ > ----------------------------------------------/ > tkrishna@bubba.ae.usr.com > ----------------------------/ http://interproc.ae.usr.com ----/ > ---------------------------------------------------------------------- > ---\ > Any Sufficiently advanced bug is indistinguishable for a > feature. > - Rick Kulawiec > ---------------------------------------------------------------------- > ---/ > > On Fri, 12 Sep 1997, Colin_McFadyen wrote: > > > Hi all. > > > > I finally took delivery of my new TC hub and I am in the process of > > configuring it. > > > > I am using Merit Radius 2.3 and I am authenticating using realms. > > > > The only major problem so far is that when I define a user as Login, > the > > TC hub disallows the authentication even though it was okayed by > radius. > > Framed users authenticate just fine and PPP starts up properly. > > > > Anyone seen this before? > > > > Thanks. > > > > > > > Colin McFadyen > > > Carleton University CCS > > > 409 Robertson Hall > > > voice: 613-520-2600 ext. 3721 fax: 613-520-4448 > > > > > >

Hi all. I just received my X2 key and I applied it as per the instructions. When I call my TC rack with an X2 Sportster, I get a one line connect status message saying that I am connected at 33333 with x2. The connection is very slow to respond to keystrokes to the point that it is not useable. When I connect to the USR linetest number (888-877-9248), I get a good x2 connection so I know that my Sportster is okay. I get a multi-line connect message saying that I am connected at 52000 x2 and 33333...etc.. 28.8K or 14.4K calls to my TC rack work just fine. Software versions: PRI/T1 - 2.5.3 Quad Modem - 5.6.7 Netserver - 3.5.34 NMC - 4.3.9 Colin McFadyen Carleton University CCS 613-520-2600 ext. 3721

On Sat, 13 Sep 1997, Tatai SV Krishnan wrote: > Your ideas to improve the web site is welcome. Currently the total > service Web site has FAQ's and some good important documentation - To get > to these information you need not login - You need no username or > password. The web site needs login since it also get you access to > reports and tracker information. > > The rlogin problem for example. This is a bug. It has been fixed in > 3.6.x beta release. Please give us your suggesstion to improve the same. > Can you please explain to us why exactly don't you guys make your beta code available to certain individuals who ask for it. For instance, if you know that there is a bug and you guys fixed it in some newer version, wouldn't it make sense to tell people like myself and others that there is a newer version available, however it is in beta so use it at your own risk. First of all, that would help a lot of us. Secondly, it will give you guys a better beta testing environment since we are out here dealing with real users and real problems. Just a thought. -Garry

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. --IMA.Boundary.386633478 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: <Pine.LNX.3.91.970914231000.2540E@bubba.ae.usr.com> Content-Description: cc:Mail note part The second message indicates that the call has an invalid LLCIE. We have recently discovered that this can happen with certain terminal adaptors when connected to certain switch types (the Ericson switches seem to be the main culprit in this regard). We are currently working on a fix to the NETServer for this problem. The first message means that there are no free ports The chassis is full of calls and cannot route the call anywhere currently krish Hi, today I had plenty of those messages in my /var/run/authlog from our usr-tc named "polyp": Sep 14 22:06:59 polyp *** ISDN WARNING ***: DNIS: 73790 ANI: 919166609 Type: B: I5 Call rejected for lack of resources and Sep 13 14:02:58 polyp *** ISDN WARNING ***: I2 Call rejected - CC info INVALID Sep 13 14:03:03 polyp *** ISDN WARNING ***: Bad low_layer_comp.user_info_layer_1_protocol 131 Anyone knows what that could be? Thanks in advance, bye, Lars -- +-----------------------------------------------------------------+ | Lars Freund lars@forchheim.com | | FOnLine Buergernetzverein: http://www.forchheim.baynet.de | | http://cip2.e-technik.uni-erlangen.de:8080/hyplan/lafreund.html | +-----------------------------------------------------------------+ --IMA.Boundary.386633478--

On Sun, 14 Sep 1997, Colin_McFadyen wrote: > Hi all. > > I just received my X2 key and I applied it as per the instructions. > When I call my TC rack with an X2 Sportster, I get a one line connect > status message saying that I am connected at 33333 with x2. The > connection is very slow to respond to keystrokes to the point that it is > not useable. > > When I connect to the USR linetest number (888-877-9248), I get a good > x2 connection so I know that my Sportster is okay. I get a multi-line > connect message saying that I am connected at 52000 x2 and 33333...etc.. Do you have your hubs connected via a digital T1 to your phone carrier? If so check whether or not you have B8ZS or ANI framing on the line. If you have ANI, place an order to change to B8ZS. We have TCs here and all of our X2 customers are connecting with 48+k speeds.. -Garry

On Sun, 14 Sep 1997, Colin_McFadyen wrote: > Hi all. > > I just received my X2 key and I applied it as per the instructions. > When I call my TC rack with an X2 Sportster, I get a one line connect > status message saying that I am connected at 33333 with x2. The > connection is very slow to respond to keystrokes to the point that it is > not useable. > > When I connect to the USR linetest number (888-877-9248), I get a good > x2 connection so I know that my Sportster is okay. I get a multi-line > connect message saying that I am connected at 52000 x2 and 33333...etc.. Do you have your hubs connected via a digital T1 to your phone carrier? If so check whether or not you have B8ZS or ANI framing on the line. If you have ANI, place an order to change to B8ZS. We have TCs here and all of our X2 customers are connecting with 48+k speeds.. -Garry

On Tue, 16 Sep 1997, Michael H. Hamrich wrote: > Are there not two different flavors of B8ZS, Can this also effect the > connect rates. We see average of 42K and many 33333 connects. There is an AT&T version but I don't think anyone is using that.. It doesn't affect connect rates as much as stability. However, connect rates are better with B8ZS -Garry

Hi, today I had plenty of those messages in my /var/run/authlog from our usr-tc named "polyp": Sep 14 22:06:59 polyp *** ISDN WARNING ***: DNIS: 73790 ANI: 919166609 Type: B: I5 Call rejected for lack of resources and Sep 13 14:02:58 polyp *** ISDN WARNING ***: I2 Call rejected - CC info INVALID Sep 13 14:03:03 polyp *** ISDN WARNING ***: Bad low_layer_comp.user_info_layer_1_protocol 131 Anyone knows what that could be? Thanks in advance, bye, Lars -- +-----------------------------------------------------------------+ | Lars Freund lars@forchheim.com | | FOnLine Buergernetzverein: http://www.forchheim.baynet.de | | http://cip2.e-technik.uni-erlangen.de:8080/hyplan/lafreund.html | +-----------------------------------------------------------------+

Yes, I have a digital PRI line and I am set for B8ZS. > Colin McFadyen > Carleton University CCS > 409 Robertson Hall > voice: 613-520-2600 ext. 3721 fax: 613-520-4448 > > > ---------- > From: Garry Shtern[SMTP:shterng@akula.com] > Reply To: usr-tc@mail.xmission.com > Sent: Sunday, September 14, 1997 11:44 PM > To: usr-tc@mail.xmission.com > Cc: 'usr-tc@xmission.com' > Subject: Re: (usr-tc) X2 upgrade problem > > On Sun, 14 Sep 1997, Colin_McFadyen wrote: > > > Hi all. > > > > I just received my X2 key and I applied it as per the instructions. > > When I call my TC rack with an X2 Sportster, I get a one line > connect > > status message saying that I am connected at 33333 with x2. The > > connection is very slow to respond to keystrokes to the point that > it is > > not useable. > > > > When I connect to the USR linetest number (888-877-9248), I get a > good > > x2 connection so I know that my Sportster is okay. I get a > multi-line > > connect message saying that I am connected at 52000 x2 and > 33333...etc.. > > Do you have your hubs connected via a digital T1 to your phone > carrier? > If so check whether or not you have B8ZS or ANI framing on the line. > If > you have ANI, place an order to change to B8ZS. We have TCs here and > all > of our X2 customers are connecting with 48+k speeds.. > > -Garry > >

On Sun, 14 Sep 1997, Tatai SV Krishnan wrote: > > On Sun, 14 Sep 1997, Garry Shtern wrote: > > > On Sat, 13 Sep 1997, Tatai SV Krishnan wrote: > > > > > Your ideas to improve the web site is welcome. Currently the total > > > service Web site has FAQ's and some good important documentation - To get > > > to these information you need not login - You need no username or > > > password. The web site needs login since it also get you access to > > > reports and tracker information. > > > > > > The rlogin problem for example. This is a bug. It has been fixed in > > > 3.6.x beta release. Please give us your suggesstion to improve the same. > > > > > > > Can you please explain to us why exactly don't you guys make your beta > > code available to certain individuals who ask for it. For instance, if > > you know that there is a bug and you guys fixed it in some newer version, > > wouldn't it make sense to tell people like myself and others that there is > > a newer version available, however it is in beta so use it at your own > > risk. First of all, that would help a lot of us. Secondly, it will give > > you guys a better beta testing environment since we are out here dealing > > with real users and real problems. Just a thought. > > > > -Garry > > > > The bug in Rlogin was with downloads. Giving out beta code is easier > said than down. We are working towards open beta. This is a good > suggestion and I shall make sure that the management hears about this > > krish While you're at it. Please ask them about FREE SOFTWARE UPGRADES. > > > ----------------------------------------- > \ T.S.V. Krishnan \ > \ Network System Engineer \ ( : - : ) > \ 3Com ............ \ > ----------------------------------------------/ > tkrishna@bubba.ae.usr.com > ----------------------------/ http://interproc.ae.usr.com ----/ > -------------------------------------------------------------------------\ > Any Sufficiently advanced bug is indistinguishable for a feature. > - Rick Kulawiec > -------------------------------------------------------------------------/ > > > ========================================================================= Jeffrey A. Lynch, President 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 Sun, 14 Sep 1997, Tatai SV Krishnan wrote: > > The bug in Rlogin was with downloads. Giving out beta code is easier > said than down. We are working towards open beta. This is a good > suggestion and I shall make sure that the management hears about this > Thanks. Another question if I may. I have the weirdest problem I have ever seen on one of my TCs. I have a user that has a static IP. In addition to that he has a subnet being routed to him. Here is the problem: When he logs in to the first TC, the routing table gets updated fine and he gets a router 1.2.3.4/27 3.4.5.6 1 assigned to the pptp that he is on. However, when he logs on the second TC, this is what happens. Instead of adding a route with metric 1, it adds the same route with metric 13. Now, I have him in my radius database and other than him, all users get authenticated fine and with no problems; but he is the only one with a subnet being routed to him. It is not a big deal since dead routes have metric of 16 but I would still be curious to find out why exactly does one of them add routes correctly and the other doesn't. I tried everything I could think of: I reflashed the card, I reset it to the default settings. Still the same.. -Garry

On Mon, 15 Sep 1997, Colin_McFadyen wrote: > Yes, I have a digital PRI line and I am set for B8ZS. > Then try setting DTMF tones on the modems instead of MF and ask your phone to run a thorough checks on your T1s.. -Garry

-----BEGIN PGP SIGNED MESSAGE----- On Sun, 14 Sep 1997, Colin_McFadyen wrote: > Hi all. > > I just received my X2 key and I applied it as per the instructions. > When I call my TC rack with an X2 Sportster, I get a one line connect > status message saying that I am connected at 33333 with x2. The > connection is very slow to respond to keystrokes to the point that it is > not useable. > > When I connect to the USR linetest number (888-877-9248), I get a good > x2 connection so I know that my Sportster is okay. I get a multi-line > connect message saying that I am connected at 52000 x2 and 33333...etc.. > > 28.8K or 14.4K calls to my TC rack work just fine. > I'm curious, we have been having the same problem. It has finally been tracked down to a telco related problem with how they route local as opposed to LD calls. Try dialing a PIC code (long distance carrier) in front of your phone number (i.e. 10288xxx-xxxx) and see if the connect speeds go up. If things improve, then you are in the same boat we are.. Unfortunately, dialing a PIC code incurrs long distance charges even for local calls, so this is not a fix for our customers.. At the moment we are working with USR/3Com (hey Todd!) and the local carrier (PacBell) switch engineers to figure out what needs to be done. > Software versions: > PRI/T1 - 2.5.3 > Quad Modem - 5.6.7 > Netserver - 3.5.34 > NMC - 4.3.9 > > Colin McFadyen > Carleton University CCS > 613-520-2600 ext. 3721 > - - Josh Richards / jrichard@fix.net / Finger for PGP key - - - Systems Administrator / FIX Net / http://www.fix.net - -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: http://www.c2.org/~bryce/Niche.html 'BAP' Easy-PGP v1.1b2 iQCVAwUBNB1+IGm9zE6XY0w5AQHjAgP/cl5RUrGg6JeXnFh2DxgpD/RFp6zgjBT2 /OFxFQmmJqlx8cOqwmWAqgdMZtqlgUiRV4tOOpNyf/VcuqmsFXPHAUw5vkBPO+09 cwJzZscAnY2ln9RdX8JkIPZ9C6MG2xJHk1l4iANQRJucYpIOczwREbEJUT9GrAjd pMercFXJgK4= =GfEX -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE----- On Sun, 14 Sep 1997, Colin_McFadyen wrote: > Hi all. > > I just received my X2 key and I applied it as per the instructions. > When I call my TC rack with an X2 Sportster, I get a one line connect > status message saying that I am connected at 33333 with x2. The > connection is very slow to respond to keystrokes to the point that it is > not useable. > > When I connect to the USR linetest number (888-877-9248), I get a good > x2 connection so I know that my Sportster is okay. I get a multi-line > connect message saying that I am connected at 52000 x2 and 33333...etc.. > > 28.8K or 14.4K calls to my TC rack work just fine. > I'm curious, we have been having the same problem. It has finally been tracked down to a telco related problem with how they route local as opposed to LD calls. Try dialing a PIC code (long distance carrier) in front of your phone number (i.e. 10288xxx-xxxx) and see if the connect speeds go up. If things improve, then you are in the same boat we are.. Unfortunately, dialing a PIC code incurrs long distance charges even for local calls, so this is not a fix for our customers.. At the moment we are working with USR/3Com (hey Todd!) and the local carrier (PacBell) switch engineers to figure out what needs to be done. > Software versions: > PRI/T1 - 2.5.3 > Quad Modem - 5.6.7 > Netserver - 3.5.34 > NMC - 4.3.9 > > Colin McFadyen > Carleton University CCS > 613-520-2600 ext. 3721 > - - Josh Richards / jrichard@fix.net / Finger for PGP key - - - Systems Administrator / FIX Net / http://www.fix.net - -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: http://www.c2.org/~bryce/Niche.html 'BAP' Easy-PGP v1.1b2 iQCVAwUBNB1+IGm9zE6XY0w5AQHjAgP/cl5RUrGg6JeXnFh2DxgpD/RFp6zgjBT2 /OFxFQmmJqlx8cOqwmWAqgdMZtqlgUiRV4tOOpNyf/VcuqmsFXPHAUw5vkBPO+09 cwJzZscAnY2ln9RdX8JkIPZ9C6MG2xJHk1l4iANQRJucYpIOczwREbEJUT9GrAjd pMercFXJgK4= =GfEX -----END PGP SIGNATURE-----

> Then try setting DTMF tones on the modems instead of MF and ask your phone > to run a thorough checks on your T1s.. We just got our first TC rack a couple months ago, and a CT1 (B8ZS) through the local telco. We get horrible connect rates (sometimes as low as 9600 baud!) when people use the local telco. If they make a "long distance" call through AT&T, they can get 48k or 52k connect rates. It's definitely the local wiring. Calls to the telco have resulted in "we don't care" responses (and there's not much we can do, since the problem is the local lines for the users, not us). I'm kind of out of the loop on this one, but supposedly, USR is working with the telco to get better rates. All I can say is, good luck. The original poster's problem may be similar to ours. -- Brad Wilson KA8RJS bradw @ pobox.com http://www.thebrads.com Objectivist, Software Engineer (Win32, STL, MFC, and sockets spoken here) "Life begins at 128 ... megs of RAM ... gigs of drive space ..."

At 11:27 AM 9/15/97 -0700, you wrote: > Try dialing a PIC code (long distance carrier) in > front of your phone number (i.e. 10288xxx-xxxx) and see if the connect > speeds go up. If things improve, then you are in the same boat we are.. That is our exact problem with Ameritech. -- Brad Wilson KA8RJS bradw @ pobox.com http://www.thebrads.com Objectivist, Software Engineer (Win32, STL, MFC, and sockets spoken here) "Life begins at 128 ... megs of RAM ... gigs of drive space ..."

At 01:56 PM 9/13/97 -0400, you wrote: >Thus spake Jaye Mathisen >>We are switching from livingston PM's to TC racks wholesale here. > >>I could've sworn in my initial tests that it did, but now it appears it >>doesn't. I am not envious of the job of converting a whole truckload of >>customers to new dns numbers... :( > >Do a show global and at the bottom, if it says "Send DNS Info: On" or >something like that, then windoze95 should pick up the DNS info....*if* >its set to server assigned DNS servers. I saw no settings in netserver that allow the transmission of dns numbers or am i in the wrong place. i telneted in and did not see anything as well. thanks eric > Delaware Online!.........The SMART Choice! With 56K X2 Modems Phone : 302-762-0375 Fax: 302-762-3462 WWW: www.dol.net Eight out of five people have a problem understanding statistics! ****************Customer support is our bottom line!*********************

Thus spake eric@dol.net >At 01:56 PM 9/13/97 -0400, you wrote: >>Do a show global and at the bottom, if it says "Send DNS Info: On" or >>something like that, then windoze95 should pick up the DNS info....*if* >>its set to server assigned DNS servers. >I saw no settings in netserver that allow the transmission of dns numbers or >am i >in the wrong place. i telneted in and did not see anything as well. >thanks >eric Uhm...being a newcomer to the TC racks...I'm not sure at what version this feature was added...its possible that the version you are using is too old for that? (don't know what version you have)...we're on 3.5.34 (soon to move to 3.5.84 probably...more on that later) -- Jeff McAdams Email: jeffm@iglou.com Chief Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

-> At 11:27 AM 9/15/97 -0700, you wrote: -> > Try dialing a PIC code (long distance carrier) in -> > front of your phone number (i.e. 10288xxx-xxxx) and see if the connect > -> speeds go up. If things improve, then you are in the same boat we are.. -> That is our exact problem with Ameritech. I'll sneak in here a bit since I worked for MCI in one of their central offices for 8 years. One difference between a local and a long distance call is that the central office switch places a 6db pad on the receive side of the calling party's line at the calling CO and places a 6db pad on the receive side of the vcalled party at their CO (i.e. the call ends up having a 6db bidirectional pad on it). You might think this would make modem transmissions worse but often times it helps, at least with many of the older modems I ran across. Other than that the other difference is how the call is routed through the central offices but since they should all be trunk side connections, this shouldn't make a difference unless the LEC has a bad set of trunks somewhere. If you want to try and simulate the LD situation as far as levels go, see if you can change an option on the TC to drop your xmit level down 6db. Then see if the person calling can do the same. With X2 being so sensitive to the S/N ratio, this might do the trick. I've not checked to see if this option exists or not in the TCs. Just my 2 cents worth. Jeff Binkley ASA Network Computing

> I'll sneak in here a bit since I worked for MCI in one of their central offices > for 8 years. One difference between a local and a long distance call is that > the central office switch places a 6db pad on the receive side of the calling > party's line at the calling CO and places a 6db pad on the receive side of the > vcalled party at their CO (i.e. the call ends up having a 6db bidirectional > pad on it). Yes, I recall hearing this ... LD calls get a 6db boost, local calls get a 3db boost. They are saying that that is what the problem is. So, who's lying to us here? Did none of the 56k vendors check over local phone lines or what? Ameritech made it sound like every phone co in the nation uses the setup. -- Brad Wilson KA8RJS bradw @ pobox.com http://www.thebrads.com Objectivist, Software Engineer (Win32, STL, MFC, and sockets spoken here) "Life begins at 128 ... megs of RAM ... gigs of drive space ..."

Here is what John has to say about the X2 problem krish

Are there not two different flavors of B8ZS, Can this also effect the connect rates. We see average of 42K and many 33333 connects.

-> > I'll sneak in here a bit since I worked for MCI in one of their central -> offices -> > for 8 years. One difference between a local and a long distance call is -> that -> > the central office switch places a 6db pad on the receive side of the -> calling -> > party's line at the calling CO and places a 6db pad on the receive side of -> the -> > vcalled party at their CO (i.e. the call ends up having a 6db -> bidirectional > pad on it). -> -> Yes, I recall hearing this ... LD calls get a 6db boost, local calls get a -> 3db boost. They are saying that that is what the problem is. -> -> So, who's lying to us here? Did none of the 56k vendors check over local -> phone lines or what? Ameritech made it sound like every phone co in the -> nation uses the setup. Ameritech is correct but it's a 6db loss not boost. I'm not sure about the 3db loss on local calls. I thought local calling area padding was always 0db loss. What they may be referring to is the standard loop loss on a local analog line. In other words when you had a local analog line on your end, the standard expected loss is 3db (this assumes an average distance from the CO but losses can vary from about 1db up to about 8db, depending upon cable type and distance). I believe Ameritech may be adding a 3db standard pad on the digital PRI to compensate for having a digital trunk, which in itself is a lossless transmission medium. Anyway, in either case, I did find that under LINE INTERFACE OPTIONS there is a transmitter level option which is set for 9db. I believe this is actually a negative number (i.e. -9db) but the helpfile doesn't really say. The interesting thing is that the helpfile documentation says the default should be 11 where mine are set at 9. 11 sounds right to me since modems generally are at a -8db point (at least analog modems were) and then a 3db pad would make -11. You might try this or see what your end looks like. Maybe USR/3COM can jump in here. Jeff Binkley ASA Network Computing

-> > I'll sneak in here a bit since I worked for MCI in one of their central -> offices -> > for 8 years. One difference between a local and a long distance call is -> that -> > the central office switch places a 6db pad on the receive side of the -> calling -> > party's line at the calling CO and places a 6db pad on the receive side of -> the -> > vcalled party at their CO (i.e. the call ends up having a 6db -> bidirectional > pad on it). -> -> Yes, I recall hearing this ... LD calls get a 6db boost, local calls get a -> 3db boost. They are saying that that is what the problem is. -> -> So, who's lying to us here? Did none of the 56k vendors check over local -> phone lines or what? Ameritech made it sound like every phone co in the -> nation uses the setup. Ameritech is correct but it's a 6db loss not boost. I'm not sure about the 3db loss on local calls. I thought local calling area padding was always 0db loss. What they may be referring to is the standard loop loss on a local analog line. In other words when you had a local analog line on your end, the standard expected loss is 3db (this assumes an average distance from the CO but losses can vary from about 1db up to about 8db, depending upon cable type and distance). I believe Ameritech may be adding a 3db standard pad on the digital PRI to compensate for having a digital trunk, which in itself is a lossless transmission medium. Anyway, in either case, I did find that under LINE INTERFACE OPTIONS there is a transmitter level option which is set for 9db. I believe this is actually a negative number (i.e. -9db) but the helpfile doesn't really say. The interesting thing is that the helpfile documentation says the default should be 11 where mine are set at 9. 11 sounds right to me since modems generally are at a -8db point (at least analog modems were) and then a 3db pad would make -11. You might try this or see what your end looks like. Maybe USR/3COM can jump in here. Jeff Binkley ASA Network Computing

On Tue, 16 Sep 1997, Jeff Binkley wrote: > -> > I'll sneak in here a bit since I worked for MCI in one of their central > -> offices > -> > for 8 years. One difference between a local and a long distance call is > -> that > -> > the central office switch places a 6db pad on the receive side of the > -> calling > -> > party's line at the calling CO and places a 6db pad on the receive side of > -> the > -> > vcalled party at their CO (i.e. the call ends up having a 6db > -> bidirectional > pad on it). > -> > -> Yes, I recall hearing this ... LD calls get a 6db boost, local calls get a > -> 3db boost. They are saying that that is what the problem is. > -> > -> So, who's lying to us here? Did none of the 56k vendors check over local > -> phone lines or what? Ameritech made it sound like every phone co in the > -> nation uses the setup. > > Ameritech is correct but it's a 6db loss not boost. I'm not sure about the 3db > loss on local calls. I thought local calling area padding was always 0db loss. > What they may be referring to is the standard loop loss on a local > analog line. In other words when you had a local analog line on your > end, the standard expected loss is 3db (this assumes an average distance > from the CO but losses can vary from about 1db up to about 8db, > depending upon cable type and distance). I believe Ameritech may be > adding a 3db standard pad on the digital PRI to compensate for having a > digital trunk, which in itself is a lossless transmission medium. Anyway, in > either case, I did find that under LINE INTERFACE OPTIONS there is a > transmitter level option which is set for 9db. I believe this is actually a > negative number (i.e. -9db) but the helpfile doesn't really say. The > interesting thing is that the helpfile documentation says the default should be > 11 where mine are set at 9. 11 sounds right to me since modems generally are > at a -8db point (at least analog modems were) and then a 3db pad would make > -11. You might try this or see what your end looks like. Maybe USR/3COM can > jump in here. > > Jeff Binkley > ASA Network Computing > How about taking some measurements from the modems themselves? That is if the digital couriers support ATI11 to report the line parameters. Here's an example from an analog courier: ATI11^M USRobotics Courier V.Everything Link Diagnostics... Modulation V.34+ Carrier Freq ( Hz ) 1959/1959 Symbol Rate 3429/3429 Trellis Code 64S-4D/64S-4D Nonlinear Encoding ON/ON Precoding ON/ON Shaping ON/ON Preemphasis (-dB ) 8/8 Recv/Xmit Level (-dBm) 25.5/11.4 SNR ( dB ) 33.2 Near Echo Loss ( dB ) 14.5 Far Echo Loss ( dB ) 20.9 Roundtrip Delay (msec) 4 ========================================================================= Jeffrey A. Lynch, President 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

At 11:39 PM 9/15/97 -0500, you wrote: >Here is what John has to say about the X2 problem > >krish > >-------------------- > All, > > You folks are definitely on the right track as far as the pads go. As > far as transmit levels go, leave them at default. Are these pads the same as a slick? Here in USWest land, where life is better, we have run into large areas around Casper that can't get x2 connects because of these slicks. I hear that they are like a multiplexor, they allow the telco to run many more calls over existing buried copper pairs but put a a-d conversion in there too. The conversion knocks out the x2 and we lose a lot of potential customers. Greg Coffey, CoffeyNet 142 S. Center St. ** $20 local Casper USR x2 56k access ** Casper, WY 82601 Wheatland, Pinedale, Lander, Lusk http://www.coffey.com Douglas & Rawlins (307) 234-5443

This is what I am seeing. When dialling from home... If I dial the USR linetest number (long-distance) manually, I get a proper X2 connection. I can also dial Netcom's 800 number and get a good X2 connection. When I dial locally to my TC rack, I negotiate X2 but the connection starts and stops and is quite useless. I also dialled Netcom's local number and saw the same behaviour so I guess my TC config is okay. When dialling from my office (off-campus, through Bell and back in to the rack) I get great X2 connections. I am going to call my Bell contact and see what (if anything) can be done. I'll post when I get an answer from them. > Colin McFadyen > Carleton University CCS > 409 Robertson Hall > voice: 613-520-2600 ext. 3721 fax: 613-520-4448 > > > ---------- > From: Brad Wilson[SMTP:bradw@thebrads.com] > Reply To: usr-tc@mail.xmission.com > Sent: Monday, September 15, 1997 1:13 PM > To: usr-tc@mail.xmission.com > Subject: RE: (usr-tc) X2 upgrade problem > > > Then try setting DTMF tones on the modems instead of MF and ask your > phone > > to run a thorough checks on your T1s.. > > We just got our first TC rack a couple months ago, and a CT1 (B8ZS) > through > the local telco. We get horrible connect rates (sometimes as low as > 9600 > baud!) when people use the local telco. If they make a "long > distance" > call through AT&T, they can get 48k or 52k connect rates. It's > definitely > the local wiring. > > Calls to the telco have resulted in "we don't care" responses (and > there's > not much we can do, since the problem is the local lines for the > users, not > us). I'm kind of out of the loop on this one, but supposedly, USR is > working with the telco to get better rates. All I can say is, good > luck. > The original poster's problem may be similar to ours. > > -- > Brad Wilson KA8RJS bradw @ pobox.com > http://www.thebrads.com > Objectivist, Software Engineer (Win32, STL, MFC, and sockets spoken > here) > "Life begins at 128 ... megs of RAM ... gigs of drive space ..." > >

I called USR support and they said that the local vs. long-distance X2 trouble was a known problem and that I would have to resolve it with my telco. The support person could not give me any details as to just what needs to be resolved. So far, Bell has no idea what I am talking about. > Colin McFadyen > Carleton University CCS > 409 Robertson Hall > voice: 613-520-2600 ext. 3721 fax: 613-520-4448 >

I had to 'erase flash' this morning to clear some routing problems, and after reconfiguring everything I'm left with one problem. Regardless of what username is entered manually at the login prompt when dialing up, the netserver automatically starts a telnet session to the default host without asking for a password. The way I had it before was with the radius server being contacted, and a PPP session started by default. In any case, the radius server was always contacted for authentication -- unless it was a local netserver user. `show radius` tells me both Login and Password are enabled. I have the radius secret set properly, and CHAP users log in just fine. What am I missing? - lv

Sounds like you should set the ports security. From the netserver... set snn security on (nn = port number) If the username/password are not found in the netserver user table, the netserver will check with the radius server to validate the user. > Colin McFadyen > Carleton University CCS > 409 Robertson Hall > voice: 613-520-2600 ext. 3721 fax: 613-520-4448 > > > ---------- > From: Laszlo Vecsey[SMTP:master@internexus.net] > Reply To: usr-tc@mail.xmission.com > Sent: Tuesday, September 16, 1997 11:57 AM > To: usr-tc@xmission.com > Subject: (usr-tc) Login/Netwrk - defaults to host login instead > of PPP > > I had to 'erase flash' this morning to clear some routing problems, > and > after reconfiguring everything I'm left with one problem. Regardless > of > what username is entered manually at the login prompt when dialing up, > the > netserver automatically starts a telnet session to the default host > without asking for a password. > > The way I had it before was with the radius server being contacted, > and a > PPP session started by default. In any case, the radius server was > always > contacted for authentication -- unless it was a local netserver user. > > `show radius` tells me both Login and Password are enabled. I have the > radius secret set properly, and CHAP users log in just fine. What am I > missing? > > - lv > >

All, You folks are definitely on the right track as far as the pads go. As far as transmit levels go, leave them at default, it has no effect on this topic (and may hurt things if you mess with it). Let me explain the pad situation. As a rule, a 3db pad is inserted on the "egress" from the network in both directions on a local call, 6db on an LD call (definition of what is "LD" varies). This is definitely "loss" not "gain". In the US, loop loss is not considered in the calculation (it is in some other countries). It is there as an echo deterrent. Padding complements the normal echo cancellation in a voice call, but does not get shut off with a 2100hz tone like the other stuff is. So, in the x2 path, the pad we normally need to deal with is on the CO serving the x2 analog user. This pad can be digital or analog. the spec does not care. Analog pads do not affect x2 much (unless they are collossal, then they may cause signal starvation). Digital pads, on the other hand, mess with our precious bits, and will cause x2 (or K56) to choke if they are not arithmetically compensated for. Unfortunately, the switch vendors did not collaborate on these, and each one appears to have derived their own scheme for manipulating the bits to achieve the desired loss. Each scheme requires a different algorithm in the modems to deal with it. We definitely tested x2 on local calls, and compensate for many 3db pads. If we didn't, x2 would not function in a vast majority of the US and Canada, and I would be looking for a new job (I can hear it now..."Welcome to McDonalds, would you like to try our Big Mac combo meal today"). If you were dealing with a digital pad (on the CO serving the analog user) that is not supported, some of your users would work fine, but those on the CO with the unsupported pad would fail (usually 33333 connects with lots of errors, or painful sounding training and fallback to V.34). More likely (though rare) is that the Telco has put a pad on the "ingress" to the network on your T-span. In other words, they are applying a digital pad in the x2 path coming from your chassis. I have yet to figure out the reason for this (I don't think there is a good one), but I have seen it. This pad may only be applied on local calls, or may be applied on all calls, so chasing it can be difficult. This creates a very complex environment with "cascading" digital pads, and is extremely difficult to compensate for mathenatically. I need to emphasize, this is rare, particularly if "trunk-side" service was requested. The symptoms would be pretty much the same as in the previous paragraph. The bottom line is that the telco should ensure that there are no pads on the ingress to the network from your chassis (the x2 path). These are out of spec and serve no purpose. While they are at it, try to convince them to remove even egress pads (on the span to your chassis). You will likely see an improvement on the backchannel for both x2 and V.34 users. Our digital modems can handle the hotter signal, and take advantage of it (may give you a speed click or two improvement). The spec calls for these to reduce echo, but echo is not an issue on digital spans, and the modems have their own echo cancellation anyway. We are working (actually testing in our labs) a new pad detection scheme that should overcome any digital pad (in, or out of, spec). Even with that, the less pads in the path the better (either direction), so getting rid of all pads on your spans will benefit all of your users (x2 and V.34). If any of you (ISPs, etc.) are interested in participating in beta, and you have a non-production chassis, please contact me directly. I hope this helps your understanding, and dispels any myths or confusion. It is definitely a complicated topic, so the confusion is definitely justified. Regards, John Powell <jpowell@usr.com> PS. Note, I am not on this listserver, so I will not see any responses directed only to this list. Sorry. ---------- Forwarded message ---------- -> > I'll sneak in here a bit since I worked for MCI in one of their central -> offices -> > for 8 years. One difference between a local and a long distance call is -> that -> > the central office switch places a 6db pad on the receive side of the -> calling -> > party's line at the calling CO and places a 6db pad on the receive side of -> the -> > vcalled party at their CO (i.e. the call ends up having a 6db -> bidirectional > pad on it). -> -> Yes, I recall hearing this ... LD calls get a 6db boost, local calls get a -> 3db boost. They are saying that that is what the problem is. -> -> So, who's lying to us here? Did none of the 56k vendors check over local -> phone lines or what? Ameritech made it sound like every phone co in the -> nation uses the setup. Ameritech is correct but it's a 6db loss not boost. I'm not sure about the 3db loss on local calls. I thought local calling area padding was always 0db loss. What they may be referring to is the standard loop loss on a local analog line. In other words when you had a local analog line on your end, the standard expected loss is 3db (this assumes an average distance from the CO but losses can vary from about 1db up to about 8db, depending upon cable type and distance). I believe Ameritech may be adding a 3db standard pad on the digital PRI to compensate for having a digital trunk, which in itself is a lossless transmission medium. Anyway, in either case, I did find that under LINE INTERFACE OPTIONS there is a transmitter level option which is set for 9db. I believe this is actually a negative number (i.e. -9db) but the helpfile doesn't really say. The interesting thing is that the helpfile documentation says the default should be 11 where mine are set at 9. 11 sounds right to me since modems generally are at a -8db point (at least analog modems were) and then a 3db pad would make -11. You might try this or see what your end looks like. Maybe USR/3COM can jump in here. Jeff Binkley ASA Network Computing

On Tue, 16 Sep 1997, Rick Payne wrote: > >>>>> "Laszlo" == Laszlo Vecsey <master@internexus.net> writes: > > Laszlo> The way I had it before was with the radius server being > Laszlo> contacted, and a PPP session started by default. In any case, > Laszlo> the radius server was always contacted for authentication -- > Laszlo> unless it was a local netserver user. > > Have you "set all security on"? > That was it, thanks for the speedy response guys! Only thing faster would be a real time #usr-tc chat channel ;) - lv

-> At 11:39 PM 9/15/97 -0500, you wrote: -> >Here is what John has to say about the X2 problem -> > -> >krish -> > -> >-------------------- -> > All, -> > -> > You folks are definitely on the right track as far as the pads go. As -> > far as transmit levels go, leave them at default. -> -> Are these pads the same as a slick? Here in USWest land, where life is -> better, we have run into large areas around Casper that can't get x2 -> connects because of these slicks. I hear that they are like a multiplexor, -> they allow the telco to run many more calls over existing buried copper -> pairs but put a a-d conversion in there too. The conversion knocks out the -> x2 and we lose a lot of potential customers. Apples and oranges. SLC (Subscriber Line Carrier) is nothing more than a reconfiguration of standard T-1s. The telcos use SLC (96 voice channels) to haul line side connections further from the CO. Thus they have 2 A/D conversions since the call comes out of the switch 2 wire, gets converted to 4 wire on the input side and then back to 2 wire at the subscriber side. Digital pads are nothing more than digital algorithms built into the digital switches to insert the equivalent of analog loss into calls. They were originaly designed to allow interoperability with analog switch and transmission plans. Jeff Binkley ASA Network Computing

> Are these pads the same as a slick? Here in USWest land, where life is > better, we have run into large areas around Casper that can't get x2 > connects because of these slicks. I hear that they are like a multiplexor, > they allow the telco to run many more calls over existing buried copper > pairs but put a a-d conversion in there too. The conversion knocks out the > x2 and we lose a lot of potential customers. No, it sounds like what they're using is emergency multiplexors. These devices are meant to -temporarily- multiplex more calls on a trunk, at a significant loss of call quality. They're really only meant for emergency situations (like an earthquake takes out some of your trunks). I've heard of phone co's doing this; it's pretty slimey, since it not only stops X2, but your customers probably get terrible connects rates, period. -- Brad Wilson KA8RJS bradw @ pobox.com http://www.thebrads.com Objectivist, Software Engineer (Win32, STL, MFC, and sockets spoken here) "Life begins at 128 ... megs of RAM ... gigs of drive space ..."

Hey, This might sound like a stupid question, however... How do I create the following filter on net0? input: deny icmp any any permit udp 1.2.3.4/32 0.0.0.0 eq 520 deny udp 0.0.0.0/0 0.0.0.0/0 eq 520 permit ip any any output: deny icmp any any: deny tcp 0.0.0.0/0 0.0.0.0/0 eq 139 deny tcp 0.0.0.0/0 0.0.0.0/0 eq 137 permit ip any any Thanks Garry Shtern shterng@akula.com Chief Network Administrator http://www.akula.com Akula Communications Corp. tel. (212) 292-8892

You are correct, with one critical addition. There are two kinds of SLCs, Universal and Integrated. What you describe is a Universal. More common is an Integrated SLC, which comes out of the switch and to the street corner as pure digital. Essentially the digital network has been extended to within a few hundred feet (or so) of the enduser. As the analog portion of the network is the most susceptible to noise, this is a very good thing indeed. Extensive testing of the network, confirmed by studies done by independent sources have determined that approximately 5 percent of the analog lines in the US are served by Universal SLCs or other situations that insert additional A/D conversions. There is a small connection between SLCs and digital pads. As there is no mechanism for the switch to signal the SLC what analog pad level to insert in the hybrid, digital padding is almost always the method used (as it can be done in the switch). Analog pads are only used when the analog line is served directly off the switch's line card. JP ---------- Forwarded message ---------- -> At 11:39 PM 9/15/97 -0500, you wrote: -> >Here is what John has to say about the X2 problem -> > -> >krish -> > -> >-------------------- -> > All, -> > -> > You folks are definitely on the right track as far as the pads go. As -> > far as transmit levels go, leave them at default. -> -> Are these pads the same as a slick? Here in USWest land, where life is -> better, we have run into large areas around Casper that can't get x2 -> connects because of these slicks. I hear that they are like a multiplexor, -> they allow the telco to run many more calls over existing buried copper -> pairs but put a a-d conversion in there too. The conversion knocks out the -> x2 and we lose a lot of potential customers. Apples and oranges. SLC (Subscriber Line Carrier) is nothing more than a reconfiguration of standard T-1s. The telcos use SLC (96 voice channels) to haul line side connections further from the CO. Thus they have 2 A/D conversions since the call comes out of the switch 2 wire, gets converted to 4 wire on the input side and then back to 2 wire at the subscriber side. Digital pads are nothing more than digital algorithms built into the digital switches to insert the equivalent of analog loss into calls. They were originaly designed to allow interoperability with analog switch and transmission plans. Jeff Binkley ASA Network Computing

Has anyone gotten anyone with a MP2000 to connect to the USRTC? If so maybe you can tell me all that is needed to be done......Thanks. Brian /-------------------------- signal@shreve.net -----------------------------\ | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | | Systems Administrator | Perl, Linux | Web hosting, online stores, | | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | | 89 CRX, Akimoto intake, DC |-=*:Quake:*=-| http://www.shreve.net/ | | headers, Eurosport exhaust |LordSignal/SN| Quake server: 208.206.76.3 | \-------------------------- 318-222-2638 x109 -----------------------------/

>>>>> "Colin" == Colin McFadyen <ColinMcFadyen@pigeon.carleton.ca> writes: Colin> I called USR support and they said that the local Colin> vs. long-distance X2 trouble was a known problem and that I Colin> would have to resolve it with my telco. The support person Colin> could not give me any details as to just what needs to be Colin> resolved. So far, Bell has no idea what I am talking about. I believe its to do with the DMS-100 switches (though my memory could be wrong here). Rick -- Rick Payne, Senior Network Admin | Meddle not in the affairs of NETCOM Internet Ltd. | dragons - for you are crunchy & rickp@corp.netcom.net.uk | taste great dipped in chocolate.

>>>>> "Laszlo" == Laszlo Vecsey <master@internexus.net> writes: Laszlo> The way I had it before was with the radius server being Laszlo> contacted, and a PPP session started by default. In any case, Laszlo> the radius server was always contacted for authentication -- Laszlo> unless it was a local netserver user. Have you "set all security on"? Rick -- Rick Payne, Senior Network Admin | Meddle not in the affairs of NETCOM Internet Ltd. | dragons - for you are crunchy & rickp@corp.netcom.net.uk | taste great dipped in chocolate.

U>> Are these pads the same as a slick? Here in USWest land, where life U>> is better, we have run into large areas around Casper that can't U>> get x2 connects because of these slicks. I hear that they are like U>> a multiplexor, they allow the telco to run many more calls over U>> existing buried copper pairs but put a a-d conversion in there too. U>> The conversion knocks out the x2 and we lose a lot of potential U>> customers. U>No, it sounds like what they're using is emergency multiplexors. U>These devices are meant to -temporarily- multiplex more calls on a U>trunk, at a significant loss of call quality. They're really only U>meant for emergency situations (like an earthquake takes out some of U>your trunks). I've heard of phone co's doing this; it's pretty U>slimey, since it not only stops X2, but your customers probably get U>terrible connects rates, period. I believe you are referring to ADPCM equipment. This equipment allows you to have 44 voice channels on a single T-1 as opposed to 24 channels. This is done through adaptive sampling of the analog to digital conversion as opposed to the standard 8k rate/8 bit standard PCM conversion which is done on standard T-1 carrier systems. I hope most LECs aren't using these any longer. I saw them mostly being used in the early years of the long distance companies who were short on backbone bandwidth. Jeff Binkley ASA Network Computing CMPQwk 1.42 9999

I been following this list for some time and am a little leary of posting such junior questions. Anyway, here it is. We have a TC rack, when we purchased it, we had no RADIUS server and didn't know much about. One of our system admin's set a public domain radius server on our SCO server. The problem is that when logging into the USR-tc rack no password is required. You have to be a user on our system, it just doesn't care what password you use. I don't have the ppp authentication checked in the global setup. Is this ness. or is our Radius server just screwed up. The latter is more probable... Any good Radius programmers out need some work? Terry Kennedy Olypen, Inc. terry@olypen.com

The total service web site is now pushing out an e-mail newsletter customized for the hardware that you have.. This may give those of you that are looking for new code and beta announcements what you have been asking for.. Check it out.. I don't think that you have to have a service agreement to use this service.. Just register with the site. -Mike `'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`' Mike Wronski(mwronski@coredump.ae.usr.com) 3Com/U.S.Robotics Network Systems Engineer PGP: http://coredump.ae.usr.com/pgp

We are having the same problem. I have checked with the Telco, (Ameritech) and confirmed that there are no digital padding on our PRI. What else could be wrong? We have seen MAJORITY of our users not being able to login to our chassis with any decent X2 speed locally and those same people CAN log in to another provider fine (Getting connect speed of 48000~). very small minority of the users can dial in to our chassis fine locally. Of course, almost anyone dialing in long distance can log in fine also. I have a ticket open at USR for over a month and keeping in touch with the tech regulary and have not gotten any fixes yet. At 11:39 PM 9/15/97 -0500, you wrote: >Here is what John has to say about the X2 problem > >krish > >-------------------- > All, > > You folks are definitely on the right track as far as the pads go. As > far as transmit levels go, leave them at default. > > Let me explain the pad situation. As a rule, a 3db pad is inserted on > the "egress" from the network in both directions on a local call, 6db > on a LD call (definition of LD varies). This is definitely "loss" not > "gain". In the US, loop loss is not considered in the calculation (it > is in some other countries). It is there as an echo deterrent. > Padding complements the normal echo cancellation in a voice call, but > does not get shut off with a 2100hz tone like the other stuff is. So, > in the x2 path, the pad we normally need to deal with is on the CO > serving the x2 analog user. > > This pad can be digital or analog. the spec does not care. Analog > pads do not affect x2 much (unless they are collossal, then they may > cause signal starvation). Digital pads, on the other hand, mess with > our precious bits, and will cause x2 (or K56) to choke if they are not > arithmetically compensated for. Unfortunately, the switch vendors did > not collaborate on these, and each one appears to have derived their > own scheme for manipulating the bits to achieve the desired loss. > Each scheme requires a different algorithm to deal with it. > > We definitely tested x2 on local calls, and compensate for many 3db > pads. If we didn't, x2 would not function in a vast majority of the > US and Canada (Europe and elsewhere are mostly analog pads), and I > would be looking for a new job ("Welcome to McDonalds, would you like > to try our Big Mac combo meal today"). > > If you were dealing with a digital pad (on the CO serving the analog > user) that is not supported, some of your users would work fine, but > those on the CO with the unsupported pad would fail (usually 33333 > connects with lots of errors, or painful sounding training and > fallback to V.34). > > More likely (though rare) is that the Telco has put a pad on the > "ingress" to the network on your T-span. In other words, they are > applying a digital pad in the x2 path coming from your chassis. I > have yet to figure out the reason for this (I don't think there is a > good one), but I have seen it. This pad may only be applied on local > calls, or may be applied on all calls, so chasing it can be difficult. > This creates a very complex environment with "cascading" digital pads, > and is extremely difficult to compensate for mathenatically. I need > to emphasize, this is rare, particularly if "trunk-side" service was > requested. > > The bottom line is that the telco should ensure that there are no pads > on the ingress to the network from your chassis (the x2 path). These > are out of spec and serve no purpose. While they are at it, try to > convince them to remove even egress pads (on the span to your > chassis). You will likely see an improvement on the backchannel for > both x2 and V.34 users. Our digital modems can handle the hotter > signal, and take advantage of it (may give you a speed click or two > improvement). The spec calls for these to reduce echo, but echo is not > an issue on digital spans, and the modems have their own echo > cancellation anyway. > > We are working (actually testing in our labs) a new pad detection > scheme that should overcome any digital pad (in, or out of, spec). > Even with that, the less pads in the path the better (either > direction), so getting rid of all pads on your spans will benefit all > of your users (x2 and V.34). > > I hope this helps your understanding, and dispels any myths or > confusion. > > Regards, > > John Powell <jpowell@usr.com> J.S. Nakamura -- Kiva Networking -- Phone (812)337-5070 -- Fax (812)337-5082 jnakamur@kiva.net

At 04:22 PM 9/16/97 -0500, you wrote: > You are correct, with one critical addition. There are two kinds of > SLCs, Universal and Integrated. What you describe is a Universal. > More common is an Integrated SLC, which comes out of the switch and to > the street corner as pure digital. Essentially the digital network > has been extended to within a few hundred feet (or so) of the enduser. > As the analog portion of the network is the most susceptible to noise, > this is a very good thing indeed. So are these things normal? Seems like half the town is on them and I've heard the same things from other ISP's in USelessWest Land. Should I be fighting with the telco or the PSC to get them removed? I have some clout with the PSC. Some of the comments call them slimey or temp fixes. As far as I know, they are here for the duration. I live in an area that doesn't work with x2 now. I call the x2 test line from home and it tells me over 50% of the time that x2 should work, perhaps not well but should work. I've never got a x2 connect from there to my site or anywhere else. I tried to find someone at USR to interpret the data from the test calls but no luck. Is there anyone available at USR to analyze the data and hopefully make this work in more areas? I can get maps of the SLC's in the immediate area. Thanks, Greg Coffey 307-234-5443 CoffeyNet *** $20 56k x2 USR Casper Access *** Casper, Pinedale, Douglas, Wheatland, Rawlins, Lander & Lusk Wy www.coffey.com

At 11:07 AM 9/17/97 -0500, you wrote: >The total service web site is now pushing out an e-mail newsletter >customized for the hardware that you have.. This may give those of >you that are looking for new code and beta announcements what you have >been asking for.. Check it out.. I don't think that you have to have >a service agreement to use this service.. Just register with the site. > >-Mike > To avoid some confusion I caused, the totalservice website is http://totalservice.usr.com.. -M `'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`' Mike Wronski(mwronski@coredump.ae.usr.com) 3Com/U.S.Robotics Network Systems Engineer PGP: http://coredump.ae.usr.com/pgp

At 10:30 AM 9/17/97 -0700, you wrote: >I been following this list for some time and am a little >leary of posting such junior questions. Anyway, here it >is. We have a TC rack, when we purchased it, we had >no RADIUS server and didn't know much about. One of >our system admin's set a public domain radius server on >our SCO server. The problem is that when logging into the >USR-tc rack no password is required. You have to be a user >on our system, it just doesn't care what password you use. >I don't have the ppp authentication checked in the global setup. >Is this ness. or is our Radius server just screwed up. The latter >is more probable... > You didn't give too much information but check the following.. 1) Make sure you set security on the modem ports on.. 'set all security on' or 'set s5-s61 security on' 'save all' 'reset all' 2) Make sure your radius clients file has your netservers IP listed and a secret is set. Also check that the netserver is pointing to that radius server and has the matching secret. If these don't work.. Send me another letter and we can get more specific.. -Mike `'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`' Mike Wronski(mwronski@coredump.ae.usr.com) 3Com/U.S.Robotics Network Systems Engineer PGP: http://coredump.ae.usr.com/pgp

> ---------- > From: jpowell@usr.com[SMTP:jpowell@usr.com] > Reply To: usr-tc@mail.xmission.com > Sent: Tuesday, September 16, 1997 1:14 PM > To: usr-tc@mail.xmission.com > Subject: Re: (usr-tc) RE: (USR-TC) X2 UPGRADE PROBLEM (fwd) > > We are working (actually testing in our labs) a new pad detection > > scheme that should overcome any digital pad (in, or out of, > spec). > Even with that, the less pads in the path the better (either > direction), so getting rid of all pads on your spans will benefit > all > of your users (x2 and V.34). If any of you (ISPs, etc.) are > interested in participating in beta, and you have a > non-production > chassis, please contact me directly. > I have a rack that will not be going into production for at least a week. If I can help test the new pad detection code, please let me know. > Colin McFadyen > Carleton University CCS > 409 Robertson Hall > voice: 613-520-2600 ext. 3721 fax: 613-520-4448 > >

Since the USR/3COM I-TEAM will order the circuits and work with the telco, shouldn't they be able to resolve all these issues? The I-TEAM should have a substantial database by now on what typical switching equipment and telco provisioning exhibit problems and how to get around them. ========================================================================= Jeffrey A. Lynch, President 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 Tue, 16 Sep 1997 jpowell@usr.com wrote: > All, > > You folks are definitely on the right track as far as the pads go. As > far as transmit levels go, leave them at default, it has no effect on > this topic (and may hurt things if you mess with it). > > Let me explain the pad situation. As a rule, a 3db pad is inserted on > the "egress" from the network in both directions on a local call, 6db > on an LD call (definition of what is "LD" varies). This is definitely > "loss" not "gain". In the US, loop loss is not considered in the > calculation (it is in some other countries). It is there as an echo > deterrent. Padding complements the normal echo cancellation in a > voice call, but does not get shut off with a 2100hz tone like the > other stuff is. So, in the x2 path, the pad we normally need to deal > with is on the CO serving the x2 analog user. > > This pad can be digital or analog. the spec does not care. Analog > pads do not affect x2 much (unless they are collossal, then they may > cause signal starvation). Digital pads, on the other hand, mess with > our precious bits, and will cause x2 (or K56) to choke if they are not > arithmetically compensated for. Unfortunately, the switch vendors did > not collaborate on these, and each one appears to have derived their > own scheme for manipulating the bits to achieve the desired loss. > Each scheme requires a different algorithm in the modems to deal with > it. > > We definitely tested x2 on local calls, and compensate for many 3db > pads. If we didn't, x2 would not function in a vast majority of the > US and Canada, and I would be looking for a new job (I can hear it > now..."Welcome to McDonalds, would you like to try our Big Mac combo > meal today"). > > If you were dealing with a digital pad (on the CO serving the analog > user) that is not supported, some of your users would work fine, but > those on the CO with the unsupported pad would fail (usually 33333 > connects with lots of errors, or painful sounding training and > fallback to V.34). > > More likely (though rare) is that the Telco has put a pad on the > "ingress" to the network on your T-span. In other words, they are > applying a digital pad in the x2 path coming from your chassis. I > have yet to figure out the reason for this (I don't think there is a > good one), but I have seen it. This pad may only be applied on local > calls, or may be applied on all calls, so chasing it can be difficult. > This creates a very complex environment with "cascading" digital pads, > and is extremely difficult to compensate for mathenatically. I need > to emphasize, this is rare, particularly if "trunk-side" service was > requested. The symptoms would be pretty much the same as in the > previous paragraph. > > The bottom line is that the telco should ensure that there are no pads > on the ingress to the network from your chassis (the x2 path). These > are out of spec and serve no purpose. While they are at it, try to > convince them to remove even egress pads (on the span to your chassis). > You will likely see an improvement on the backchannel for both x2 and > V.34 users. Our digital modems can handle the hotter signal, and take > advantage of it (may give you a speed click or two improvement). The > spec calls for these to reduce echo, but echo is not an issue on > digital spans, and the modems have their own echo cancellation anyway. > > We are working (actually testing in our labs) a new pad detection > scheme that should overcome any digital pad (in, or out of, spec). > Even with that, the less pads in the path the better (either > direction), so getting rid of all pads on your spans will benefit all > of your users (x2 and V.34). If any of you (ISPs, etc.) are > interested in participating in beta, and you have a non-production > chassis, please contact me directly. > > I hope this helps your understanding, and dispels any myths or > confusion. It is definitely a complicated topic, so the confusion > is definitely justified. > > Regards, > > John Powell <jpowell@usr.com> > > PS. Note, I am not on this listserver, so I will not see any responses > directed only to this list. Sorry. > > ---------- Forwarded message ---------- > Date: Tue, 16 Sep 1997 02:33:00 -0500 > From: Jeff Binkley <jeff.binkley@asacomp.com> > To: USR-TC@MAIL.XMISSION.COM > Subject: (usr-tc) RE: (USR-TC) X2 UPGRADE PROBLEM > > -> > I'll sneak in here a bit since I worked for MCI in one of their central > -> offices > -> > for 8 years. One difference between a local and a long distance call is > -> that > -> > the central office switch places a 6db pad on the receive side of the > -> calling > -> > party's line at the calling CO and places a 6db pad on the receive side of > -> the > -> > vcalled party at their CO (i.e. the call ends up having a 6db > -> bidirectional > pad on it). > -> > -> Yes, I recall hearing this ... LD calls get a 6db boost, local calls get a > -> 3db boost. They are saying that that is what the problem is. > -> > -> So, who's lying to us here? Did none of the 56k vendors check over local > -> phone lines or what? Ameritech made it sound like every phone co in the > -> nation uses the setup. > > Ameritech is correct but it's a 6db loss not boost. I'm not sure about the 3db > loss on local calls. I thought local calling area padding was always 0db loss. > What they may be referring to is the standard loop loss on a local > analog line. In other words when you had a local analog line on your > end, the standard expected loss is 3db (this assumes an average distance > from the CO but losses can vary from about 1db up to about 8db, > depending upon cable type and distance). I believe Ameritech may be > adding a 3db standard pad on the digital PRI to compensate for having a > digital trunk, which in itself is a lossless transmission medium. Anyway, in > either case, I did find that under LINE INTERFACE OPTIONS there is a > transmitter level option which is set for 9db. I believe this is actually a > negative number (i.e. -9db) but the helpfile doesn't really say. The > interesting thing is that the helpfile documentation says the default should be > 11 where mine are set at 9. 11 sounds right to me since modems generally are > at a -8db point (at least analog modems were) and then a 3db pad would make > -11. You might try this or see what your end looks like. Maybe USR/3COM can > jump in here. > > Jeff Binkley > ASA Network Computing > >

On Wed, 17 Sep 1997, Brian wrote: > > I hate to keep asking about this.......I mean I had MPIP working right at > one time, but its just not working for me, and I am not sure what I am > doing wrong, so let me just tell you what I am doing: > > hub #1 208.214.44.2 CLIENT/SERVER > hub #2 208.214.44.53 CLIENT > hub #3 208.214.44.104 CLIENT > > > hub #1: > set mpipserver 1 208.214.44.2 secret > set time_server 1 208.206.76.2 > reset time > save all > hub #2: > set mpipserver 1 208.214.44.2 secret > set time_server 1 208.206.76.2 > reset time > save all set mpipserver off > hub #3: > set mpipserver 1 208.214.44.2 secret > set time_server 1 208.206.76.2 > reset time > save all > set mpipserver off > hub #1: > set mpipserver on > add mpipclient 208.214.44.2 secret > add mpipclient 208.214.44.53 secret > add mpipclient 208.214.44.104 secret > save all > Check the time on all the NETServer - they should match. Also check your syslog, It will give you indications on what is happening when you place a mpip call. krish > > > sh mp on all servers reveals MPP is enabled. ISDN/MPP works flawlessly on > all hubs. MPIP does not work however. Is there something I am doing wrong > in configuring? Have I left something out? Should I reboot netserver? > > /-------------------------- signal@shreve.net -----------------------------\ > | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | > | Systems Administrator | Perl, Linux | Web hosting, online stores, | > | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | > | 89 CRX, Akimoto intake, DC |-=*:Quake:*=-| http://www.shreve.net/ | > | headers, Eurosport exhaust |LordSignal/SN| Quake server: 208.206.76.3 | > \-------------------------- 318-222-2638 x109 -----------------------------/ > > >

On Wed, 17 Sep 1997, Brian wrote: > The USR TC hubs support STAC compression. > > How can you tell if STAC compression is being used on a link? Is there a > way via tcm or netserver card to view this information? > > Is there anything you have to set to enable STAC compression, either in > tcm or radius? > > Brian > set ccp stac This is the command to enable stack compression krish \ T.S.V. Krishnan \ \ Network System Engineer \ ( : - : ) \ 3Com ............ \ ----------------------------------------------/ tkrishna@bubba.ae.usr.com ----------------------------/ http://interproc.ae.usr.com ----/ Any Sufficiently advanced bug is indistinguishable for a feature. - Rick Kulawiec > > /-------------------------- signal@shreve.net -----------------------------\ > | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | > | Systems Administrator | Perl, Linux | Web hosting, online stores, | > | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | > | 89 CRX, Akimoto intake, DC |-=*:Quake:*=-| http://www.shreve.net/ | > | headers, Eurosport exhaust |LordSignal/SN| Quake server: 208.206.76.3 | > \-------------------------- 318-222-2638 x109 -----------------------------/ > > >

On Thu, 18 Sep 1997, Lars Freund wrote: > Hi, > > > > Sep 14 22:06:59 polyp *** ISDN WARNING ***: DNIS: 73790 ANI: 919166609 > > > Type: B: I5 Call rejected for lack of resources > > > > The first message means that there are no free ports > > The chassis is full of calls and cannot route the call anywhere currently > > thanks - but: we have 16 MB memory, 3 quad modem cards, and set > maxbchann to 5. Normally, users get a "busy" when all five lines are > full. With the error above, users get: "computer doesn't response" from > their Win95. So I can't imagine that there are no free ports... Which > ports are meant? When you have set maxbchann to 5 - you have essentially said that that you have only 5 b channels, a six call cannot take place. There is no b channels to take that call. You have 12 modems in there, so set the maxbchannels to 12 - Now you will be taking 12 calls. Each connection requires a b channels - you have nothing free. It is essentially saying that it has no free port ( no b channel available ) kris \ T.S.V. Krishnan \ \ Network System Engineer \ ( : - : ) \ 3Com ............ \ ----------------------------------------------/ tkrishna@bubba.ae.usr.com ----------------------------/ http://interproc.ae.usr.com ----/ Any Sufficiently advanced bug is indistinguishable for a feature. - Rick Kulawiec > > > Ciao, > > Lars > > -- > +-----------------------------------------------------------------+ > | Lars Freund lars@forchheim.com | > | FOnLine Buergernetzverein: http://www.forchheim.baynet.de | > | http://cip2.e-technik.uni-erlangen.de:8080/hyplan/lafreund.html | > +-----------------------------------------------------------------+ > > >

On Thu, 18 Sep 1997 eric@dol.net wrote: > Why is the default for a duel pri/t1 tc chassis set to 60 channels and 60 > ips? I understand in europe you can have 30 channels on each as opposed to > 24 in the us. Since my chassis use pri should i be setting the max channels > and ips to both be 46? > Thanks > Eric > The NETServer is capable of supporting 60 modems/Bchannels currently, this will be increased to 96 in future. The setup of Max B channels is entirely upto you, it is defaulted to 60 since it can handle 60, you should set this value depending upon the amount of B channels you have. krish \ T.S.V. Krishnan \ \ Network System Engineer \ ( : - : ) \ 3Com ............ \ ----------------------------------------------/ tkrishna@bubba.ae.usr.com ----------------------------/ http://interproc.ae.usr.com ----/ Any Sufficiently advanced bug is indistinguishable for a feature. - Rick Kulawiec > > > > > Delaware Online!.........The SMART Choice! With 56K X2 Modems > Phone : 302-762-0375 Fax: 302-762-3462 WWW: www.dol.net > Eight out of five people have a problem understanding statistics! > ****************Customer support is our bottom line!********************* > > >

I hate to keep asking about this.......I mean I had MPIP working right at one time, but its just not working for me, and I am not sure what I am doing wrong, so let me just tell you what I am doing: hub #1 208.214.44.2 CLIENT/SERVER hub #2 208.214.44.53 CLIENT hub #3 208.214.44.104 CLIENT hub #1: set mpipserver 1 208.214.44.2 secret set time_server 1 208.206.76.2 reset time save all hub #2: set mpipserver 1 208.214.44.2 secret set time_server 1 208.206.76.2 reset time save all hub #3: set mpipserver 1 208.214.44.2 secret set time_server 1 208.206.76.2 reset time save all hub #1: set mpipserver on add mpipclient 208.214.44.2 secret add mpipclient 208.214.44.53 secret add mpipclient 208.214.44.104 secret save all sh mp on all servers reveals MPP is enabled. ISDN/MPP works flawlessly on all hubs. MPIP does not work however. Is there something I am doing wrong in configuring? Have I left something out? Should I reboot netserver? /-------------------------- signal@shreve.net -----------------------------\ | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | | Systems Administrator | Perl, Linux | Web hosting, online stores, | | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | | 89 CRX, Akimoto intake, DC |-=*:Quake:*=-| http://www.shreve.net/ | | headers, Eurosport exhaust |LordSignal/SN| Quake server: 208.206.76.3 | \-------------------------- 318-222-2638 x109 -----------------------------/

The USR TC hubs support STAC compression. How can you tell if STAC compression is being used on a link? Is there a way via tcm or netserver card to view this information? Is there anything you have to set to enable STAC compression, either in tcm or radius? Brian /-------------------------- signal@shreve.net -----------------------------\ | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | | Systems Administrator | Perl, Linux | Web hosting, online stores, | | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | | 89 CRX, Akimoto intake, DC |-=*:Quake:*=-| http://www.shreve.net/ | | headers, Eurosport exhaust |LordSignal/SN| Quake server: 208.206.76.3 | \-------------------------- 318-222-2638 x109 -----------------------------/

Set ccp on will set ccp compression to both stac and ms. The system will autodetect when the client connects - You also have an option to set ccp only for ms or stac. krish \ T.S.V. Krishnan \ \ Network System Engineer \ ( : - : ) \ 3Com ............ \ ----------------------------------------------/ tkrishna@bubba.ae.usr.com ----------------------------/ http://interproc.ae.usr.com ----/ Any Sufficiently advanced bug is indistinguishable for a feature. - Rick Kulawiec On Thu, 18 Sep 1997, Pete Ashdown wrote: > Brian said once upon a time: > > >> set ccp stac > >> > >> This is the command to enable stack compression > > > >will "set ccp on" also enable stac compression? > > Does this prohibit someone from using Microsoft compression? >

On Thu, 18 Sep 1997, Brian wrote: > Ok, thanks to krish and a few others, I am starting to see my problem with > MPIP: > > hub #1: > February 3, 1900 7:45:57 UT > > hub #2: > September 18, 1997 17:38:18 UT > > hub #3: > September 18, 1997 17:38:45 UT > > > The time server on ALL 3 hubs is: > 208.206.76.2 > alternate is: > 208.206.76.3 > > > I did a reset time on hub #1, and the time does NOT change!! The only > thing special about hub #1 is its one of the Packet Bus clocking chassis > (high density), and its netserver was sent back to USR becuase of nic > lockups, and replaced by USR with the fc2 chip netserver. You do not have to reboot the NETServer. However if you set one to be a client and then change it to Server, you do need to reboot it. Do a show netconns - this will show a process talking to the time server on port 123 -- reset that connections you will see it something like this 6 net 0 0 149.112.96.232.1026 207.24.169.174.123 UDP no do a reset n6 or whatever the first number is. This will make sure that you have connections with the time server krish > > Do I have to reboot the netserver for the time to change? The time server > is set, I sit there and do reset time all day and nothing happens, yet on > the other hubs they get updated. > > Brian > > > /-------------------------- signal@shreve.net -----------------------------\ > | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | > | Systems Administrator | Perl, Linux | Web hosting, online stores, | > | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | > | 89 CRX, Akimoto intake, DC |-=*:Quake:*=-| http://www.shreve.net/ | > | headers, Eurosport exhaust |LordSignal/SN| Quake server: 208.206.76.3 | > \-------------------------- 318-222-2638 x109 -----------------------------/ > > >

At 11:41 PM 9/17/97 -0500, you wrote: >The USR TC hubs support STAC compression. > >How can you tell if STAC compression is being used on a link? Is there a >way via tcm or netserver card to view this information? > >Is there anything you have to set to enable STAC compression, either in >tcm or radius? From the Netserver, "set ccp on" will turn both stac and ms compression on and "set ccp ms" or "set ccp stac" will turn on only the individual compression. I haven't figured out how to see what each connection is using either.

set ccp all will enable all the options krish \ T.S.V. Krishnan \ \ Network System Engineer \ ( : - : ) \ 3Com ............ \ ----------------------------------------------/ tkrishna@bubba.ae.usr.com ----------------------------/ http://interproc.ae.usr.com ----/ Any Sufficiently advanced bug is indistinguishable for a feature. - Rick Kulawiec On Thu, 18 Sep 1997, Pete Ashdown wrote: > Tatai SV Krishnan said once upon a time: > > > >Set ccp on will set ccp compression to both stac and ms. > >The system will autodetect when the client connects - You also have an > >option to set ccp only for ms or stac. > > SaltLake1-TC> set ccp on > Compression Control Protocol: ENABLED > CCP Algorithm : STAC > > Am I to ignore the Algorithm line? >

set ccp all will enable both ms and stack krish \ T.S.V. Krishnan \ \ Network System Engineer \ ( : - : ) \ 3Com ............ \ ----------------------------------------------/ tkrishna@bubba.ae.usr.com ----------------------------/ http://interproc.ae.usr.com ----/ Any Sufficiently advanced bug is indistinguishable for a feature. - Rick Kulawiec On Thu, 18 Sep 1997, Pete Ashdown wrote: > Tatai SV Krishnan said once upon a time: > > > >Set ccp on will set ccp compression to both stac and ms. > >The system will autodetect when the client connects - You also have an > >option to set ccp only for ms or stac. > > SaltLake1-TC> set ccp on > Compression Control Protocol: ENABLED > CCP Algorithm : STAC > > Am I to ignore the Algorithm line? >

Why is the default for a duel pri/t1 tc chassis set to 60 channels and 60 ips? I understand in europe you can have 30 channels on each as opposed to 24 in the us. Since my chassis use pri should i be setting the max channels and ips to both be 46? Thanks Eric > Delaware Online!.........The SMART Choice! With 56K X2 Modems Phone : 302-762-0375 Fax: 302-762-3462 WWW: www.dol.net Eight out of five people have a problem understanding statistics! ****************Customer support is our bottom line!*********************

On Thu, 18 Sep 1997, Brian wrote: > My Hub #1 will not allows its time to be set. That is surprising. So does this mean that you cannot set time - It gives you an error? > > After a reboot its time is January 1, 1900 00:00, it does increment, but > it wont take a time change from any time server. > Ok, Are you communicating with the Time server at all. I would check the time server - or atleast make sure that the NETServer is communicating - I would point it to another time server. A tcp dump or a snoop to see what is happening would be great to debug. > I called USR Tech Support, so that I could have nothing more than a Level > 1 guy read to me aloud the section of the Netserver manual about setting > the time server. To me this is very insulting, because I promise you I > have more experience, time and knowledge then he has. Well - Not surprised - ( BTW who is this person do you know his name ? ). > > Could this mean my memory is screwed?! Is there a way to check this? The > card is a very old hardware version, it was sent to me from USR when I > sent them my very new card that was having nic lockups (btw, no more > lockups!). Perhaps a internal battery or something has died on this > card......any ideas? > Memory should be fine, if at all something that could screwed up - then I would tend to believe it could be flash. Flash generally does not get corrupted easily - but you things do happen. If you have a syslog or tcp dump it will help - Please let me know... krish > Brian > > > /-------------------------- signal@shreve.net -----------------------------\ > | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | > | Systems Administrator | Perl, Linux | Web hosting, online stores, | > | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | > | 89 CRX, Akimoto intake, DC |-=*:Quake:*=-| http://www.shreve.net/ | > | headers, Eurosport exhaust |LordSignal/SN| Quake server: 208.206.76.3 | > \-------------------------- 318-222-2638 x109 -----------------------------/ > > >

On Thu, 18 Sep 1997, Brian wrote: > > Here is what my broken time netserver is crying out: > > Sep 18 16:48:49 usr1ts1 last message repeated 4 times > Sep 18 16:48:50 usr1ts1 ntp_recvresponse: Someone spoofed the NTP > response.^M > Sep 18 16:48:51 usr1ts1 ntp_recvresponse: Someone spoofed the NTP > response.^M > Sep 18 16:48:52 usr1ts1 ntp_recvresponse: Someone spoofed the NTP > response.^M > Sep 18 16:48:55 usr1ts1 last message repeated 3 times > Sep 18 16:48:56 usr1ts1 ntp_recvresponse: Someone spoofed the NTP > response.^M > Sep 18 16:48:57 usr1ts1 ntp_recvresponse: Someone spoofed the NTP > response.^M Guess this is syslog - Try changing your NTP server on this box and see what it does ( if you do not have one - point it to 207.24.169.174 ) Also could you please get a tcpdump or snoop or better yet a sniffer trace to see what is happening to the time packet from the server krish \ T.S.V. Krishnan \ \ Network System Engineer \ ( : - : ) \ 3Com ............ \ ----------------------------------------------/ tkrishna@bubba.ae.usr.com ----------------------------/ http://interproc.ae.usr.com ----/ Any Sufficiently advanced bug is indistinguishable for a feature. - Rick Kulawiec > > > /-------------------------- signal@shreve.net -----------------------------\ > | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | > | Systems Administrator | Perl, Linux | Web hosting, online stores, | > | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | > | 89 CRX, Akimoto intake, DC |-=*:Quake:*=-| http://www.shreve.net/ | > | headers, Eurosport exhaust |LordSignal/SN| Quake server: 208.206.76.3 | > \-------------------------- 318-222-2638 x109 -----------------------------/ > > >

On Thu, 18 Sep 1997, Lars Freund wrote: > Hi Kris, > > > > > The first message means that there are no free ports > > > > The chassis is full of calls and cannot route the call anywhere currently > > > > > > thanks - but: we have 16 MB memory, 3 quad modem cards, and set > > > maxbchann to 5. Normally, users get a "busy" when all five lines are > > > full. With the error above, users get: "computer doesn't response" from > > > their Win95. So I can't imagine that there are no free ports... Which > > > ports are meant? > > > > When you have set maxbchann to 5 - you have essentially said that that > > you have only 5 b channels, a six call cannot take place. There is no b > > channels to take that call. You have 12 modems in there, so set the > > maxbchannels to 12 - Now you will be taking 12 calls. Each connection > > requires a b channels - you have nothing free. > > It is essentially saying that it has no free port ( no b channel > > available ) > > We only have 64kbit - so we can not have more than 5 ISDN connections to > get at least some bits per second over the line. I do not understand this - Guess I am missing some info here - Could please explain what you means by saying that you have 64 Kb. > > But normally and the last weeks whe set maxbchann to 5 and we are able > to have 12 users per modem AND 5 modems per ISDN online at the same > time. > Trust me - If you have maxbchannesl set to 5 and if you have a pri line coming in, ISDN and modem calls combined it will handle only 5 calls. After a reset everything works makes me believe that you have rebooted the NETServer and the change made prior to the reboot was not saved so you must have gone to the original configuration. If you do have analog lines then yes you can have more than 5 people connected. krish \ T.S.V. Krishnan \ \ Network System Engineer \ ( : - : ) \ 3Com ............ \ ----------------------------------------------/ tkrishna@bubba.ae.usr.com ----------------------------/ http://interproc.ae.usr.com ----/ Any Sufficiently advanced bug is indistinguishable for a feature. - Rick Kulawiec > I guess there was a problem after 18 days uptime of the USR. After a > reset I haven't seen this anymore. > > > Bye, > > Lars > > -- > +-----------------------------------------------------------------+ > | Lars Freund lars@forchheim.com | > | FOnLine Buergernetzverein: http://www.forchheim.baynet.de | > | http://cip2.e-technik.uni-erlangen.de:8080/hyplan/lafreund.html | > +-----------------------------------------------------------------+ > > >

Is there a solution to the problem of spurious line feeds and @ characters appearing on the screen whem loggin in through a TC rack when you dial into a port set up for portmux and do a straight terminal session rather than a ppp type connection? We have no problems with livingston or cisco equipment just usr. The problem occurs with virtually any machine you call in from using a VT100 terminal emulation. peter peter stern pstern@polarnet.com System Administration

Brian said once upon a time: >> set ccp stac >> >> This is the command to enable stack compression > >will "set ccp on" also enable stac compression? Does this prohibit someone from using Microsoft compression?

J. S. Nakamura said once upon a time: >>From the Netserver, >"set ccp on" will turn both stac and ms compression on and >"set ccp ms" or "set ccp stac" will turn on only the individual compression. Great. Now that I've typed "set ccp stac" on my TC, how do I turn it back to both "ms and stac" without rebooting?

Not that it matters, except to satisfy my curiosity: Why do some ISDN calls connect on the modems (v5.5.7) and some on the I ports in the Netserver (v3.5.34)? I would expect all of the ISDN calls to connect on one or the other. Regards, Charles Hill ioNET Network Specialist

On Wed, 17 Sep 1997, Tatai SV Krishnan wrote: > > On Wed, 17 Sep 1997, Brian wrote: > > > The USR TC hubs support STAC compression. > > > > How can you tell if STAC compression is being used on a link? Is there a > > way via tcm or netserver card to view this information? > > > > Is there anything you have to set to enable STAC compression, either in > > tcm or radius? > > > > Brian > > > > set ccp stac > > This is the command to enable stack compression will "set ccp on" also enable stac compression? > > krish > > ----------------------------------------- > \ T.S.V. Krishnan \ > \ Network System Engineer \ ( : - : ) > \ 3Com ............ \ > ----------------------------------------------/ > tkrishna@bubba.ae.usr.com > ----------------------------/ http://interproc.ae.usr.com ----/ > -------------------------------------------------------------------------\ > Any Sufficiently advanced bug is indistinguishable for a feature. > - Rick Kulawiec > -------------------------------------------------------------------------/ > > > > > > > /-------------------------- signal@shreve.net -----------------------------\ > > | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | > > | Systems Administrator | Perl, Linux | Web hosting, online stores, | > > | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | > > | 89 CRX, Akimoto intake, DC |-=*:Quake:*=-| http://www.shreve.net/ | > > | headers, Eurosport exhaust |LordSignal/SN| Quake server: 208.206.76.3 | > > \-------------------------- 318-222-2638 x109 -----------------------------/ > > > > > > > /-------------------------- signal@shreve.net -----------------------------\ | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | | Systems Administrator | Perl, Linux | Web hosting, online stores, | | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | | 89 CRX, Akimoto intake, DC |-=*:Quake:*=-| http://www.shreve.net/ | | headers, Eurosport exhaust |LordSignal/SN| Quake server: 208.206.76.3 | \-------------------------- 318-222-2638 x109 -----------------------------/

Ok, thanks to krish and a few others, I am starting to see my problem with MPIP: hub #1: February 3, 1900 7:45:57 UT hub #2: September 18, 1997 17:38:18 UT hub #3: September 18, 1997 17:38:45 UT The time server on ALL 3 hubs is: 208.206.76.2 alternate is: 208.206.76.3 I did a reset time on hub #1, and the time does NOT change!! The only thing special about hub #1 is its one of the Packet Bus clocking chassis (high density), and its netserver was sent back to USR becuase of nic lockups, and replaced by USR with the fc2 chip netserver. Do I have to reboot the netserver for the time to change? The time server is set, I sit there and do reset time all day and nothing happens, yet on the other hubs they get updated. Brian /-------------------------- signal@shreve.net -----------------------------\ | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | | Systems Administrator | Perl, Linux | Web hosting, online stores, | | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | | 89 CRX, Akimoto intake, DC |-=*:Quake:*=-| http://www.shreve.net/ | | headers, Eurosport exhaust |LordSignal/SN| Quake server: 208.206.76.3 | \-------------------------- 318-222-2638 x109 -----------------------------/

Tatai SV Krishnan said once upon a time: > >Set ccp on will set ccp compression to both stac and ms. >The system will autodetect when the client connects - You also have an >option to set ccp only for ms or stac. SaltLake1-TC> set ccp on Compression Control Protocol: ENABLED CCP Algorithm : STAC Am I to ignore the Algorithm line?

Hi, > > Sep 14 22:06:59 polyp *** ISDN WARNING ***: DNIS: 73790 ANI: 919166609 > > Type: B: I5 Call rejected for lack of resources > > The first message means that there are no free ports > The chassis is full of calls and cannot route the call anywhere currently thanks - but: we have 16 MB memory, 3 quad modem cards, and set maxbchann to 5. Normally, users get a "busy" when all five lines are full. With the error above, users get: "computer doesn't response" from their Win95. So I can't imagine that there are no free ports... Which ports are meant? Ciao, Lars -- +-----------------------------------------------------------------+ | Lars Freund lars@forchheim.com | | FOnLine Buergernetzverein: http://www.forchheim.baynet.de | | http://cip2.e-technik.uni-erlangen.de:8080/hyplan/lafreund.html | +-----------------------------------------------------------------+

On Thu, 18 Sep 1997, Pete Ashdown wrote: > Brian said once upon a time: > > >> set ccp stac > >> > >> This is the command to enable stack compression > > > >will "set ccp on" also enable stac compression? > > Does this prohibit someone from using Microsoft compression? > I read somewhere that if the computer does software compression of anykind, that the hardware will NOT do STAC compression, meaning the hardware at either end won't do STAC if it detects software compression is in use. I wonder if this is true........ Brian /-------------------------- signal@shreve.net -----------------------------\ | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | | Systems Administrator | Perl, Linux | Web hosting, online stores, | | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | | 89 CRX, Akimoto intake, DC |-=*:Quake:*=-| http://www.shreve.net/ | | headers, Eurosport exhaust |LordSignal/SN| Quake server: 208.206.76.3 | \-------------------------- 318-222-2638 x109 -----------------------------/

> You do not have to reboot the NETServer. However if you set one to be a > client and then change it to Server, you do need to reboot it. > Do a show netconns - this will show a process talking to the time server > on port 123 -- reset that connections > > you will see it something like this > > 6 net 0 0 149.112.96.232.1026 207.24.169.174.123 UDP > > no do a reset n6 or whatever the first number is. This will make sure > that you have connections with the time server > > krish > Thanks. I did a reset on the port talking to 123, but It never came back :(, the netconn went away but it never came back. I am probably going to do a reset on the hub just because I have been screwing with this MPIP for so much these last few days, I am not sure whats going on. Brian > > > > > > Do I have to reboot the netserver for the time to change? The time server > > is set, I sit there and do reset time all day and nothing happens, yet on > > the other hubs they get updated. > > > > Brian > > > > > > /-------------------------- signal@shreve.net -----------------------------\ > > | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | > > | Systems Administrator | Perl, Linux | Web hosting, online stores, | > > | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | > > | 89 CRX, Akimoto intake, DC |-=*:Quake:*=-| http://www.shreve.net/ | > > | headers, Eurosport exhaust |LordSignal/SN| Quake server: 208.206.76.3 | > > \-------------------------- 318-222-2638 x109 -----------------------------/ > > > > > > > /-------------------------- signal@shreve.net -----------------------------\ | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | | Systems Administrator | Perl, Linux | Web hosting, online stores, | | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | | 89 CRX, Akimoto intake, DC |-=*:Quake:*=-| http://www.shreve.net/ | | headers, Eurosport exhaust |LordSignal/SN| Quake server: 208.206.76.3 | \-------------------------- 318-222-2638 x109 -----------------------------/

My Hub #1 will not allows its time to be set. After a reboot its time is January 1, 1900 00:00, it does increment, but it wont take a time change from any time server. I called USR Tech Support, so that I could have nothing more than a Level 1 guy read to me aloud the section of the Netserver manual about setting the time server. To me this is very insulting, because I promise you I have more experience, time and knowledge then he has. Could this mean my memory is screwed?! Is there a way to check this? The card is a very old hardware version, it was sent to me from USR when I sent them my very new card that was having nic lockups (btw, no more lockups!). Perhaps a internal battery or something has died on this card......any ideas? Brian /-------------------------- signal@shreve.net -----------------------------\ | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | | Systems Administrator | Perl, Linux | Web hosting, online stores, | | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | | 89 CRX, Akimoto intake, DC |-=*:Quake:*=-| http://www.shreve.net/ | | headers, Eurosport exhaust |LordSignal/SN| Quake server: 208.206.76.3 | \-------------------------- 318-222-2638 x109 -----------------------------/

Here is what my broken time netserver is crying out: Sep 18 16:48:49 usr1ts1 last message repeated 4 times Sep 18 16:48:50 usr1ts1 ntp_recvresponse: Someone spoofed the NTP response.^M Sep 18 16:48:51 usr1ts1 ntp_recvresponse: Someone spoofed the NTP response.^M Sep 18 16:48:52 usr1ts1 ntp_recvresponse: Someone spoofed the NTP response.^M Sep 18 16:48:55 usr1ts1 last message repeated 3 times Sep 18 16:48:56 usr1ts1 ntp_recvresponse: Someone spoofed the NTP response.^M Sep 18 16:48:57 usr1ts1 ntp_recvresponse: Someone spoofed the NTP response.^M /-------------------------- signal@shreve.net -----------------------------\ | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | | Systems Administrator | Perl, Linux | Web hosting, online stores, | | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | | 89 CRX, Akimoto intake, DC |-=*:Quake:*=-| http://www.shreve.net/ | | headers, Eurosport exhaust |LordSignal/SN| Quake server: 208.206.76.3 | \-------------------------- 318-222-2638 x109 -----------------------------/

You can have it done via radius, per user basis - the value of ccp should be setup in the dictionary file - So your entry for CCP will be as follows VALUE CCP_Algorithm NONE 1 VALUE CCP_Algorithm Stac 2 VALUE CCP_Algorithm MS 3 VALUE CCP_Algorithm Any 4 krish \ T.S.V. Krishnan \ \ Network System Engineer \ ( : - : ) \ 3Com ............ \ ----------------------------------------------/ tkrishna@bubba.ae.usr.com ----------------------------/ http://interproc.ae.usr.com ----/ Any Sufficiently advanced bug is indistinguishable for a feature. - Rick Kulawiec On Wed, 17 Sep 1997, Brian wrote: > The USR TC hubs support STAC compression. > > How can you tell if STAC compression is being used on a link? Is there a > way via tcm or netserver card to view this information? > > Is there anything you have to set to enable STAC compression, either in > tcm or radius? > > Brian > > > /-------------------------- signal@shreve.net -----------------------------\ > | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | > | Systems Administrator | Perl, Linux | Web hosting, online stores, | > | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | > | 89 CRX, Akimoto intake, DC |-=*:Quake:*=-| http://www.shreve.net/ | > | headers, Eurosport exhaust |LordSignal/SN| Quake server: 208.206.76.3 | > \-------------------------- 318-222-2638 x109 -----------------------------/ > > >

Thus spake Brian >I called USR Tech Support, so that I could have nothing more than a Level >1 guy read to me aloud the section of the Netserver manual about setting >the time server. To me this is very insulting, because I promise you I >have more experience, time and knowledge then he has. Call them on the same ticket number and ask to escalate it? -- Jeff McAdams Email: jeffm@iglou.com Chief Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

On Thu, 18 Sep 1997, Brian wrote: > > > Guess this is syslog - Try changing your NTP server on this box and see > > what it does ( if you do not have one - point it to 207.24.169.174 ) > > Also could you please get a tcpdump or snoop or better yet a sniffer > > trace to see what is happening to the time packet from the server > > > > > > krish > > ----------------------------------------- > > \ T.S.V. Krishnan \ > > \ Network System Engineer \ ( : - : ) > > \ 3Com ............ \ > > ----------------------------------------------/ > > tkrishna@bubba.ae.usr.com > > ----------------------------/ http://interproc.ae.usr.com ----/ > > -------------------------------------------------------------------------\ > > Any Sufficiently advanced bug is indistinguishable for a feature. > > - Rick Kulawiec > > -------------------------------------------------------------------------/ > > > Here is my tcpdump output. usr1ts1 is the hub we are having time problems > with. I did a few "reset time" in there on usr1ts1 and it didnt change > anything or the output of the tcpdump: > > 19:51:41.450000 usr1ts1.shreve.net.1026 > ns1.shreve.net.ntp: v3 client > strat 0 > poll 0 prec 0 dist 0.000000 disp 0.000000 ref @0.000000000 [|ntp] (ttl > 254, id 12) > 19:51:48.880000 usr3ts1.shreve.net.1026 > ns1.shreve.net.ntp: v3 client > strat 0 > poll 0 prec 0 dist 0.000000 disp 0.000000 ref @0.000000000 [|ntp] (ttl > 254, id 17929) > 19:51:52.390000 usr1ts1.shreve.net.1026 > ns1.shreve.net.ntp: v3 client > strat 0 > poll 0 prec 0 dist 0.000000 disp 0.000000 ref @0.000000000 [|ntp] (ttl > 254, id 190) > 19:51:55.190000 usr2ts1.shreve.net.1026 > ns1.shreve.net.ntp: v3 client > strat 0 > poll 0 prec 0 dist 0.000000 disp 0.000000 ref @0.000000000 [|ntp] (ttl > 254, id 30978) > 19:51:59.850000 usr3ts1.shreve.net.1026 > ns1.shreve.net.ntp: v3 client > strat 0 > poll 0 prec 0 dist 0.000000 disp 0.000000 ref @0.000000000 [|ntp] (ttl > 254, id 17931) > 19:52:03.350000 usr1ts1.shreve.net.1026 > ns1.shreve.net.ntp: v3 client > strat 0 > poll 0 prec 0 dist 0.000000 disp 0.000000 ref @0.000000000 [|ntp] (ttl > 254, id 245) > 19:52:05.190000 usr2ts1.shreve.net.1026 > ns1.shreve.net.ntp: v3 client > strat 0 > poll 0 prec 0 dist 0.000000 disp 0.000000 ref @0.000000000 [|ntp] (ttl > 254, id 30991) > 19:52:10.820000 usr3ts1.shreve.net.1026 > ns1.shreve.net.ntp: v3 client > strat 0 > poll 0 prec 0 dist 0.000000 disp 0.000000 ref @0.000000000 [|ntp] (ttl > 254, id 17933) > 19:52:14.330000 usr1ts1.shreve.net.1026 > ns1.shreve.net.ntp: v3 client > strat 0 > poll 0 prec 0 dist 0.000000 disp 0.000000 ref @0.000000000 [|ntp] (ttl > 254, id 326) > 19:52:16.180000 usr2ts1.shreve.net.1026 > ns1.shreve.net.ntp: v3 client > strat 0 > poll 0 prec 0 dist 0.000000 disp 0.000000 ref @0.000000000 [|ntp] (ttl > 254, id 76) > 19:52:21.780000 usr3ts1.shreve.net.1026 > ns1.shreve.net.ntp: v3 client > strat 0 > poll 0 prec 0 dist 0.000000 disp 0.000000 ref @0.000000000 [|ntp] (ttl > 254, id 18001) > 19:52:25.290000 usr1ts1.shreve.net.1026 > ns1.shreve.net.ntp: v3 client > strat 0 > poll 0 prec 0 dist 0.000000 disp 0.000000 ref @0.000000000 [|ntp] (ttl > 254, id 356) > 19:52:26.180000 usr2ts1.shreve.net.1026 > ns1.shreve.net.ntp: v3 client > strat 0 > poll 0 prec 0 dist 0.000000 disp 0.000000 ref @0.000000000 [|ntp] (ttl > 254, id 89) > Is it possible for you to reboot the NETServer and see what happens? If not then I would like to telnet to your NETServer and check some stuff. krish \ T.S.V. Krishnan \ \ Network System Engineer \ ( : - : ) \ 3Com ............ \ ----------------------------------------------/ tkrishna@bubba.ae.usr.com ----------------------------/ http://interproc.ae.usr.com ----/ Any Sufficiently advanced bug is indistinguishable for a feature. - Rick Kulawiec > > /-------------------------- signal@shreve.net -----------------------------\ > | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | > | Systems Administrator | Perl, Linux | Web hosting, online stores, | > | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | > | 89 CRX, Akimoto intake, DC |-=*:Quake:*=-| http://www.shreve.net/ | > | headers, Eurosport exhaust |LordSignal/SN| Quake server: 208.206.76.3 | > \-------------------------- 318-222-2638 x109 -----------------------------/ > > >

On Thu, 18 Sep 1997, Tatai SV Krishnan wrote: > On Thu, 18 Sep 1997, Brian wrote: > > > > > Here is what my broken time netserver is crying out: > > > > Sep 18 16:48:49 usr1ts1 last message repeated 4 times > > Sep 18 16:48:50 usr1ts1 ntp_recvresponse: Someone spoofed the NTP > > response.^M > > Sep 18 16:48:51 usr1ts1 ntp_recvresponse: Someone spoofed the NTP > > response.^M > > Sep 18 16:48:52 usr1ts1 ntp_recvresponse: Someone spoofed the NTP > > response.^M > > Sep 18 16:48:55 usr1ts1 last message repeated 3 times > > Sep 18 16:48:56 usr1ts1 ntp_recvresponse: Someone spoofed the NTP > > response.^M > > Sep 18 16:48:57 usr1ts1 ntp_recvresponse: Someone spoofed the NTP > > response.^M > > Guess this is syslog - Try changing your NTP server on this box and see > what it does ( if you do not have one - point it to 207.24.169.174 ) > Also could you please get a tcpdump or snoop or better yet a sniffer > trace to see what is happening to the time packet from the server will have a tcpdump to you in a few minutes......... and BTW, changing the time server yields the same results....... Brian > > > krish > ----------------------------------------- > \ T.S.V. Krishnan \ > \ Network System Engineer \ ( : - : ) > \ 3Com ............ \ > ----------------------------------------------/ > tkrishna@bubba.ae.usr.com > ----------------------------/ http://interproc.ae.usr.com ----/ > -------------------------------------------------------------------------\ > Any Sufficiently advanced bug is indistinguishable for a feature. > - Rick Kulawiec > -------------------------------------------------------------------------/ > > > > > > > > /-------------------------- signal@shreve.net -----------------------------\ > > | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | > > | Systems Administrator | Perl, Linux | Web hosting, online stores, | > > | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | > > | 89 CRX, Akimoto intake, DC |-=*:Quake:*=-| http://www.shreve.net/ | > > | headers, Eurosport exhaust |LordSignal/SN| Quake server: 208.206.76.3 | > > \-------------------------- 318-222-2638 x109 -----------------------------/ > > > > > > > /-------------------------- signal@shreve.net -----------------------------\ | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | | Systems Administrator | Perl, Linux | Web hosting, online stores, | | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | | 89 CRX, Akimoto intake, DC |-=*:Quake:*=-| http://www.shreve.net/ | | headers, Eurosport exhaust |LordSignal/SN| Quake server: 208.206.76.3 | \-------------------------- 318-222-2638 x109 -----------------------------/

> Guess this is syslog - Try changing your NTP server on this box and see > what it does ( if you do not have one - point it to 207.24.169.174 ) > Also could you please get a tcpdump or snoop or better yet a sniffer > trace to see what is happening to the time packet from the server > > > krish > ----------------------------------------- > \ T.S.V. Krishnan \ > \ Network System Engineer \ ( : - : ) > \ 3Com ............ \ > ----------------------------------------------/ > tkrishna@bubba.ae.usr.com > ----------------------------/ http://interproc.ae.usr.com ----/ > -------------------------------------------------------------------------\ > Any Sufficiently advanced bug is indistinguishable for a feature. > - Rick Kulawiec > -------------------------------------------------------------------------/ Here is my tcpdump output. usr1ts1 is the hub we are having time problems with. I did a few "reset time" in there on usr1ts1 and it didnt change anything or the output of the tcpdump: 19:51:41.450000 usr1ts1.shreve.net.1026 > ns1.shreve.net.ntp: v3 client strat 0 poll 0 prec 0 dist 0.000000 disp 0.000000 ref @0.000000000 [|ntp] (ttl 254, id 12) 19:51:48.880000 usr3ts1.shreve.net.1026 > ns1.shreve.net.ntp: v3 client strat 0 poll 0 prec 0 dist 0.000000 disp 0.000000 ref @0.000000000 [|ntp] (ttl 254, id 17929) 19:51:52.390000 usr1ts1.shreve.net.1026 > ns1.shreve.net.ntp: v3 client strat 0 poll 0 prec 0 dist 0.000000 disp 0.000000 ref @0.000000000 [|ntp] (ttl 254, id 190) 19:51:55.190000 usr2ts1.shreve.net.1026 > ns1.shreve.net.ntp: v3 client strat 0 poll 0 prec 0 dist 0.000000 disp 0.000000 ref @0.000000000 [|ntp] (ttl 254, id 30978) 19:51:59.850000 usr3ts1.shreve.net.1026 > ns1.shreve.net.ntp: v3 client strat 0 poll 0 prec 0 dist 0.000000 disp 0.000000 ref @0.000000000 [|ntp] (ttl 254, id 17931) 19:52:03.350000 usr1ts1.shreve.net.1026 > ns1.shreve.net.ntp: v3 client strat 0 poll 0 prec 0 dist 0.000000 disp 0.000000 ref @0.000000000 [|ntp] (ttl 254, id 245) 19:52:05.190000 usr2ts1.shreve.net.1026 > ns1.shreve.net.ntp: v3 client strat 0 poll 0 prec 0 dist 0.000000 disp 0.000000 ref @0.000000000 [|ntp] (ttl 254, id 30991) 19:52:10.820000 usr3ts1.shreve.net.1026 > ns1.shreve.net.ntp: v3 client strat 0 poll 0 prec 0 dist 0.000000 disp 0.000000 ref @0.000000000 [|ntp] (ttl 254, id 17933) 19:52:14.330000 usr1ts1.shreve.net.1026 > ns1.shreve.net.ntp: v3 client strat 0 poll 0 prec 0 dist 0.000000 disp 0.000000 ref @0.000000000 [|ntp] (ttl 254, id 326) 19:52:16.180000 usr2ts1.shreve.net.1026 > ns1.shreve.net.ntp: v3 client strat 0 poll 0 prec 0 dist 0.000000 disp 0.000000 ref @0.000000000 [|ntp] (ttl 254, id 76) 19:52:21.780000 usr3ts1.shreve.net.1026 > ns1.shreve.net.ntp: v3 client strat 0 poll 0 prec 0 dist 0.000000 disp 0.000000 ref @0.000000000 [|ntp] (ttl 254, id 18001) 19:52:25.290000 usr1ts1.shreve.net.1026 > ns1.shreve.net.ntp: v3 client strat 0 poll 0 prec 0 dist 0.000000 disp 0.000000 ref @0.000000000 [|ntp] (ttl 254, id 356) 19:52:26.180000 usr2ts1.shreve.net.1026 > ns1.shreve.net.ntp: v3 client strat 0 poll 0 prec 0 dist 0.000000 disp 0.000000 ref @0.000000000 [|ntp] (ttl 254, id 89) /-------------------------- signal@shreve.net -----------------------------\ | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | | Systems Administrator | Perl, Linux | Web hosting, online stores, | | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | | 89 CRX, Akimoto intake, DC |-=*:Quake:*=-| http://www.shreve.net/ | | headers, Eurosport exhaust |LordSignal/SN| Quake server: 208.206.76.3 | \-------------------------- 318-222-2638 x109 -----------------------------/

Hi Kris, > > > The first message means that there are no free ports > > > The chassis is full of calls and cannot route the call anywhere currently > > > > thanks - but: we have 16 MB memory, 3 quad modem cards, and set > > maxbchann to 5. Normally, users get a "busy" when all five lines are > > full. With the error above, users get: "computer doesn't response" from > > their Win95. So I can't imagine that there are no free ports... Which > > ports are meant? > > When you have set maxbchann to 5 - you have essentially said that that > you have only 5 b channels, a six call cannot take place. There is no b > channels to take that call. You have 12 modems in there, so set the > maxbchannels to 12 - Now you will be taking 12 calls. Each connection > requires a b channels - you have nothing free. > It is essentially saying that it has no free port ( no b channel > available ) We only have 64kbit - so we can not have more than 5 ISDN connections to get at least some bits per second over the line. But normally and the last weeks whe set maxbchann to 5 and we are able to have 12 users per modem AND 5 modems per ISDN online at the same time. I guess there was a problem after 18 days uptime of the USR. After a reset I haven't seen this anymore. Bye, Lars -- +-----------------------------------------------------------------+ | Lars Freund lars@forchheim.com | | FOnLine Buergernetzverein: http://www.forchheim.baynet.de | | http://cip2.e-technik.uni-erlangen.de:8080/hyplan/lafreund.html | +-----------------------------------------------------------------+

> > J. S. Nakamura said once upon a time: > > >>From the Netserver, > >"set ccp on" will turn both stac and ms compression on and > >"set ccp ms" or "set ccp stac" will turn on only the individual compression. > > Great. Now that I've typed "set ccp stac" on my TC, how do I turn it back > to both "ms and stac" without rebooting? > > Try "set ccp all"

The command was intended not to be in the documentation. It was a hidden command for some obvious reason - So you do not have any doc on it. I will address this issue with our Doc guys. krish \ T.S.V. Krishnan \ \ Network System Engineer \ ( : - : ) \ 3Com ............ \ ----------------------------------------------/ tkrishna@bubba.ae.usr.com ----------------------------/ http://interproc.ae.usr.com ----/ Any Sufficiently advanced bug is indistinguishable for a feature. - Rick Kulawiec On Fri, 19 Sep 1997, Michael Wronski wrote: > At 07:49 PM 9/19/97 +1000, you wrote: > > > >> set ccp all > >> will enable all the options > > > >Is there actually documentation that describes all these options? Our > >NETServer was shipped with 3.3.28 code installed, and documentation from > >around the 3.1 vintage (read 'useless'). > > > >So far, I'm yet to find documentation either printed or in PDF form, for > >anything more recent. Complete 3.5.33 documentation would be nothing > >short of brilliant, especially if it documents all these things. > > > There is no documentation for this option.. You can get the release notes > from all releases after 3.0 to update your docs for other options.. > Unfortunatly there > is not one complete doccument that has everything.. > > -MCW > > > `'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`' > Mike Wronski(mwronski@coredump.ae.usr.com) 3Com/U.S.Robotics > Network Systems Engineer (Level 3) > PGP: http://coredump.ae.usr.com/pgp > > > > >

>>>>> "Garry" == Garry Shtern <shterng@akula.com> writes: Garry> Hey, This might sound like a stupid question, however... How do Garry> I create the following filter on net0? Okay - I'll give it a shot: Garry> input: Garry> deny icmp any any Garry> permit udp 1.2.3.4/32 0.0.0.0 eq 520 Garry> deny udp 0.0.0.0/0 0.0.0.0/0 eq 520 Garry> permit ip any any On your netserver: add filter test set filter test 1 deny 0.0.0.0/0 0.0.0.0/0 icmp set filter test 2 permit 1.2.3.4/32 0.0.0.0/32 udp dst eq 520 set filter test 3 deny 0.0.0.0/0 0.0.0.0/0 udp dst eq 520 set filter test 4 permit 0.0.0.0/0 0.0.0.0/0 ip set net0 ifilter test Do the same for your output filter, and then: set net0 ofiler test2 Now you just have to construct the filters you want ;) Rick -- Rick Payne, Senior Network Admin | Meddle not in the affairs of NETCOM Internet Ltd. | dragons - for you are crunchy & rickp@corp.netcom.net.uk | taste great dipped in chocolate.

We are currently running the Worldgroup BBS software with the MajorTCP/IP Radius Server (Note: not *MY* idea), and the current version will simply NOT run unless you use Netserver card version 3.5.93. Well, this is fine and dandy, except that on the totalservice site, you can only get up to version 3.5.34. Where does one go to get the .93? Jim MacKenzie tomservo@erie.net System Administrator ErieNet, Inc. "I love California. I practically grew up in Phoenix." - Former U.S. VP Dan Quayle

Thus spake James MacKenzie >We are currently running the Worldgroup BBS software with the MajorTCP/IP >Radius Server (Note: not *MY* idea), and the current version will simply >NOT run unless you use Netserver card version 3.5.93. Well, this is fine >and dandy, except that on the totalservice site, you can only get up to >version 3.5.34. Where does one go to get the .93? Additionally, I've been sent 3.5.86 in order to fix the ISDN bonded channel idle problem (where it idle'd out the second channel despite traffic), but I've also been hit by a customer or two experiencing quake lag (fixed in 3.5.93 correct?) so I'd like to be able to get that fix in place also. The question is...are all the fixes that are present in (for example) 3.5.86 also in place in 3.5.93 or are they worked on somewhat in parallel so all the fixes won't be incorporated until a later release? Basically, I have 3.5.86 which fixes a very important thing for us, but if that fix is also present in 3.5.93, I may push for that code, but if its not, then I'll hold on 3.5.86 as the idle timeout problem is a bigger problem for us than quake lag. Thanks for any and all info. -- Jeff McAdams Email: jeffm@iglou.com Chief Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

At 08:55 AM 9/19/97 +0100, Rick Payne wrote: >add filter test >set filter test 1 deny 0.0.0.0/0 0.0.0.0/0 icmp >set filter test 2 permit 1.2.3.4/32 0.0.0.0/32 udp dst eq 520 >set filter test 3 deny 0.0.0.0/0 0.0.0.0/0 udp dst eq 520 >set filter test 4 permit 0.0.0.0/0 0.0.0.0/0 ip > >set net0 ifilter test I wish it was that simple.. The command: set filter test 4 permit 0.0.0.0/0 0.0.0.0/0 ip is not valid. Garry Shtern shterng@akula.com Chief Network Administrator http://www.akula.com Akula Communications Corp. tel. (212) 292-8892

I seem to be experiencing some users getting connected and then after one to two or three minutes being just dropped for no apparent reason. The detail log shows either Stop or Lost-Carrier. Usually: Acct-Status-Type = Stop Acct-Terminate-Cause = User-Request also Acct-Status-Type = Stop Acct-Terminate-Cause = Lost-Carrier Our TCs were both up for 34 days. I thought that, like our Unix servers get, that they should be rebooted. I did that and all seems OK. I did discover a bad modem (won't acknowledge itself to the TCM, when other 3 will). I replaced it with a spare. Could that modem cause someone to get a standard busy signal of that chassis loaded up? It uses 2 PRIs (23x2) so therefore has 2 open modems and also uses Round-Robin. Running 2.5.1 3.5.34 Munich daughtercard on Netserver Thanks in advance. Bill Sheeler William M Sheeler, Sr www.talon.net ceo TCRA Computers and voice 610.670.6491 TALON Network Services, Inc voice 610.670.4923 Fax for both fax 610.670.6495 ( Total Area Linked Online Nationwide Network Services, Inc) " Live with Passion " " It's in your moments of decision that your destiny is shaped " ANTHONY ROBBINS

At 07:49 PM 9/19/97 +1000, you wrote: > >> set ccp all >> will enable all the options > >Is there actually documentation that describes all these options? Our >NETServer was shipped with 3.3.28 code installed, and documentation from >around the 3.1 vintage (read 'useless'). > >So far, I'm yet to find documentation either printed or in PDF form, for >anything more recent. Complete 3.5.33 documentation would be nothing >short of brilliant, especially if it documents all these things. > There is no documentation for this option.. You can get the release notes from all releases after 3.0 to update your docs for other options.. Unfortunatly there is not one complete doccument that has everything.. -MCW `'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`' Mike Wronski(mwronski@coredump.ae.usr.com) 3Com/U.S.Robotics Network Systems Engineer (Level 3) PGP: http://coredump.ae.usr.com/pgp

On Fri, 19 Sep 1997, Garry Shtern wrote: > > At 08:55 AM 9/19/97 +0100, Rick Payne wrote: > >add filter test > >set filter test 1 deny 0.0.0.0/0 0.0.0.0/0 icmp > >set filter test 2 permit 1.2.3.4/32 0.0.0.0/32 udp dst eq 520 > >set filter test 3 deny 0.0.0.0/0 0.0.0.0/0 udp dst eq 520 > >set filter test 4 permit 0.0.0.0/0 0.0.0.0/0 ip > > > >set net0 ifilter test > > I wish it was that simple.. The command: set filter test 4 permit 0.0.0.0/0 > 0.0.0.0/0 ip > is not valid. just do "set filter test 4 permit" Brian > > Garry Shtern shterng@akula.com > Chief Network Administrator http://www.akula.com > Akula Communications Corp. tel. (212) 292-8892 > /-------------------------- signal@shreve.net -----------------------------\ | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | | Systems Administrator | Perl, Linux | Web hosting, online stores, | | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | | 89 CRX, Akimoto intake, DC |-=*:Quake:*=-| http://www.shreve.net/ | | headers, Eurosport exhaust |LordSignal/SN| Quake server: 208.206.76.3 | \-------------------------- 318-222-2638 x109 -----------------------------/

At 03:32 PM 9/19/97 +0100, Rick Payne wrote: >>>>>> "Garry" == Garry Shtern <shterng@akula.com> writes: > > Garry> I wish it was that simple.. The command: set filter test 4 > Garry> permit 0.0.0.0/0 0.0.0.0/0 ip is not valid. > >Oh yeah - sorry. It shows it like that, but you actually have to enter: > >set filter test 4 permit 0.0.0.0/0 0.0.0.0/0 > Thanks.. It worked.. Garry Shtern shterng@akula.com Chief Network Administrator http://www.akula.com Akula Communications Corp. tel. (212) 292-8892

>>>>> "Garry" == Garry Shtern <shterng@akula.com> writes: Garry> I wish it was that simple.. The command: set filter test 4 Garry> permit 0.0.0.0/0 0.0.0.0/0 ip is not valid. Oh yeah - sorry. It shows it like that, but you actually have to enter: set filter test 4 permit 0.0.0.0/0 0.0.0.0/0 Rick -- Rick Payne, Senior Network Admin | Meddle not in the affairs of NETCOM Internet Ltd. | dragons - for you are crunchy & rickp@corp.netcom.net.uk | taste great dipped in chocolate.

At 02:37 PM 9/19/97 -0500, Brian wrote: >On Fri, 19 Sep 1997, Garry Shtern wrote: > >> >> At 08:55 AM 9/19/97 +0100, Rick Payne wrote: >> >add filter test >> >set filter test 1 deny 0.0.0.0/0 0.0.0.0/0 icmp >> >set filter test 2 permit 1.2.3.4/32 0.0.0.0/32 udp dst eq 520 >> >set filter test 3 deny 0.0.0.0/0 0.0.0.0/0 udp dst eq 520 >> >set filter test 4 permit 0.0.0.0/0 0.0.0.0/0 ip >> > >> >set net0 ifilter test >> >> I wish it was that simple.. The command: set filter test 4 permit 0.0.0.0/0 >> 0.0.0.0/0 ip >> is not valid. > >just do "set filter test 4 permit" > >Brian I got it.. Thanks.. Garry Shtern shterng@akula.com Chief Network Administrator http://www.akula.com Akula Communications Corp. tel. (212) 292-8892

> set ccp all > will enable all the options Is there actually documentation that describes all these options? Our NETServer was shipped with 3.3.28 code installed, and documentation from around the 3.1 vintage (read 'useless'). So far, I'm yet to find documentation either printed or in PDF form, for anything more recent. Complete 3.5.33 documentation would be nothing short of brilliant, especially if it documents all these things. Regards, Bob Purdon, Southern Internet.

> Trust me - If you have maxbchannesl set to 5 and if you have a pri line > coming in, ISDN and modem calls combined it will handle only 5 calls. Guess our rack (3.5.33) must be broken. I have maxbchannels set at 20, and it quite happily handles 25 simultaneous calls (ISDN+analogue) over the PRI. Regards, Bob Purdon, Southern Internet.

On Fri, 19 Sep 1997, MegaZone wrote: > Once upon a time Tatai SV Krishnan shaped the electrons to say... > >You can have it done via radius, per user basis - the value of ccp should > >be setup in the dictionary file - So your entry for CCP will be as follows > >VALUE CCP_Algorithm NONE 1 > >VALUE CCP_Algorithm Stac 2 > >VALUE CCP_Algorithm MS 3 > >VALUE CCP_Algorithm Any 4 > > Why the heck didn't you just asked to have these added to the existing, > and standard, Framed-Compression attribute? Which is meant for this kind > of thing. Hmmm... I did not have a chance to talk to you and ask your opinion before doing this... krish \ T.S.V. Krishnan \ \ Network System Engineer \ ( : - : ) \ 3Com ............ \ ----------------------------------------------/ tkrishna@bubba.ae.usr.com ----------------------------/ http://interproc.ae.usr.com ----/ Any Sufficiently advanced bug is indistinguishable for a feature. - Rick Kulawiec > > -MZ > -- > Livingston Enterprises - Chair, Department of Interstitial Affairs > Phone: 800-458-9966 510-737-2100 FAX: 510-737-2110 megazone@livingston.com > For support requests: support@livingston.com <http://www.livingston.com/> > Snail mail: 4464 Willow Road, Pleasanton, CA 94588 > >

Once upon a time Tatai SV Krishnan shaped the electrons to say... >You can have it done via radius, per user basis - the value of ccp should >be setup in the dictionary file - So your entry for CCP will be as follows >VALUE CCP_Algorithm NONE 1 >VALUE CCP_Algorithm Stac 2 >VALUE CCP_Algorithm MS 3 >VALUE CCP_Algorithm Any 4 Why the heck didn't you just asked to have these added to the existing, and standard, Framed-Compression attribute? Which is meant for this kind of thing. -MZ -- Livingston Enterprises - Chair, Department of Interstitial Affairs Phone: 800-458-9966 510-737-2100 FAX: 510-737-2110 megazone@livingston.com For support requests: support@livingston.com <http://www.livingston.com/> Snail mail: 4464 Willow Road, Pleasanton, CA 94588

On Sat, 20 Sep 1997, MyungSik Kim wrote: > Hello, > > I want to this. From my pc, I can telnet into Netserver but nobody > else can't. And from Netsever I can telnet into specific site. > I made input filter for this so I could telnet into Netserver but > couldn't telnet into anywhere. Any idea? > > add filter input1 > set filter input1 1 permit 200.200.200.200/32(my pc) > 10.10.10.10/32(netserver) tcp dst eq 32 this should be tcp dst eq 23 > set filter input2 1 permit 10.10.10.10/32 20.20.20.20/32 tcp dst eq 32 You do not need this filter krish \ T.S.V. Krishnan \ \ Network System Engineer \ ( : - : ) \ 3Com ............ \ ----------------------------------------------/ tkrishna@bubba.ae.usr.com ----------------------------/ http://interproc.ae.usr.com ----/ Any Sufficiently advanced bug is indistinguishable for a feature. - Rick Kulawiec > set net0 ifilter input1 > set net0 ofilter input2 > > > >

Hi again, > > We only have 64kbit - so we can not have more than 5 ISDN connections= to > > get at least some bits per second over the line. >=20 > I do not understand this - Guess I am missing some info here - Could > please explain what you means by saying that you have 64 Kb. the line to our internet provider has only 64 kbit/s (is it called T line? we call it ISDN), so we can not let 20 ISDN-connections at the same time on our USR-TC. That's why we need a restriction to a maximum of 5 ISDN users (plus 12 modem users). > > But normally and the last weeks whe set maxbchann to 5 and we are abl= e > > to have 12 users per modem AND 5 modems per ISDN online at the same > > time. > > > Trust me - If you have maxbchannesl set to 5 and if you have a pri line > coming in, ISDN and modem calls combined it will handle only 5 calls. > After a reset everything works makes me believe that you have rebooted > the NETServer and the change made prior to the reboot was not saved so > you must have gone to the original configuration. If you do have analo= g > lines then yes you can have more than 5 people connected. For "input", we have one "prim=E4rmultiplex S2M", thats 30 ISDN lines (must be that PRI line). But it IS possible to have 12 modem users AND 5 ISDN users on our USR-TC, I observe this since june. Here's the proof. The maxbchann has nothing to do with the number of possible modem connects. Maxbchann is saved to flash RAM since several weeks, so a reboot doesn't effect anything. For the "Call rejected for lack of resources", I'll continue monitoring. As I get these now more often than before, I belive you that it means "all 5 ISDN lines are busy" Ciao, Lars Command> show maxbchan Currently Active B-channels: 3 Maximum Active B-channels: 5 Command> sh ses Port User Host/Inet/Dest Type Dir Status Start =20 Idle ---- --------------- ---------------- ------- --- ------------- ------

Hello, all. I had tried to figure out what rule I had to make but rack of filtering I couldn't. Does anyone help me out ? I want to make this. I can access from my pc to Netserver but noboday can't access. And if I log into Netserver via ethernet, I can telnet anywhere. Also if dialup user logs in, he can access limited telnet or rlogin server. To solve first, I did this. add filter input set filter input 1 permit 10.10.10.10(my pc)/32 0.0.0.0/0 tcp dst eq 23 set net0 ifilter input add filter output set filter output 1 permit 10.10.10.2(netserver)/32 0.0.0.0/0 tcp dst eq 23 then I could access netserver from only my pc but couldn't go anywhere from netserver. Any help is much appreciated.

> The command was intended not to be in the documentation. It was a > hidden command for some obvious reason - So you do not have any doc on > it. I will address this issue with our Doc guys. That'd be good :-) I've noticed a lot of commands here lately that aren't in the docs we have and are useful enough that they should be. I even resorted to trying to dump the strings from the NETServer image, but it seems to have some form of proprietory compression on it :-( Regards, Bob Purdon, Southern Internet.

On Sat, 20 Sep 1997, MyungSik Kim wrote: > Hello, > > I want to this. From my pc, I can telnet into Netserver but nobody > else can't. And from Netsever I can telnet into specific site. > I made input filter for this so I could telnet into Netserver but > couldn't telnet into anywhere. Any idea? > > add filter input1 > set filter input1 1 permit 200.200.200.200/32(my pc) > 10.10.10.10/32(netserver) tcp dst eq 32 > set filter input2 1 permit 10.10.10.10/32 20.20.20.20/32 tcp dst eq 32 > set net0 ifilter input1 > set net0 ofilter input2 Very simple.. You do not allow traffic to flow to netserver to any port but 23(not 32), and when telnet client iniates, it binds to a random port to use it for a TCP connection. What you need to do is this: set filter input1 1 permit 1.2.3.4/32 10.10.10.10/32 tcp dst eq 23 set filter input1 2 deny tcp dst eq 23 set filter input1 3 permit set filter input2 1 permit 10.10.10.10/32 1.2.3.4/32 tcp dst eq 23 set filter input2 2 deny tcp dst eq 23 set filter input2 3 permit -Garry

On Sat, 20 Sep 1997, MyungSik Kim wrote: > Hello, > > I want to this. From my pc, I can telnet into Netserver but nobody > else can't. And from Netsever I can telnet into specific site. > I made input filter for this so I could telnet into Netserver but > couldn't telnet into anywhere. Any idea? > > add filter input1 > set filter input1 1 permit 200.200.200.200/32(my pc) > 10.10.10.10/32(netserver) tcp dst eq 32 > set filter input2 1 permit 10.10.10.10/32 20.20.20.20/32 tcp dst eq 32 > set net0 ifilter input1 > set net0 ofilter input2 Very simple.. You do not allow traffic to flow to netserver to any port but 23(not 32), and when telnet client iniates, it binds to a random port to use it for a TCP connection. What you need to do is this: set filter input1 1 permit 1.2.3.4/32 10.10.10.10/32 tcp dst eq 23 set filter input1 2 deny tcp dst eq 23 set filter input1 3 permit set filter input2 1 permit 10.10.10.10/32 1.2.3.4/32 tcp dst eq 23 set filter input2 2 deny tcp dst eq 23 set filter input2 3 permit -Garry

My netserver clock STILL will not accept time. I have tried multiple time hosts, resetting the netconn, rebooting the hub, and erase flash and redoing the config. The only thing left is the dipswitch, which I am probably going to have to do...........any more suggestions until I throw the switch? Brian /-------------------------- signal@shreve.net -----------------------------\ | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | | Systems Administrator | Perl, Linux | Web hosting, online stores, | | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | | 89 CRX, Akimoto intake, DC |-=*:Quake:*=-| http://www.shreve.net/ | | headers, Eurosport exhaust |LordSignal/SN| Quake server: 208.206.76.3 | \-------------------------- 318-222-2638 x109 -----------------------------/

I'm using the large merit radius dictionary file that was posted to the list recently, but I dont see IP-Filter-In or IP-Filter-Out listed. Should Filter-Id be used instead, and if so how do I specify in or out? I also see PW_USR_IFilter_IP and PW_USR_OFilter_IP listed, but attempting to use them didn't yield much.. - lv

Hello, I want to this. From my pc, I can telnet into Netserver but nobody else can't. And from Netsever I can telnet into specific site. I made input filter for this so I could telnet into Netserver but couldn't telnet into anywhere. Any idea? add filter input1 set filter input1 1 permit 200.200.200.200/32(my pc) 10.10.10.10/32(netserver) tcp dst eq 32 set filter input2 1 permit 10.10.10.10/32 20.20.20.20/32 tcp dst eq 32 set net0 ifilter input1 set net0 ofilter input2

Once upon a time Tatai SV Krishnan shaped the electrons to say... >> >You can have it done via radius, per user basis - the value of ccp should >> >be setup in the dictionary file - So your entry for CCP will be as follows >> >VALUE CCP_Algorithm NONE 1 >> >VALUE CCP_Algorithm Stac 2 >> >VALUE CCP_Algorithm MS 3 >> >VALUE CCP_Algorithm Any 4 >> >> Why the heck didn't you just asked to have these added to the existing, >> and standard, Framed-Compression attribute? Which is meant for this kind >> of thing. >Hmmm... I did not have a chance to talk to you and ask your opinion >before doing this... Forget my opinion. This is RADIUS - you know, IETF WG. Is there a reason USR decided to avoid the standards body - when this very topic has come up? Framed-Compression is part of the RFC, and is specifically there to handle things like this. I don't recall USR mentioning a need for this when the very question was asked a few months back. It isn't even a new attribute, simply some new values. In the past when a vendor has needed something like that it took a mere email to the chair and a post to the list to make sure there were no conflicts. What's the point of having a standard if vendors are going to create VSAs at the drop of a hat? I do get very upset when I see things like this, because I consider it a major disservice to the users and the interests of interoperability. Ascend is bad enough. -MZ -- Livingston Enterprises - Chair, Department of Interstitial Affairs Phone: 800-458-9966 510-737-2100 FAX: 510-737-2110 megazone@livingston.com For support requests: support@livingston.com <http://www.livingston.com/> Snail mail: 4464 Willow Road, Pleasanton, CA 94588

On Sat, 20 Sep 1997, MegaZone wrote: > Once upon a time Tatai SV Krishnan shaped the electrons to say... > >> >You can have it done via radius, per user basis - the value of ccp should > >> >be setup in the dictionary file - So your entry for CCP will be as follows > >> >VALUE CCP_Algorithm NONE 1 > >> >VALUE CCP_Algorithm Stac 2 > >> >VALUE CCP_Algorithm MS 3 > >> >VALUE CCP_Algorithm Any 4 > >> > >> Why the heck didn't you just asked to have these added to the existing, > >> and standard, Framed-Compression attribute? Which is meant for this kind > >> of thing. > >Hmmm... I did not have a chance to talk to you and ask your opinion > >before doing this... > > Forget my opinion. This is RADIUS - you know, IETF WG. Is there a reason > USR decided to avoid the standards body - when this very topic has come > up? Framed-Compression is part of the RFC, and is specifically there to > handle things like this. I don't recall USR mentioning a need for this > when the very question was asked a few months back. It isn't even a > new attribute, simply some new values. In the past when a vendor has > needed something like that it took a mere email to the chair and a post > to the list to make sure there were no conflicts. > > What's the point of having a standard if vendors are going to create VSAs > at the drop of a hat? I do get very upset when I see things like this, > because I consider it a major disservice to the users and the interests of > interoperability. > > Ascend is bad enough. > Framed-Compression is the part of the standard - Which is IP header compression and IPX compression. CCP includes a variety of compressions methods by different vendors - like stac, Microsoft, Gandolf etc. Vendors have choice - they can support these or not. The RFC does not say that you have to use attribute 13 to support different vendors compressions. The whole idea of having attribute 26 is to enable different vendors have their own way of supporting their specific attributes. If you need interoperability - then the first thing that you need to drive to the standards body is to get rip of attribute 26 and force each and every one to follow what the standard says. kris \ T.S.V. Krishnan \ \ Network System Engineer \ ( : - : ) \ 3Com ............ \ ----------------------------------------------/ tkrishna@bubba.ae.usr.com ----------------------------/ http://interproc.ae.usr.com ----/ Any Sufficiently advanced bug is indistinguishable for a feature. - Rick Kulawiec > -MZ > -- > Livingston Enterprises - Chair, Department of Interstitial Affairs > Phone: 800-458-9966 510-737-2100 FAX: 510-737-2110 megazone@livingston.com > For support requests: support@livingston.com <http://www.livingston.com/> > Snail mail: 4464 Willow Road, Pleasanton, CA 94588 > >

I may be wrong but I thought this mailing list is for US Robotics TC Hubs and other related USR products. If I want to read what livingston has to say about it's competition and its hardware I will join a livingston mailing list. Thankfully I don't have too...:> MegaZone wrote: Forget my opinion. This is RADIUS - you know, IETF WG. Is there a reason > USR decided to avoid the standards body - when this very topic has come > up? Framed-Compression is part of the RFC, and is specifically there to > handle things like this. I don't recall USR mentioning a need for this > when the very question was asked a few months back. It isn't even a > new attribute, simply some new values. In the past when a vendor has > needed something like that it took a mere email to the chair and a post > to the list to make sure there were no conflicts. > > What's the point of having a standard if vendors are going to create VSAs > at the drop of a hat? I do get very upset when I see things like this, > because I consider it a major disservice to the users and the interests of > interoperability. > > Ascend is bad enough. > > -MZ > -- > Livingston Enterprises - Chair, Department of Interstitial Affairs > Phone: 800-458-9966 510-737-2100 FAX: 510-737-2110 megazone@livingston.com > For support requests: support@livingston.com <http://www.livingston.com/> > Snail mail: 4464 Willow Road, Pleasanton, CA 94588 -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Rick--->Monmouth Internet| Serving the Central Network Engineer---------| New Jersey Area http://www.monmouth.com | 732-842-5366 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

Once upon a time Brian shaped the electrons to say... >and turn on "Enable Software Compression" in win95, thus using STAC >instead of v42, thus making better consumption of bandwidth? >MegaZone was talking about this in relation to the portmaster, I am not >sure if its the same as the TC hub in that respect, perhaps he knows. My understanding is that the TC does Stac in SW - the PM-3 has dedicated HW that does Stac at bus speed. The question is how much CPU does the TC have to handle compression? If it has the needed CPU then you should get a decrease in latency by cutting the users modem out of the compression loop. But if it runs out of CPU then it won't be a benefit. See if USR has stats on performance using Stac. Some NASes have lower performance when many sessions run compression. I honestly do not know how the TC fairs, but this is what I'd check on with USR. -MZ -- Livingston Enterprises - Chair, Department of Interstitial Affairs Phone: 800-458-9966 510-737-2100 FAX: 510-737-2110 megazone@livingston.com For support requests: support@livingston.com <http://www.livingston.com/> Snail mail: 4464 Willow Road, Pleasanton, CA 94588

Once upon a time Stephen Fisher shaped the electrons to say... >This does directly relate to USR TC's and their (mis)-implementation of >Radius from what I can see. For the record I took this over to the ietf-radius mailing list. Ascend also has a VSA for this. And it seems to make a hell of a lot of sense to get it out in the WG before ever vendor has a different way to do the same thing. -MZ -- Livingston Enterprises - Chair, Department of Interstitial Affairs Phone: 800-458-9966 510-737-2100 FAX: 510-737-2110 megazone@livingston.com For support requests: support@livingston.com <http://www.livingston.com/> Snail mail: 4464 Willow Road, Pleasanton, CA 94588

I have been following some of the info being posted to portmaster-users and was wondering something: Would it be BETTER for users to turn off v42 compression on there modems, and turn on "Enable Software Compression" in win95, thus using STAC instead of v42, thus making better consumption of bandwidth? MegaZone was talking about this in relation to the portmaster, I am not sure if its the same as the TC hub in that respect, perhaps he knows. Brian /-------------------------- signal@shreve.net -----------------------------\ | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | | Systems Administrator | Perl, Linux | Web hosting, online stores, | | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | | 89 CRX, Akimoto intake, DC |-=*:Quake:*=-| http://www.shreve.net/ | | headers, Eurosport exhaust |LordSignal/SN| Quake server: 208.206.76.3 | \-------------------------- 318-222-2638 x109 -----------------------------/

This does directly relate to USR TC's and their (mis)-implementation of Radius from what I can see. - Steve - Systems Manager - Community Internet Access, Inc. - Gallup and Grants, New Mexico On Sun, 21 Sep 1997, Rick wrote: > I may be wrong but I thought this mailing list is for US Robotics TC Hubs and > other related USR products. If I want to read what livingston has to say about > it's competition and its hardware I will join a livingston mailing list. > Thankfully I don't have too...:> > > > > MegaZone wrote: > > Forget my opinion. This is RADIUS - you know, IETF WG. Is there a reason > > > USR decided to avoid the standards body - when this very topic has come > > up? Framed-Compression is part of the RFC, and is specifically there to > > handle things like this. I don't recall USR mentioning a need for this > > when the very question was asked a few months back. It isn't even a > > new attribute, simply some new values. In the past when a vendor has > > needed something like that it took a mere email to the chair and a post > > to the list to make sure there were no conflicts. > > > > What's the point of having a standard if vendors are going to create VSAs > > at the drop of a hat? I do get very upset when I see things like this, > > because I consider it a major disservice to the users and the interests of > > interoperability. > > > > Ascend is bad enough. > > > > -MZ > > -- > > Livingston Enterprises - Chair, Department of Interstitial Affairs > > Phone: 800-458-9966 510-737-2100 FAX: 510-737-2110 megazone@livingston.com > > For support requests: support@livingston.com <http://www.livingston.com/> > > Snail mail: 4464 Willow Road, Pleasanton, CA 94588 > > > > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Rick--->Monmouth Internet| Serving the Central > Network Engineer---------| New Jersey Area > http://www.monmouth.com | 732-842-5366 > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > > >

On Fri, 19 Sep 1997, Michael Wronski wrote: > Unfortunatly there > is not one complete doccument that has everything.. > > `'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`' > Mike Wronski(mwronski@coredump.ae.usr.com) 3Com/U.S.Robotics > Network Systems Engineer (Level 3) > PGP: http://coredump.ae.usr.com/pgp > Ok, silly question then, where do we put a vote into USR to have a product with actual full documentation? I remeber my first TC rack that arrived, with nearly 2,000 pages worth of reading (which i read maybe 1/5 th and skimmed the rest for usefull info)- i'm a real stickler for 'info' when I spend $20,000 per rack.. how bout hte rest of you? Adam Wills Global 2000 Communications Director of Networking Systems 1840 Western Ave. sysadmin@global2000.net Albany, NY, 12203 http://www.global2000.net (518) 452-1465

John Campbell said once upon a time: > >I am not only brand new to the list, and starting up my own ISP here in >Roanoke VA. Just purchased the TC package. I think they call it the 1909 >package with dual 70 PSU power supplies and 6 quad card modems. The PRI >line is to be installed next Friday, I also have not got the thing >configured.... Still working on that one! using the Radius Server on Wndows >NT with Access 95. Installed, but not configured... Any advice would be >appreaciated. You might want to download the archives at: ftp://ftp.xmission.com/pub/lists/usr-tc/archives You'll find a lot of first-time user problemm resolution in there.

> I may be wrong but I thought this mailing list is for US Robotics TC Hubs and > other related USR products. If I want to read what livingston has to say about > it's competition and its hardware I will join a livingston mailing list. > Thankfully I don't have too...:> > Hmm, I guess it's dedicated to engineers and technicians who work with TCMs. Ussualy we are not addicted to money-hunting as are those who better remember their banks accounts numbers than the date of birth. Anyone who can help with problems we discuss here is welcome. That's opinion of mine. (sorry for engl.) Kamil Kukura U N I C O M (authorized distributor of U.S.Robotics) Usti nad Labem, Czech Republic

Our TC chassis (the "newer one" if that makes any difference) has a problem with its dual PRI card. The T1 on it (it's going to two T1s this week) needs manual intervention before it will come up after a power cycling/reboot. This is a PRI connected to a Nortel switch. We've never had such problem with our Max 4000's, so I assume this is a USR glitch. Question: what's the fix for this ? -Pascal +--------------------------------------+-----------------------------+ Pascal Gosselin http://www.Mlink.NET | Mlink Internet Inc. pascal@Mlink.NET (514) 231-1923 | Montr=E9al, Qu=E9bec & Toronto

I am not only brand new to the list, and starting up my own ISP here in Roanoke VA. Just purchased the TC package. I think they call it the 1909 package with dual 70 PSU power supplies and 6 quad card modems. The PRI line is to be installed next Friday, I also have not got the thing configured.... Still working on that one! using the Radius Server on Wndows NT with Access 95. Installed, but not configured... Any advice would be appreaciated. 73's John Campbell - KC4LWI http://www.intrlink.com/~sparky mailto:sparky@intrlink.com

Thanks for the info... Will check it out! At 12:23 PM 9/23/97 -0600, you wrote: >John Campbell said once upon a time: >> >>I am not only brand new to the list, and starting up my own ISP here in >>Roanoke VA. Just purchased the TC package. I think they call it the 1909 >>package with dual 70 PSU power supplies and 6 quad card modems. The PRI >>line is to be installed next Friday, I also have not got the thing >>configured.... Still working on that one! using the Radius Server on Wndows >>NT with Access 95. Installed, but not configured... Any advice would be >>appreaciated. > >You might want to download the archives at: > ftp://ftp.xmission.com/pub/lists/usr-tc/archives > >You'll find a lot of first-time user problemm resolution in there. > > 73's John Campbell - KC4LWI http://www.intrlink.com/~sparky mailto:sparky@intrlink.com

> Ok, silly question then, where do we put a vote into USR to have a > product with actual full documentation? I'd love to know! > I remeber my first TC rack that arrived, with nearly 2,000 pages worth > of reading (which i read maybe 1/5 th and skimmed the rest for usefull > info)- i'm a real stickler for 'info' when I spend $20,000 per rack.. > how bout hte rest of you? Yeah, same here. The docs that arrived with our TC were on CD and so far out of date that the CD is only useful as a frisbee. As mentioned previously, the latest NETServer docs we have are 3.1 vintage (yet the card shipped with 3.3.28 on it). The only Quad Card manuals we have are installation manuals - no parameter reference manuals or anything useful like that. Regards, Bob Purdon, Southern Internet.

On Tuesday, September 23, 1997 9:09 PM, Jim Seidel - Family Based Internet L.L.C. 708-957-5586 [SMTP:jimseidel@safeplace.net] wrote: > We have experienced the same thing. We were told "don't ever turn the > power off" by the USR Tech Support person. We haven't since. > > -- > =================================== > Jim Seidel - GM Family Based Internet L.L.C. > jimseidel@safeplace.net > 708-957-5586 > =================================== > > Pascal Gosselin wrote: > > > > Our TC chassis (the "newer one" if that makes any difference) has a problem > > with its dual PRI card. > > > > The T1 on it (it's going to two T1s this week) needs manual intervention > > before it will come up after a power cycling/reboot. This is a PRI > > connected to a Nortel switch. > > > > We've never had such problem with our Max 4000's, so I assume this is > > a USR glitch. > > > > Question: what's the fix for this ? Seems to me the provisioning for the DMS switch is not set to AutoRestore. I would verify that with the telco. We experienced the same thing with 1 and 2, but not the third PRI on a Max 4004. The 3rd PRI had this AutoRestore feature turned on and the others did not. BTW: We were using a AT&T/Lucent 5ESS-2000 switch. Marshall Morgan Internet Doorway, Inc. http://www.netdoor.com 601.969.1434 | 800.952.1570 | 601.969.3838 Fax

At 07:16 PM 9/24/97 -0500, you wrote: > >Good luck this ISP stuff can be fun and profitable as long as you got big >enough bottle of Maalox. "3 months into it." > >Just make sure you unit has the PRI code in the T1 cards. Wescon shipped us >with Channalized T1 and we had to fight to be able to download the PRI >firmware . Also make sure you have the "Do it Yourself x2 Chassis >Installation" guide 30 pages It's got everything you need in on place. Have TONAGE worth of paperwork and CD's etc... Which one would that be!... Not trying to sound sarcastic... >PS If your marketing person would like to exchange ideas with ours, her is >her e-mail >laurel@drfast.net > >Mike Hamrich >Technical Director >DrFast.Net, Inc. >---------- >> From: John Campbell <sparky@intrlink.com> >> To: usr-tc@mail.xmission.com >> > > > 73's John Campbell - KC4LWI http://www.intrlink.com/~sparky mailto:sparky@intrlink.com

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-1566035913-875087279=:10057 Content-Type: TEXT/PLAIN; charset=US-ASCII This is modified livingston code and also allows you to provide menu for users. The readme file is petty useful krish \ T.S.V. Krishnan \ \ Network System Engineer \ ( : - : ) \ 3Com ............ \ ----------------------------------------------/ tkrishna@bubba.ae.usr.com ----------------------------/ http://interproc.ae.usr.com ----/ Any Sufficiently advanced bug is indistinguishable for a feature. - Rick Kulawiec On Wed, 24 Sep 1997, Garry Shtern wrote: > At 03:31 PM 9/24/97 -0400, Jeff Mcadams wrote: > >Thus spake Garry Shtern > >>Actually you can get all of this if you use something called Realms in > >>Merit's version. You configure the realm shell and every time a user wants > >>to login into shell, they'll have to type username@shell. > > > >Hrmm...never thought of doing it that way....still wouldn't be > >backward compatible with some of our customer's setups, so that still > >wouldn't work for us...neat idea though. > > > >What we needed (and got setup) was the ability to have the person start > >PPP and auth with PAP, but if nothing was forthcoming, fire off a telnet > >to a shell server with no authentication on the NAS. Works like a > >charm for us...no double authentication, users don't even know the > >terminal server is there, and runs PPP on the terminal server > >automatically and gets all the benefits therein. > >-- > > Cool.. I remember at the time when I was seting this up(2 years ago) I was > looking for a solution like that, but couldn't find anything. I wonder how > you guys implemented that. > > Garry Shtern shterng@akula.com > Chief Network Administrator http://www.akula.com > Akula Communications Corp. tel. (212) 292-8892 > --416219727-1566035913-875087279=:10057 Content-Type: APPLICATION/octet-stream; name="radius.tar.gz" Content-Transfer-Encoding: BASE64 Content-ID: <Pine.LNX.3.91.970924024759.10057B@bubba.ae.usr.com> Content-Description: H4sICHRJJzQCA3JhZGl1cy50YXIA7D37c9pI0vkV/RWzdpyA14DEM8bn1LFA sr51bH9gJ7e12aKENIAqQuIk4cdt5X//untGT8A4u7Gze4sqCTDT09PTr+me GU1K5WeP/qhqTW3W6/Cpas26hp/wrSI+xfNMbVQbWh3+rWK5VqlUG8/qz57g WfiB7kGXwSfP8qeOvg4OwMbjewep4jjl4JrP/iJPqdx5Pyj/KeSvNZrVKmgB yb/RrG/l/2Ty77tu8Ijy11S1Uautl3+9hvJXm5UGcJDsv1qvNJ6pW/k/+tOa +9y75l4rHP8/r7mz8Fvla90r++7CM3jZuPY9UBDl2fb5n3uk/fO561uB6919 E/uvqVn7r9F8sbX/R39W2HnZ001r4Zdn4Ai2Nv+3sP+eE3gW97/N/K9Vqs1s /FerVLWt/T+F/ZfA6q2J43q8rJUq5Q/cZO90j7E60yottdrSakw7PGyWy0r5 nf6Jjy0bARsrAOsRYL/X7r7rla4G/eK73tkVwGv3wuuGEZSMNf0nwILAm3uW I2Br98KOFpZtmqMZgd7fu+E649J0Y++mJYmsrwBrRGAzs752KGmo6UYo4YgJ 8HAT4Fz3/bUdNyPIBYR7/tphJOACy34AOogcfct11nI5guwijeaoXI7HZYpW h+U3nkXNKq+wmdZs1aths62DfnT/nzHWb+D/681GIv6rkv+ndaCt/3/0Z9ca OyYfMxvcqgJjDCyDGVMwxv1+Z2CZ7JjtPP+R6yZkiGxDrJjVpINrBuYtLFnV yioYdbNV09CnXktms97tnD3fOVJ2uWNaY0Up7ytsnz0/dScttozuOVb2+bWF PoeQr8QeoUfwE8cKLN1mnmwGZfCnrChaibHLKYeK/ywsDzwXOngA0L07ZvnM cpjwWHGxUpFNyIkynAoZTB6Bbjk+C6B87rlUOHY9+o1cYVbAZ34J2/lc/FAY PFP9mjOdodu+cT2TBXdzztwx27k6O/n3DnWEVPgxfSHWue5B/yxwGTT8RMh0 x2S6x9nZ+SUSZ7LRXUjQxNNn0K3P7bGgHsAAq27f6HeSatf3rZFlW8EdIcuD U7+DbmduwAsAoQcIBs1m1mQaMH5r+QFQjnQSJ9iNFUwJk6PPOKEIZVY8uey9 K97e3kLXJw7zF8YUWhq6j0M3QSyLOaJgN1OX+XNuWGOIQqlLQoP4ALttswkn IhguVlgGtPZ917D0AIYqewcqJfsTvEN+6ITK58bCgxEi0Mjms++UqhTmTEY1 8OWOORwwAmdHnAU3HGoE288HL4EuF9mAXTls4No66JhAQR2A0TgTAPKn7sI2 EQGxcWY51ky3Swo8kVpqlWJVLR42lD+D/48DwG+3/ldfyv8r2/W/J3lkKKbI CBI/MRpXwvhZCWM1/L4Nl/4H478wq/tm6/8NiPay8V+10axu7f8p4j8ZbIVa QFHWbjLIaiSCrFesUm3VDlvaq0SQtcvapgkTpXHrQSDpzjFaUnbTSOpLkZqa jtRCJA6/gZhqNscJObBg+hf4cE72F/O56wUYXLD3EC/CvDwQMYPBcGnAGi0C 7gMmCN0oLpHxgF/KUlMjahplrVLWgJpGq1ptqVqKmo7NdQfogQDFcE1+AP96 Hjcw4NAhHrnRPcdyJhidIU0i4irqjm+x4pybugNxdLbXaqLXClPVVv1Vq9ZM 9bq/v8/4bA5hiu1OIHz0fX3CsTSLq5LApTEVsubK78alpXEBXc1WNY1rKYgG FLlQZShC6re7J1cDVmRQketT7MjaCwiYkBM6ibCLGCAKvELZDEQgh4iE7Fmx e3Y++LHdPf+Awu68OW2/HTBrzO7cBTNd52UgQubBVDfdG3Yh42af2uvWbSun ExL4GreHqkHnXFSdnvwwOGZFGwLHTzzAGhHDtYBiAQ2154DBv/PrWNY5zk0M gxUDnAIpBbChOETj+HYS2cKxbkEpeIsJMsLfMS0HFOmGzRfGaAmJMuh3uif9 45ICKj7s/fuydzY4OT9D+C6WvO+ddc/7w8FFr3Py5qQjSzHOTgDL0nanc351 dnly9jZZp1xc9U/e/Dw8v7ik34B57Nq2e1M0pjDfF8FiDFAU7h/fQShbvLHA ym78Y8cFKt1JEaV9PIc4enxXQqUqiiyiCAMrGrox5UXT8qipEnF0Us3ahWQx e55PD7OgnHZFKwV4D6xXduGTif4AOk17gSHESmkMev33vf7w/Id/DY7D8MWl 9A4+xAIYfOICl8twIc5l8coifDcILlzZciW67g/v7sOIS40PRkrAIZkg9Bip IZAakkxDYDQIo5HAaAiMRkSmoZycdU6vur3B8fO80KNCtH7I4iKx2Kko7dPT Vk72ysLgTwHColKM+FgUBirk3VtKTnj5JdmxIpYX0TcWQWv4rfg6DWbw7zl9 ABHxiAtKGFm24grkb0HJPc93OgUoFToEqF0WUpoGhZ+oADEupDnGF4rsXpQ0 zKUWoEyiPIPfbbEse1Foz/Mh91f1ZaxqoyhCJ5IIpUwfjk00AFSxqqXwJfTl C5DGrUAjrCyRUkEfjk80UBRpeUlcoZY/HJlsIbGRIX05wi7IGVUgYblrOiF7 TnUg7PELCKYGkPyH/iSJLbLeDQgT7iiNPTZ/Jelbfk8fIVOSeNZ2Jj1GK3Qd kdMTHFtncAi6pknK1kR9xtbEDseX2ZpooyjUUxKfcKjp39MN+KiNEqXGrcg7 rhlwWJ2Ay/qVuCZJXLx5tYGiBKCCK7jgn4v4CY53pBvXtyDV05Ozy6zrXQ1U KiW4DD8Ei+BLqMIGxsTQhTeDsIHtl2K3HIo2GnFy1WAb//2J479S0t1/o/y/ Wm8u7f/UqtvzP3+1/Z+EJtHeT21llv2gvZ80quy+z8b8HcC/RgJPW0XrUnhK u6u1Vi3TcVcPIAFC06cBAGbLgRTcAOdHCxq6z9z53PVxo8NlkxkWLve0McEH 8PUZ/hK6jTn+fTtlIBisp0fk+fHPh2f6LCSLnlPrGtkfAHQPmITCBo4cQCuj FAE1Disq+wkSVNbhCARe3/sEGWcEcAFC9kFWrnPAOm0oOKzVG41kPx13fufR vhWMv7Kp2xgx92aW78uVJ3DcqD/zuwM2c0FX4RN33EzLl6tOLMANJ98dB+Tz cUFEd2IyIYVFgVMj3K5yFwEbc9qHw4010LyJp6OqHOCa1bWFC2Fy383yIyxG NBTEM48pdNyA9sTmcw6GCwWo4ACNe2kIKhfOYOARLtM1FmCzAcnrINq8ww3I +1iEXeHWFu4xRrhAvXUTYsMAtMaZMBj7fDGyLYN226BYt9DSkI8Rw5Bq6CrA vbOQR3KrMuSPHy7tQf+IMhqu4L0cM9Aysa65kyQmHm56mIKlyEWsSgkQa0EY o4TIYvZu4gljD1Vs2mv0gXb0Oh73Q8pATCMYc4SDdjoXVqCLXVnBqhUKFioW 7q4GLKEqkRbt6LgPuhNxld9ivz4KyZrNbQv3T3UPle+uFNl7chrwDcO3zF9+ ZcfKzj/zuwX8m3DOOfSJD7IxZAA4e2XXcgx7YfLcPyDOKuOut1+avs4Ui4ho uRx9ZbrU4SBoHpQtB8uT4IFpuUuw5ihdNL8x0wXLPRhIYxr5TriwsoPO8Ws9 gv+5NwuHDhy02JiYPER2D68h+BT1F0LmLfbBswI6QoBQ+sjmYeomTSteFC9C 6wWaWi7H5rpFZweEjs2FDrzBbXOB/2s9oEcZ+ll+jA4O+i/Qjjl7c3LaY/tj 80j8fN8+veoNL9onfbaPUEfKb1DRPelcDqmK7eNKAmLC0wD5wlG2FmqwjPR2 tBiPufdL7dWvWLQYiphmHgBWmMyYDwZhTFke+ym+RgkLmn5TxGY+nlC4+DC8 /PmiNxxc9iGMbgkipVDGYjA7ez5ESB93dsS4iq/RiRbkeBj0BrX5sPOChAGf Q/I4UiTczRRX0fNIHfvumL38qL6EHO03Jccw/8l/l7d86lSAFAoFrEFac6tI +vhRvd1TK7dAE4EfCbDP+MFtny81XgSGwHzAxmYKHMq+/x4KPisp2Jc7LyWo KB55XP90tIJzkFX23vb6IetQQMCQlBQFS2xiyEomIgeoIXAmnxR3gZ1dnZ6G jFohlj0/JZYD6j/CHg1K8GQtEtvMYElSnMSzngsX7W43YoI1hwTRq4ASsLxQ 0iWUaxVtaUQCwWZBdNuXvVaobtD1mCLRqH/f+i8HnyF/F7C7H1t771p7A7Y3 Ynuc7f28c6DkchTFiqZ5/BgGKIYXafrvG8BH+MhYy72DgMxEX9jBatu7cj45 7o0jTk7txWIia85gEyr9eXuCYXn/X6whP2Yf9+f/Wq3SqCzt/1e17fnPv1z+ T5pEqX/lD6T+IZbn96TET5r1f+XkmbUNw104qXzsr5ZHF/Gjtk2nt+n0Np3+ I+m0cHY5OmWVMrHa06bRWEpnp79Vch0XLRxQo0xDPKCs2+ky7nmOuzyKG90K 1mfr/BY46QhZwLxwPQzzRPWwAZlishrUybyneh8tDI08KsYMzeSjxWQ4tvVJ Blqeqx2amNdma4C6VMUVJE41VC7LI4Ue+txwHdPPAMjZbKkWCSHugJ4ISAjb DRG3Q2CMG6xDPZqDWF6HWcfj/wFPAEDXHDI7ETy3ry5/HPZ7/8f2JYQMqhF/ CCqSdJHJg0WIZF4MzJoPp64fkCMU2TqVG2AmDpX+olVEep7M2OtahcqWVwMY s10g11h4OBTKEMDfGPM7lo9xHrBUt5Lw4muRdmFyAs0w3GAYLUByEIhXETBI cL07+ZIFOAeBskSAZewqzD3CpAlSmTIlZAnRHiRGRyOefYLSuA1eg5ImQSzi dDm4dZveKNnYY9kk4A0dY9qcJ4FACDd259xJ4NF3CgV2DPm0kFuYSYt1AZkk ZjoPlwvYDkQvQQuc1cI2cVOWUNMxwCR1H52duMl9dOJju5Mh6GuUf4bl5X25 8Qs+dg4ajoO64aDMWObjZjBIDd+dIXZhgiez+cRKDmG5cOmNFVQbcMazediA hcoEPBLmoSay10Xgg2aJ8hcSEHJjYmrhKIFeyJDr+HJLuORWpmQ4XGjD/Rni UdQxLcMds0g/8S0fIO4ovSREULjwkbSG7MIH0bnzMdiJaYvWMhKLb1Qn19+O Ui2ddEtJmkzRwadkVoCW2sgqw8agLJ8uBfbYPGBn7QHDbJ1ZOLGy858ofuFQ BbOv586k9cf8Ie9LWgNzu32XcFIreIFrE1LX8uFaG5XHHi1cAlDE+MYeT3oH yX1hsnzm48pU1KEaL5CEHlEscqSQUInHg4XnHCmfH3VdOMOb7LpwnxgmNU+O TLwlpTus3fnp7PzDaa/7tgdhTtv26ZwiqK5YHRbMjrSYCS1GjonYF6MkOlsd 7jaGodHXXz1erwH0G3IHf/LgKSupM9RclgttAUxrpzbC+GO3LzCKxWR/iufQ AzfQ7aHNnYkoh8loYYBjgqAL55ohxs66eI1uTfU+RPhLy9OCCECLX8X0bcv1 4gjStCYg1F+0xq8hPMQAoHyy1er5FypwCLgkHQ+qkIxz5MzEfsBjPEAwSFwH 9zql/F/YJmIovsbcGvBcfEieM+n3BhfnZ4PeUQRG6wfxFGxK86IpW0Bc07R7 EAOFBUTh+17n8rw/PO2dCfK7vR+u3oL3GeCyAYQCcSINXz9hXA897tELfHv2 Lcvv+QU5ESWISHQmgoIHhQxJYcOgQgYibSHXTl2dFh7Q7PCYrTVZiPBNWJEf vcBJBkTcFDsEghWmHujIIOn6hdKv8/3JqVrEnOS18xA5g/+VJhI54X1ayIee qLj4OrLvaBYL90MkgNgQgQlGya3cCgFvC6wAhKDU+CVsF25tiIkk6hZBvmcV KgxDtshR08bDyvbIne+PhSnkMiL4Po01XDTOrd5/yK1ckE+SGHp4MrhChFdY HtRPIQ+zo3HaCSpDhaZxvAh3MtL4UuNJV60c2hpqolFG6+JxYe5zKEuhOZGw xQwezX6gqO05xGxmrIrRyZGyDBzBH5LmJefStM6lpQ/wqf0aLHzNVPbiBQH+ Q5iLUB6yZhm7RNwHyVyc9y+H73qDQfttb732pJhNEwDUfqG2fI6ZISwvsmoU MkQ3yaYFyrXHuES69lhdFM4D0fuUxjP3mgtbF566xLouvYyMAesMYigeRfm/ 3x/uYqyL8lx/3g/nURJ5BxLAha3T0hqX8bQfUifTjXAGSQg2IkNUFpIOPDFv AGOTPEuQL9odxMgFCrM+xJSU5QUBB7GqYcuDjPCyrVdyLMS0zKg4pLuPZDVN pFyafgh7YRLHOXXV/F5gL5IhQEhHNFpoekD7vbHDCOFFiAkAwETLGY71mUVW 3X4Dbq13marE/ko+fcSuKjuPpVrQi3SRwkegC3NOVWGOynCmxZhdRpPxzIWs hMJ8GCwtiTAPUUkhw2NRplJmmOVXxI6IEUv8RJZ8VrbrP19z/ack7+V51P2/ L7//tQq/tve/Psn+r5D/Y94C/GXyr5H8m/XaVv5PLP/HugX4y+7/bdD5/4a6 vf/jKZ7t/b9/9/M/Cft/pFuAN9//28jaP3zZ3v/xFM+mMz2kHVvL/1vY/2Pd ArzJ/qtaNRv/1avq9vzfk9h/6v7fVVe4voovyqWtW38jXHxjIoBW77veVfiY TUD0Ov4mqO7WSf0R+3/MWwA3zv+amp3/65Xm9v3fp3hsd4IHE7bG8ze3f+nb H2f9Z4P9N6sU/9caAIfrPvT/f2zn/yd58CI3ui03fZuxzmy85dcdy/NaPm5L 4/kmj+NxaPeGrsmFtngEl1b8E8fW5ZkTcWIEaiyPccfw7sRNfp/4XYk65dCn B52MLW6bdCcxbpRbJov24sMN8/Asnmgllrtls7zP59zT5VH+ka07n+g4bqCP /AIixfbQcIkAZbdDWNkZ9JTL/cTvlN1i5skVlx+lojZLlVpJaxzCXy2XE7tG 6eJKLqe4E90zLL2k89LC90qGOwtPNhG8VgNArVI6bJQqmhb91Ooq/D6M0KbL 62E3zcNSpV4NoaC3uFxTY6Iebv9xzPbE9q9V6/VmNbv+X69Vtv//xxPZP3vw Cz5ZVaFXfWQErlbLEJWrakvV8EqM9Ks+dEmPeL0n1fr5qhsyl3At3xLa6bTj Nxou8d0Ch1xPsW2I20dZh67jNtmFZ83wRnd0RQNyHPirezag1wbpCg6xPypv A8fLRaO7wsXSKGBLXA0/1cmnzfAeD3zdwZn4+AqjuJ78jAcDasNu6BZwfL8D L2kPLyl3fQ7Y5HGgGAG4I3Y+ZR+4bX+3+qZP4olaR57UKq36Kp7EV6DSYMHf 4Ksay5efRpfmV8raIatoLbW5msl0UgAlnjgerdN2sE8TBWLPIm8kkNdYRW1V ai2t+vvuJa2ncEG+B7RWDn8frloWF+SOahpXJ3pTLMAXSsY2/GD9Nx0fhlF/ RSOHL4erb3WNMNPLYWr6ZturualLvIAPsYlrr1ZPvQldCzzd8W35TgtOhnj1 P753tJtLzbET7uAciOfgwqMdPp3utAUK3ZCvxXigfjk8geLifxIAs3s7Oq/8 ng46XeBJT2kK4ugTAKVPNgMGfHdG3tZv0n02DsHVGJ5hE4YFON7TZB4XYfct GrVQe1ZkahFmMeYC11GVcsISobwmy/D9I4cHZEKjuwB68Uw0yBxerDPhCFqt sJEVSGIBfGRNGB7d0B0BzPJTazIVrSneKEBzlMdD2hZlsOHj0QS8rSyHDzom /MPevrs8YOxfugOj1Q5QEZoqDbDnLGYyKgmNHQInH0xIXAcUnaUg0ZNzSPw3 E7s58Yr7kvj/n7Nz6U4dVxbw2PtXsFZP7qDdBz8xgzsgQPbmNiE0KNl97yTL ASdhbWJzbJNOzq+/KvmBbKskmQz6keirkqVSqVSW5CjM6BDcwzcFaBOyP/xR 6PsM30/HsnUnhGwWNw9kbpT7XunvWkEMDUOKYOY34zal8c/eXKdJnuwSOJ+/ Xq/p70eG8d8Dy/ivqqVpAJXApkvafN++1SrKXddwQNGEQGrQ/LEG9ZFzMNs2 Vl3i1qIGthyb/pisTQHrKDAW75mLtjp3wJ/Mx7B1kjZZr8KKBhK3SXlo0yRw Rr08jKng2h1S/Yz0OOq72ZG0+ieQP16J0ZnrPcx+XbCxFrZJzsztXHp8qFXL 28Mxp81zaU/LkvZdid2Rh5aB2VrqptTlQauAyy44R87RUOUQmz/g3EhTnytt lQIrO53HPB11ZLpmZsZxfpP7rQ3eH/eikTCwRvKBB8Z8V06XPBZIMTiP/Bzu fpmrpNkqY02s6SHsYQPrPNy83gDVcg+lrYAXlxlm49FsW8fAFuu/YSiwCafA HLlzeKOr4YhGmuY2DzmFtqtwRSE/RC+YJ8W2hQmb5PAewfHTGhvJzWuxP0Yd CLhAznUj65Iby7kpNMqeNQmg9Sh3hvJWoRj9fYdz5L5hNdnSopB/oPFIyk0H 8h6nDvbzq9VtDHOkWDFUlxPSGuaOq4mt4OzERZuniX1Pk/Ppgvk61jw50aCA hMdf5vIQg0E7I705pOaqseAE/bj/g5AQFI5l1YSjhKwHzhk/Qw5cxSTCuFl0 DL+YVV9mckuDW8Snc27eF/Flydka3P05b4Ouo8FVg5aLHVy5rTCsvgqCC1S8 Huq4hnF97WZZh3BivHq8kX6z8KAbaHCVb4nMaQgX4wI31uDuzsf8wDWq4Q0N WTuC5dP5/xznhuFZBuqyIKasvfmlzf2h0vewyZQ3X8AUlsiY5eH90IovfFsn UAB/ABIMw286q9/Aq9H1cLmkuXyLzCrWD7u35PfBkP13nJT/W54loUtZkYsE YZ0f322FJSxtksSNo4OwdsrhOEiRva0q83bYR5f1DywMixVR9JmLZle6rEig ns1ZsuUf2LJnUS5UCLdqgrUKXWR3E0TfihUWOsfNikahaz1VyeJOF3NTrMcN S1X+Loxp0EXLF3m2zLChiuyGF7ChrKyaYXTWD0bR+fB7o9IjKlY646KcjZer wzJOrqNRnJfv4uWpY3imw66qiIeXnHAr2o+oKO/jxdmYY5ZZih5JRF/eTJSC A40nBA2s8PhbvUIeVAuySw+1VmqGQVfOBtc1nb9vlwsoYHNSqwUUS790RJd/ NYwVnU+N2hq7f79Jk3C/C6kBdtTXZZa0iaPY4GwClWKWZR2upvwaqmmp3UUW Vl++yGMYm/8T7pLnLCqWPrRtLNDHzLG67uiipbG2MuigPsbw5uOio1Vgc4T/ 5/ujLYHqhPui+FHSKgJO9o62B1gZa4siWGk9fzuMgVLgnC+aBSWSE98TnQKX o63mfcyZuLTgy4tB7RtSQM0XcoLq1iW6ttX+e+HhOo/DlVjCvYCdx+FFsCNN RtGIdLpgL//Yh4fA9rkUGdyiE12uGGLXLcHlCvsIjizS38Nl/8V9RUV6jM6g eZGEPNE2r24+PZVDrvD/08Zh3NZIK/L1ZlGG9ni5mDYvi0/DGaoK/yxO4lAn V37Q4GFLR/YzXKqUXV5U8B8po2VWd9NL/jWj8yHzA+zDZmb9YbNLtu0JyhdB AIzQ1fn9mVYFfBYdWPf8wm74ORz6fitmkeKL2JytFtsLPg/kOFvhpVklZrJa NLTPxygOL2bi6DjAfoafN7ew2qjyjh0B8w9hFq8h4GbeDqHaPNzS3lw88Lx9 28gucLWnz22y4S2WAPDtSAbP6YyIKGewj8BlRGLOyBz40Nw0F67Q7J7kscsL 6szNZxESt2Wwx57h/C0NZXC65Kdq/QTVT412otJPJPopf4Pz1O7ovEOdZvTO Ngyc06hrd5Yeb5I3Oou9Jcd9g58HLs7TCPBMH+AxOeatpBun35aY7eeJvZ3C JDDewfl18g/EO3Dj81c5bLu8pP7TkPq51iqnxc8DT91+22OSo+N+jPPbr3hn TjL4510jg8L3/wjn79PDa7HenMQZNEVLCuMDnKfFz8WqQtwKjJfYP50z4qhc 99LoP8xaWU3gxxL7vQ0PR2qzZp6YlaiGFKZf0n7zf1PzO/wHfQLG38r0H4vg eB7DXeN70fOPhhrPT92eaOUL/T+X9F850yQv5gZemXdEMN7H+dpvVsnQVi4U 6u8GUvtNQzoA6aS3heWs8PktLX4T7SK60Nl3ecn4vzkmu1+I7pr3lLxQd837 GnwmrgHjJf23iWi8doizaqXcrgLjAw3+e3G3p1C/xP7ptAGrbrgiPzxmSP0n Svu7fzG5nlxeXhAx/kbHfm8gchLrn+nwbAIss/lZk5/r8NVIzrr6b3X4h1P2 dnjJs279g6F2/VeTP7v6A0s2fjdQ80z4IqPkZWFf7b8EvqfmbxX2b87TNEmL dGJLEPDTobz+JD1j1Wf8TGJ/23JTUpmt6TwFzL+zuQZPR/BJ0AjA307k/hM8 r7lKqhm0IQT8ryUZ/zfQ9mXwLwpgmf1J5s8tu2AVdpyYd6u1uaQjuTGM2fw5 1uIfXfuZRiIPjbefrP8k9b97PjxN86f1ZvEEodBTO46hvCWL/0qezO6ewALE vNdD/ymMn8Cp8byv5G/KLnh6yJo+lPGS51+/fWUHuswXvDGr7Ufm/4sXBObN OauS993533Jl9suW3sIlW8HfDofDcvFEV9dQH29mwr98Z8AmLbbPpl4+jsbY 2rQKsKipkKT9jJ7ER0OfonDFzyVr21nEspGoCCZA5qRv4V3oTLa4nvsSJ/XX 2LHY2p56iZcojWJamWJjGMfLghy2wmUtPBUH6ZSXBDmz7XAg+yl7k3vxQIlM 2Luj30eBSH6mlO9yr1O+U2v6J/wyF+t6Y41ImfX7yO4oE7BdZX69taDOjMHN 5nRxCntcN2zzbTNx1BlYP5/ghqJFsaXmabHuPNOYDQwkH9PB/xbglgq/l2p3 9HGRdlcX307WAtyT4Y/r1RM6YBjuq3DBvjcOHynx6PD69pykYjyQ4UVW/anM 3z892h18rNJeGilS+VCGkzObSFq5Zh5/luEL+Er4QNbyOxk+PefJy4sM38vw YjqS4RGOF3vKn2ar7VO53buLv7T2DDUisWIbOiIAcNhGh+CV9tWNWD3DLQ3t YgEMt3H8KzsmryYJT3jTWY46DVQkUru5IMaPdXkaA4n4iSYvyEUzXrKM+zP6 Ym+w8DCe8pIw9iHmDkvBBN9JIFOeCzGKWWF9OL7Sbm9MBN3o4Sai8wZdnYSn 4ksH8MGKluxgKJn9t6cIXiW8VPHHoZOiorxk9r8LP6smzRDbCIa2tG9Y+DX/ PMEnWZJYxDtqfgaHn967aQrGu9IUa6HXnBxfE7pYenvv8rIU5+XtplAC431Z ioPlZszJbmfeCQYY4yUhNilfiGECGB/o1R/yPHkrR8r4UNL/dF3Ky9ge/hN1 9D9LXhGsB4roj/I7Gf+3mt/LXjGwTcmwdw2330iS4oftb3l4/CXT/yJZIqeH /WtjN3WXt6TjN0leVLxk/MJ2Z3mKn/K2bIkW7000Gip5PBZkOHYkoMLxWLB4 K4euDwtcMnrhxRxOl7yvePrtLj2ccgvl8WiQ3dou4RkeyBuvoG1U+1hLu43h oY52B9X+rKXdwfCdjnYX1b7X0u5ieKSj3UO1v2hp9xDcHupo9zHttqWl3cdw G8XLLW5HzGswHB/xtcOs9hmbmzBu5OQoLpmw2b4TdH1d8vjyr1w3dY/a8Lgv fSUYvbc2Znf4UXObYrUjH9usOJDskS23Fgq3z06mU/JE5ps7uiCeb+ATCA/z LanOZ+iRy/steZpONpvFfFNttexBUr2Pi2m1d9PRIxez5fyJLO7m9w9VbV09 cjvfwi3MPOzpkZPZ3WIFnyuYk3pHaz/y5v6+Qkd6JLvefL7Z3G8uB7P0yNVk 2wIHY32yaQgDa9gH5R4TTmj1eNKH1Wo+n81n1SmtHuh6M5/frUnJWk4PdPuw Xc9XlVpL25CY3dI6Tx4ni2VxXksPnU6Wy5vJ9E/+LJTfY5g2+9XStKUfMNpa Izy4+A6Wlhws4vpITHbZ7tzePMV2NUTmIs6iVPBStR4XKAk7+0Svk+tx0SXX 24dqEwtdJoXpe4sMpCTsg4iQzV9jlPzxcFPs3Lk/52wPQWOe4cZFF70NY6lS y0LRn2G+e9tDukScLKjHhaB5X9+LlyXlvo8O6qDoIuYW8Oa8fYTxMi66KLSO jK3HhUorGG8L9XW1dlgLtyUOE/aRFeigwu6xcGuCd6H1Yhv2k7SP8Q0laPEa GFtl2JYUZW/AMRS3Jv7ldZh3t6/ZjsT8y90CQhBOOqLoKmH7S01CF9TmLMqL 2xX4cxwydJkkJ3N6TlO2XbNF27g1/W8E+4qFnqU8LImiGzjDhnHsvCSKLpMs g9TZln2pUoDi1rTZfVCt6Tv1wnsR7+DWRA2XHZhkR0nMbfERHx61ZP47ei/T PM9fsK20WWHHVqGNzQDNE5TSkYODcIoSd/6/Gm+P2ZGaj8ZJSm2UDn34WEid YXR8bXTZOhLujLTRRRw2quzg1sTOpsAaIX0Jd1HRSw2tuDVVbx3ZCbNytuNP qrpDPZTt0mm2sSvxTTDOQVuxO6Uzabm2HF3EGDlwHbVW2kB0icfemPNbW11X jrI9KWLW9eSdc3OkLNyR1g0LXNyaJnkO19VQVcXTtqW4Mt9UXOxiljKK3Tfm /HMXRXBbjyvzTaAL4di5S3ULs/cls3P7OL43VPYrQg48S3vk0ImrPPNSorg1 0cU5HDxJoLmgteg03Vice7g1lcdnqxMeeQinR5NLVsFzteac4kxR0yQ8Tz3n iDhAfc05p8t7oz5zToP3Akmgt0vYrNMMFMNnasdv1KC8sSzQe00kqD/spbVe Ie3hwG0vrQ3U1okRq+HTcFC+I0PzQ3xOqBlPN9NuWOG7vVC+d3zJTNfYpWUW t6DxWn2l969Sce14emRpo+BS2VVHFYq3MLctbMqC1NYEO3L00ZbakcT71zsR F6LrWgYjTwMVTK6A4i0Mu48QhQU6kqNihQWKj1di/YtY683iX3P4p3nZolWh +HhdZ2eTDbwTdd7PnWXOIBh+u6QW2gdE4OX+nN3NhqybpeRDDJ8LjsVhOEqC Ad695vBrIemg5OwcHom1mkyR2rpSkkXECOyh5F/ncC8jfZQkaTnkEHKEkn/b nhQNpM/56LhohcfS53x07Nnh9ZCL2opLviDohM5PyatAtWVpaJ3Eog6ybAXq UlT8tJajQsUqm8kXXCtSYdyStnR6O0a4/Vq4Kc3ztyiNoxyzCgu3JRow0QBN tAOqk3xpo27gS23YGstQaZ3todSEN1vbsZF2sm2ZVunQsXGTgLdc5e64oq1a uI3362I7W8mGq+1L0VN6QG3Cxvt1evwV7akrxTypjfcrM9t1khyLay5gEw7T b9hjNUNVZlwDGc5QzbQ8kuFYagaahmsVw5FMKETYZQaFHI2BDP7ue2VthuG4 ar8Bju77xUANx9NzGBxkOLhZrOblE7G9oxu4Q6noIGekZkjyK4ohfVN1UCCb Z2y3jJREFujg9vDzkEZH6lgqww93ranYxoOOeUxV7qI97ppcVwnjo871vqki iAUWQVjDoSWFJzDF7d+FEigsn65mr/lRAsuNFTRjAiiMt9jFIMSPTWGNSQtp Mrg1XDltSWDcoLdvSZr/CM9HpM8oHKi76nW/iAVtRuGxbFjgFsJgRTAEmldJ TJV3O4vClhLGq60IiC6auzyF5Ra2zPbLg7DSDHbVMPLQFPa0NIsemsK+ruYO T2Hcwn5sKwP9ecjfHh2v21WBJpyc8xZP4bHUPH8cXt/YZt6uYgrbqnDbYzHS MvmHyWhqtuU+bC4azQbFbL3ByHgDANyebqLjcUfX+cskfm0MYsA8JbZ9a419 wHAz2E63i/n+NSrjgLJ2I27hK7+aw7KG5s16K1j2yjln2ORsTc5vcY5uPe0m 6GpyttvkPE3ODZqcr8mNWvUcaXLjVsME2u3yZ6M9x7qc+4fLk5xfV4D+HwGv 0dK1GGv8R6Oulq7JOEGrqro2M/IaTcMvbhWd77UGha7VPKz+XN3/XNWwpWs2 3ugPv/GMunZjWy0w0B4YTcOxdC3H9pugrWs5dtACtS3H8hok9dYX96a6OAh3 cCoSd3EqEndyytqibk5FMkf39wX1tEnc1alI3NmpSNzdqVsIc3hKEnd5ShR3 ekoUd3tKA8Qdn7JncNenNAfc+alQiftToRIHqLR83AWqBw3qBJUo7gaVKO4I paghcITatmS1dOrbkuO0UA1bMpzC6A3D9nRK+1VpDYsx3GFVeqRT2q1KBzql g6r0WKf02HEcVt7R6H7DG/q+XxS3dIpXbejYOqWdui6OTnG3rotOf3pVDzk6 /emN6rrodKgX1HXR6VG/6n9Hp0d9q66LTpf6lbm4/NtD1fWCeJShIvEoQ0Xi UYaytmiUoSLx5ZSKxKMMFYlHGSoSjzLULYRFGUoSjzKUKB5lKFE8ylAaIB5l KHsGjzKU5oBHGSpUEmWoUEmUobR8PMpQDxo0ylCieJShRPEoA0ENWYChNCM8 wFCieICB1lQUX+CFBeEFWlgUXeCFBcEFXlgQW+CFRaEFWloYWeClBYEFXlgU V+ClRWEFXloQVeCFRUEFXloUU6ClRSEFXlgUUeClhQGF6r5hddqCXJ22IFen LcjVaQsiS1sIAwoVqU5bkKvTFuTqtAW5Om1Brk9bkOvTFuT6tAW5Pm1Brk9b kOvTFuT6tAW5Pm1Brk9bkOvTFuT6tAW5Pm3RQfmIwrB72FAnmij+rS9AnbQg vZIWpFfSgvRKWpBeSQvSK2lB+iUtSL+kBemVtCD9khakX9KC9EpakH5JC9Iv aUF6JS1Iv6QF6ZW0IFcnLcjVSQtyddKCXJ20IFcnLcjVSQtyddKCXJ20IFcn Lcj1SQtyfdKCXJ+0INcnLcj1SQtyfdKCXJ+0INcnLcj1SQtyfdKCXJ+0INcn LcgVSQtyfdKCXJ+0IH2SFqRP0oL0SVqQPkkL0idpQXolLUivpAXpk7QgvZIW pFfSgvRJWpBeSQvSK2lB+iQtSK+kBVElLX67xBTC79wY7BdvaRIn56y5tU4O lr+/kIZxCSlqFPs2Tv37p0P8dPmf8q+cbi0BxZ8YbdhKtCwtUtyKa9QSOM2N I121COzjPues+orbj8sdSsIzbJiE3e6Q54+Ojd73oSnBhk8WKM60YRKeo+PR GjropmNXtw4WJsHTqoNtoc3ABX6qlsTaYaT7FGhDBEoJcfRKrYH9QXjdzFiv HYbBM74BXCniw7Zuw0/2CXlhh1iWhoiRXIStIWIsF6G2yw9LUQu3T1sIbcvy +rSFrTg7p9EWYhGjPm1hK87SoSIcm0Tpc4Ka1lhDhDuQ/dga1nk7lYuwdGpx Op7xDzXY/AEg5LNq+zydpckJP2ihlBBlu/AUbeFrVbHgsDZ/ChmREOZv0+T9 Hb5XqjqNjEjYhWl6iFL+FgrsVDIi4VBcOnPIv7qfPGudTkYkvMcn2Rlw/pQy IuEc76OXQ4xdoMafVkYkpOz7sfjdwIFSwpHGX5K7hfnTy2gdqg/Oir8gxR/c kVRidsh2xZ/vstfW19gstVXGCdyLVV6LJffcuEl8hMfDnh3uUHhuvEfhG4Ak KT/KJvPcqFnVB0TFY8TyNNoC7piB28UGylPPiIhf0dfkOUlz1E2MdDo1ujln X6iIQONBRHdhiU9DIyI+EtGNEuJT0YpaYA1q61jntPBYuOfWcRY5u51FbJ22 2jo/XHsbPr9HyK2LfCZBIuImjcJfqAhPR8RlrE/f97Kz27iIxX7+uWO3uEDA KTnDLXmQcL+NcuSOYjvQqkXhMuCbTj87DtQea/UIu4OZJHBqqzsTDnvVQuQv HB3rjGVDZFCt0tR1cWx2Hc8euaHEUdvonnqu6pN8QhGu5qRYnHSeRfGhPV4c tY0e6VyCBheDxsV46INkQyJpCv6CPEzEKaXRRb5KcuTTso6OB10zIdTEFjFk PCTHzXHrmKT/Fn5buIi11Db6TmFZrORa2g+yiFe0Ppu/OiJsLdOCm+0g5SR8 EEcrUJHNi67aOsNznpxowIVdneuqrfP0/D2Ko/SwYxeXCkT4GiKgFShPPtcp HSvtBnFHfUQQaudfzeueB/zFe7iI6rZYGigIphR3rCGijBXFEviL+HQeZLIU JHEsfREbRITdoy3uwoxO9O2H8RwNEey+r7tDlgm/duK5+s25X2Y/36iFwnM9 XKZIT8c678/5/Uu1QGT3aTRqoWOddG7ugJwIHeukRv0zPORIpOIFPdqCiqKP Q7u3KaKHdd5/pC/HfzarTTNa8Yf6Iuiy6Ob8Ugjil5lq60x3H/vy3g6IvDox l6+2zhwutIB1IsQqghb1NWb27MRubk3PJ2Gn+K7Okrv6JsXjITm2b87kLwBE Mwcsk3Qbfv6gseP51G0LtXW+ZTlbIxbXCncfxR9xOyEUX6fH0jGWtgQsHWNr S8DSMY62BCwd8//sPf1z4zau+6v9V7Debjfe+kOSP5I4l85LE2/rd9lsJnG6 12lvPIokx7rYsivJyeZ6+78/ACQlSpZiOS/JXmfifsSmSBAAQQAEQbFdGEJe OKZTGEJeOKZbGEJeOGa7MIS8cMxOYQh54ZjdDXDIDseomRUFkEiHY9IZFmtA 5IVjdGMDkcgOx+itDUY0OxyjFxfMvHCM3tmAF9nhGL24aOaFY/TtTQY1Mxyj 72xASHY4Ri8unXnhGEPbGIs0Q41NpDM7HGMYGymLrHCMUVw688IxRnsTEJnh GKOzCYjMcIzR3QREZjjG2N6IkKxwjLGzERZZ4Rhjd6MRyQrHtLQHYaHqi9Ym 0pkdjlkJw6zFJScc0youo3nhmFZ7Q6O4Go5pFZfRvHBMq7iM5oVjWsVlNC8c 09pEg2aHY1q7m0hHZjimXVxG88IxbX1jQtLhmLaxkWhlhWParY0clSy72C4u nXnhmHZx6cwLx7S7G4DIDse0tx8CIhGOae9sACI7HNPe3QBEdjimoz2IEDWW 0tE3B5EKx3SMB/AiGY7ptDYAkR2O6bQ3Z2cqHNPZRDqzwzGdTaQzOxzT2UQ6 s8MxnZ0H8CIZjuk8QDpT4ZiutjmIVDimW1w688Ix3eLSmReO6W5g2XPCMd32 JkvuzHBMt7h05oVjusWlMy8co4Zhzt3ZYop3/tn1Dyen9WPnhl/FXiJfi3I/ 1YzRvNpAMP2QmXJKuubaNjKBqNRa34Yn5LWjhKdSe32bdEpmqbO+jZI8e0KM 6BanRyJX2i7UBu/nBkbvrK8MHnQ/tLDybuYAAl8u3aB+EcC6XAwggdbXV5Z8 lamS2eOXbCPp7cTjF98L8ccSPP1/Z6Rq8U96T1cv3JJe/plIqlJjivzmuXrO tiAolUS5Xrhluljtle6Ekld8rJ5KwCMqydMthVu2tGRLo3DLk9RKSRmaIwfv ApEaA0Z1mMz/SzfVC7d0A9sT6juF7rqWf8h7LVbRjW8fqR9m7bR68/B8uVjM k5eR6oXbB5mJDkbh9svAz8iVaBVuHzpTax7HGVbT9Nb3v9I6eYXIOv699x1H ZX4qRW9Ne1wyzUBJhgd4oZUcg+0N2585/8IgC9RdSc8r0p5GQLXVuxvSP/jp U25q3hoA7tVtGvtUYt56ACv4py4bKULC0J6FQU5S3hoAlxanID8lbx0JTiaA 4lJoTVx7FYReXAwX/vwqA0BxObTgOfiMp6Yf3sWA9J2NADh2qn3yWpI1o4Br ohXTYxSXRJOugvgxBcYoLok2v38iBcEoLolzvqBK3TZlbCCJmWmRRnFJtFIX da4m360XJPLbkyELo8s2nI4/Wtw6Z2XerZtNHixMsdLhHGQyELQYO+X/ivy/ RtM3bfuyOXO85asn+mh4k0O7/UrTNH27o+Nf+Gbwv5rW1rdbr7Ruq2N0tO0W PdfbhtZ5pb16hs8yCE0fugyvfTeYeGZePag2Ht9HJJGiCeK2X/1FPq/ZtwO7 x3D4azdMb7RAx+1uN7VWU+uAtup1tJ5msBvBHNb/vGDfll+Xodnx/CpqB0Xs DLxCkm4EkgklAgO1D2y8fNSaz3DLMYCFPgsnDhu7U4egK8CMBDBN67WNXicL mBmGvnu5DJ2A4X6EhN1AgFBpOIHVEHaAWiU0XS8g7PHX2L0S95NCZdY3rQl/ 5IbgRk1MgIeOJZuP1T7CiRky03fgkRdKAk4OztntxPHoKcAiCNCvNZlDNcLj ANFjzmcTFmIOmwLcJTz3HfT4TaVfboEYKJal6AwlFXiFFA/7xyf9IXRNF6TK 3id4d6JnzmSzBhANTJ37M5Njr4B3gx6hc3F+Vv/QP7moD4b9D3XeW7Qzv88u Tgb/KJVfl+jSW2EL+EJuX9wri09qUIP/kuZinw2dqeeE8ZOfEbl9gZjpNMDV bcAYERInH4f98x4MNgO/M0YyIP4ufGfsfgaabt1wQnQGeGFpiLdwvk2i/xZ6 YwYnOyIC2I+jBzxCYmoAAUrgX1hrMNMKYYE6vYMxgA5gYOEBwqCzfnQ/LjS7 dpwF9etiIAmv516YPlANorFY3GH1Fu/SB1uFfMa6YHlI2KCjf4GOYSBF7pj3 fesA5pcOBkv5uNs4RqJbE6BcLaemjyj50CVBe4s/grdigpRYm3fImfTh4nwI 8LAuOu0+iE7gcFYSDF9cHczZCfJ+4+D6SnQIBMatAAygEmGHWyd4oaZ5hfMl JFRA2n0XYBFmEbcQMZg8ICrsPVjaQxJeuoWUrr622dbRyeC8yi5NZHTgTPm1 qjU+7bmEugEfXQzAOp8tZ4EziCQfi7E992kCoGgxNUHKsDySlgbrN64aGUKt G602FX+aIOfxJ3EiBRWqJNstFov0VChnTgSKGdtiJpTELxkyhOenp6dxOSgr GJAAio1OpxH/146rnDjhzAyuV6p0amVpt0XND8MLqKV3NG3l0SEMni/0wz77 xfTq/2ta80tQQ/Xh4Wl9cFpOkRtM3Uei9/x4cFqAmjQCIWmMYiiouidX9SQ1 z5re/SlWfoTezwjQut5L5UKa97GIX1G7qe71rqY/Xe+kOEEjWioGr14+X/8j /X+yL1/H/ze2jTb6/+0u1utq5P+3tl/8/2fx/8FmZ3jGgcyF4Z604iHDXObm Gr5DW/jOHHSYUYAajDucrg+zfuw6U1vadHz6NiDfFEFCQwucYPBZYFkKDsgO OMimD84YCCG5MY53FU4IHPfVxnMRj9yiXiM3AbP9qrFjCOtr7ugu4ZcXiltX wV34Y+n6lN0YCJzJrYhwRg/dRNKs6RKW8AuhB2u0iGD8UlJCHt1ZtQwj1cxb zi5BGRKvyLVfuIJXNjr1wiHkLID2Ejr0/AmXCtAkA190JV30dGgXlo19dJWJ cKV/cp/Aa7sxp0vh3sHSBHw7gH3AgoVjuaZwAmlZABAqR/33BxfHwwoTIyBd 0C1EP5jMlzBqUEwOFi6qhNNnAx0CAYKH8lLFsaNexnew7DHJybbnfDxIo5CT LaSKuhf+bAQigajkDLKsghYoQpJ34hII6AOgYpcIKcU6MS5QB7ogKxZD3Wo6 odWkn3YVAKWacrEAnpNYoMNYGng2VEDmRCIWmpexsFZJAKV4osscSvmH1vgM ZMrGDri3mZxJYtQA10suc7gEMa1rKFkdaqxmYi9iJeKK95DwdR3xU6wGG3JK qyINhHlXAaB7zTEBlzQTG2hLbBCLSVocXMVDBiM5R9aUo4iA4jNUZGHlEdzk 5/GBcT4PKb2VL1QOaFUCdfn9xfUzJ5gvfcsJALFT352Z/t3o6OR8JG6WhW5b O42d7YbeMMplnHollR9YkMOLg1j2HOJIhHpZTNAEJJoMRSFtMv8bzculOwUP YNawvk78T9cNtPndlrYNX9pai+y/3nmx/89i/90xHgdBPRaWA1yuW6Te2Luz w3OXZO/bnx3Tdvwea96YfpPPh6Z1E/jzeYjeo7sMKHysSBKFEnWM23WbutHU dYzbdbZ7re1UKLGyV34NtsUdl8vNd2X2ToQVE5C+xXIlIKizTMBxQBCqize5 gvnkzaAM/m1SL/icPmcHR4OL8/gnJfCq8wn7wzMNAI7hzGJi6nFoUcNj9waV awi1+3yh44IqrkErqxFV6u4aGvs72Al2iCbFB8XpX9+ad1GF06ljBiboV6/G Dg9w17Pd6XbVfg7nizvfvZqESL+xrtsYMOq3KE4IygDdmsVdDTdbwYpyv8UG z4lHNrkNDObj8Bb9CbSKphejuVj6i3lAXhzZedzjHDsU58LoyuUdu/JNtJk1 DIHduBRD4zEcN4igWBEpCGcRY4iWHRaS5mLhmGhu0OZhbVdEdQOeHQCER7Ds ubVE186MA0rkZ4JhvI9F5Jpckl2zI1jgnpg2hsdcymUE2hfLy6lroSsMWKIb Q1Z+HjNM2GDoNuaRPwcmzCL+CO/FggcugozI5bwXNAMuV+DqeSoyMblJMjlL kYv4KDGA5KMH7FIZspi963gC5qegYLOZee2gf4fBOLCxEjMYpkugOYJBrvrS BbfJnSIX5+NsAZOCBTgMKAqrMJNLUQVDqEEl4ir42RRIg/aU1IQRYtNH4btr RPNdVWmBZQWu/ds/2X658j9br6uxlinpjXax6YW0g9IqvxaOVelvwV3QDMEU B43JD6niAHdew9Xy0J05q6XkDidKPQdG3gmbroflavXQducrde3LFFA645HC a3FrJwtWkbGQnGQRcimBQoUr/sakUi5ze4FCj/NurwymhNnO5fJqNJ6aV3vi OW8wsl0f2cePILL3g5Oj0YePR/3RycGHfknLeHDWPz3+taRnPDn/++C0ZGQ8 eH98cf4zJrC9Hxz32Tv0f8Y29DrDw3Fbpn9lwcTzr26qZTHPcCPnytori+wF RPcdVtgr/1kWBUjab7qx8889WYLLGpD633TNaMelCh84ZOyZ4UpwOeNOWPxT QEDUuNIgvbXPRN8IYMy2tsZohucLWCpuVWhV1ViYV5Ua+zj6dPbx5PhX9h/4 enjWPxjSt+HZxclhjWldTatW2d+Yxsn8U3iYYxBkLwS4IESOD0vIypugB8IP 6z7vbcj7iXqh2Xnru6iBfvcqtQjLqmAWzEI3ZFt1XRR8QT5M0UAA2lSWQwLI wTOQAL08Agmx6KI/1KhIsmBW4EJM0lSpsm/2C+CqoErNAUxBxODPLabHsy3s cAQrd1iaUlxCylKV7a+gQFLXsBchoi9FU3kQuP9GqQN1McUBSqAgRVQ2F79X H6eASHRkRZc4gFtLBN+OELYl00p/lktrh5aD4LMHx/VNgJwrU2azZF+NCQpK CQ6WvkSjCwwXA0z48UoafP+CDuJjfbgNKr1ferSo7LFozMSTU27xeuB5hkvf i+NoctcP6DRxw4zVuUcDZvPauZOcQxAlLDOY0PRQz5o41rVYy3PvAvfK7mSs IXDAGcBwD28M3prJPOcWIxXCZj7WB2xvroyqelaRR14QSVikei+X47Hj/2Z0 uqqaDX2pYREECJ38iTmE+J1SY0anB4MzAIpsGVFgJv2I+CMfwTNchzBwPj4u HCVWFWLGMD1oisnPrQpOty1uZqrs5OL4ODn1AinOnAYS5+abACZ7rFNqYiEy ujjvn50nZkzUCQg7Kc8IjF+pVjP6vmcSJdXjm4DmD46O0IvpScS7yp9GZZ6t iXGdhBHfU7TU+MoJgxhr1BHziBnVGuPkkQbY4sOaxUTkBO8q3ZckGMasRIP2 3vXsaJf6jmdMoIcche9EVBIo5C2a+Ac7eMeRQlTevn7LvvuOqSW/h2+r1ID9 WRZv0Ob6kNfZk4WCbpROasc4JPkTwMDvsngJd1ysIXQkBR7QjPj+e3QD4Pn3 3wNs4LmA/054CNgk6pTQJ3TSsHAuud7SScCQUFcx3ucY/+c/LAYXKuBW8QHF Yy3uInVfwyrVCLYoZd9n2YVSnPGbkCHy98TjL1LcQASngSNGWx0uBWWl5CHD 9TWIl3Xq+8xYQUo+VBBTixLIiQf1egJBUaqMdgwhQ4S2InSYTnPybU3pwudG iuxk1Af94UOT4HbzHfvk0H6EjQcQ+DQTr+2IoSSGGP8/FmZZ6AXyvUQDUj5f XjaNH33/F3cBGpOn7GPN/m/LwFhvMv7barWMl/jvM3zUqCuXhIyIq5GMuBo9 3ei1UxFXcPmYM1uEd7RhNHMCOlYWucEvAdyXAO5LAPclgLtxALcpqcGILddQ 4jQQqCXQIIbR3G3zqq/BixGvNtsajczpYmJW0f2Oy+bBeDSqljG+iZteSw8z iaFbXDZeDE6GbdyOQm9mpcYUj7hGVfiOldrf0nM/Izeq6KfJwuAu6CQKPoxw I7cahVHlnq8I1VLMFftH/0lCRNJy6vPQLmGTbpFA7jKw3YxOZ6Y1gedN16P1 vxLwXamCfZheAj8EmonbDNMUrCRqsnICLdP9XE1HzCkxONkWqjG+VHtx157A /7NdYLj19fw/wzDAXYr9vzb3/4zWi//3F9v/55JEe/8dcWZHb7Z0Zui91m6v rRfb+4+gpL3QDssE+lAvtB2D03aYttNrd3p698HgWgq4FtPBowWIu0lwh3SQ j5LmuFuABxXYL8AEMIHn0sdQzhi5fB9DHiYJGqv9qr459NvttVo9LcUVfDsa GrHlAjwOm9xH36ej++Sdgc3wKHwMjgA/eQ9OYN0E08fqYAZN9KVfvPgXL/7F i3/x4p8gDYMr/BIq+IemYKymQ+RkZaxkP0S5DtmpDc5nPPG3srMvitOJDona iXwHQf/R4HA4OhgOz9g7pBrGCRNKY4W/l6jIz3arNfku3l6Z/Gg022A/Rr/0 T44+no3OT/uHg/eDQ0y/KHOsaBuIbd3MXbtK22lK/9gpbdXgFzDzOfhE4Wiq hvs0CoyszRq59VR5E/we/h7+ghj3mPb5zeffQ8xY7bE39u8h4M3NnrR6VEy7 UPJl3aFf/4HvRPHvRLv8gaMmv6/AqhJdEgrQJoDB8MQ7/OPxdBlMaIsMpDgR auY7wbFv8mQbwsjzEaYApDeEhd3ELXXaB47GpoH20eRmG8dg8OPFsH+Ogjjn O7rJ6spQ0tkItTlJ1z1NxY4xNXv0rWGSUUk92+LSybcysZjnzNA8spez2R3o 1N+6SpINykW6DPBNFyH16TJSCnEZThBc/Y68+V7WBGHJqQid7OVsSyMk4pn8 gT3t3TdRebVBAM+k6B7I8QKp1WL/eMONZER58PHk4OzXOAOHs7X4TvKm+Tax 5PSirAzlbS6pPeXkZlAyw0UMB+dA4a1kTt+6rWQBG3fEytFO1fm1uxBufrDA Y8W0xx9tiyn7iq9Xdxq11SLvrdyXVvZfv5TvF4U4Scb3rNlCGSA+z0cnHw5h tHVNZvjwHnKlR9/L3Du9T9pKkdJTMhDy8AG9A+jsSmzuoQ16BQ5t5fUMqFZl vyUii+/oc02FSinqkIZP2bMPAsv0knOC/wOYSb1Rk8qiJrfdhaaoSVVAMtNO 7xenZT5qzYVfvPw6Xqyhk0zovaHjS/F0iHMrknNBiGK8GZyYDWJvNJHc8Av2 SK+JAPUtjuGnshjUHC4i7QfW0h9IGnnv/CTe0xGHSH/jBnQCH+YaH5rqAzEm 9ftEuN4v4GKMYCje0Zr+hq/pg5U1vXpUDxYWP/f/kRrBe6dJkitS/KU8V958 BsH/jnpQttfF/JdTLAGCcww9pLkrAa0OECY6oAoQEwZ64vHnSqSLEkBDfjDp 9NNo+Otpf3QOs/fkpzQ+OYDxpPiV4xeDPDgZ9n/qnxUFvTBtuyjk04Ojo6KA cU4WA3t0MOzv3Z85UVDUCfATqhx2KN9I4zm3iviOxelAOmkbS+2W8LSTqwO+ EwCkCGMdPaySyyGxyFpS3M8UzgtcfQLYmTOb59F8P6mlOIdHXW9I5Un1lMUH vkaBO3hRuRjfta5e1GBlsQKts6d87P3xARl4gePDkjwklz09CPESJ38tV2I5 SwO+Qko5DDneCHnCoGY6ih+SNtjcW36QsRYuezyU0noLq/3/MtZ8FHlq4H+V uRZUb2Cuc5yQ5zDXLz7GE2neUq49ztLJfJJxYc7TyrhejbSyWMPmqGV6mqWX o2ZfRzEjCfUfUMLjYFCknJOVMrQ3f5DS3oUUqgC5olBlCC6pTIVXt894hCAj pVGsT/f4FriGpxDUGF11L157JeNQTx6AQo7C4jrnUAK90GAJGixWMsDdpUWv X+Nv86I4uMODSHEtnN30YozHjx4p/kJZJYErUupePdoVW9RnioHi3Ev4DftM QYwvxOUg44OqYnrvCVnKJhndP5ugjF3PfmxJwRn7TEKC6HOekxJSz53IwmeV ErmYSIe7CbtEoOcvKC8g/EXEhc+R+0SF13hCMRE2rqyiTeZ3RUpEmSIkoi3p /TJZ8GyDEckH1vhmP9u65smHYt8kVpnSAQ9V4eDIRJYsTzSSSDyXbBSwOetF g7/AU1Q0xeEfMwjmlktvNXoWLZMWHzJFyn6VIkWUQhjvE9ynfZ5PsJLeVSxd dFaJMdWHEk7UU8ndS0Les+f/zezO06b/rcv/67QNYyX/T+t2X/L//mL5fyRJ lP5nZObCFUr/k0Cyz6Dcn193Znrsp5MLfOcaPx/9uClr7MNR57BxyOrs7PyA 4T09TN4ZypNxalhDpgnWbRfvLmBgDuZQZTKLwMRZLluHVcRIrxu1PJhi0W9T PXqpMypTao4Je/RyOLtBu5nHruXAmhbTojAlicwhvgUvmegD30VqWCozDNMQ 8NofWLlh4h2+bQ/fWo0GtZKHHNL7QdB7RPQijANJcoUyufCV3kCCj2zF1Cng qsjq8p2x4zuexd+cp2CJUOTr+MbCc0gSCQ/MaTCPaAGiMRUqIhok1r0Bcb5x 2O3cvw4iYsuUDYWvU19aE/GM+JKgukLt8c3c/nxGPJAswPZruXAPC7D9fVwQ qGMaFeDGic5jf27ylzX3LIeyOpkDWPDXy/G3Zft4nUR+HpiIJGXkiiGI1XQx PGBt0fvKo8wxShxbSRjD5gVyxuh9hgD4GiYxJ35Ir7jk2XkBm+HL1C/xXev8 nZLEXu9OJieK1oiWincyaw9kpIm7c4KYhjw+Ig4yVFAHYfYXzVUPtCJeUYAU w0DTdZn4BlTmAyXivQnN6CU056BYtpVfeEZF+YmaS/n5f+xd63fbNrL/rPwV qD/0SI2T8gG+nLb3KLJsaytLWktO083N6lAklaiVLa8k105uu3/7nRkABMFH knY37fZselLbJIABfoPB4DWc4RiOJX90bOYVnhwWFZ5cjOCjHzmGkskfXZsV El0HAxbpRzQLLjxyDOGSP3KbFRK5g8GS9KOLYX/0I8f4M2qaQLMykyOTi/Fs PB8OpjNY4dFK9wV/eag/osGJBQ1vOp0nBpH+NZolF4pDl7XbRjH2xaFcO39x aHy3U6Z1nNXRqhZVRN9FC8DNr7IrPGI0oE3GePN4ccjyPz6ACsYgqKeywm/H yxQUCbPBeC05GJ0iE9nXtFWw7kPrkP1r/5DMIfsDyTz45QmNtpNDdnrIzkiJ D0grw44PmIAKVk0DO3PAnbTvDxnow7cdYGn7vsM+Z+03nQ77GR7/KR7fdjqd PP9pTf63Mv8bevqnkf+smB+y/x3J48+3hUyDYiaRjHl/VsQQG3R9d9afD/sn M1Ad0Lmgre7ZOlvu2TVbrPYlXIXsSPxaNferr1j7WrYXHr/5hrVd5xG+kvWc IBORi2fCrHkwYHs1QuXsQJ4/NrfX6Y7ZhwzWHq7Iyh/TZLORapICZ4AmxTsH mgbjNF3tpQE7KHCMeYQOijdXN7d7GT7F6JqTdnzIFocsOWTpIQMU6JIm6bD/ Y//7gLXjDvpGOAEci84hayf4IwVkDxkCg580aDttKPFEFfjaYGMbXkGhXUdn AIpAjh5hw5l3+ukHtOT092jJ2dkHtOTs92jJYPABLRl8zJY8gHl2nsTrhLVh KgUZQlUof62za3liUtLYIueT2jQq/aQFg4D+EjHYcms+42tPqoGyqtvHZbkQ alfU3b3Zc+FJ4144CIJ3A7Ja/Vy+JeNFeHt5Q9e9+fsSHJnrZIURZHLEBSK/ qE2GdO+sAqc+Zk+zV+iVHbY3mLohH0703YL0ayavBCUpMQpx7nmQt1XVIlih YH2hcLWQE/JBYZePj75JQFXsX1gvlfsv/c5+qaw0ofhwE6ewIn0F+tpsP5YS i6jHuQelnBBOc5kgbt37Afcc17KfVHOIqu6zZZLGizCqyeGIHFG4iNNkmdXk cEUOG11O8MAvclz0+q3owZzBj3H9RxacOfPN3R3tU3R3YIiLTIRBj2HBCuvu /KMxqkCoWapFLvYfMFbfbUqYqrIEv4b56HhvT/7L40RU9/6hYhY7pE04KBVc iWN54VqL9WiyyOTVIJJavMGZ8GqTMp9L71pYEq+tjTUR6JOqRML05+Kkbd27 Jx1Vh2RdoQqMGZQ77qohg3pJKrQcMc60bkeymX317gyVcYEWxjWv62sCFE4k mi/ZBeiBG48EKxQuvdCGHdUVbnPQd+cOn2DjtVstMART0UWZruBrRdg8CdYL 3AetfEGK/MwbLo3cqR2wlNd5pDgqsk80Rd3Mtjn+Dstk9YcauCJpr1jezCds BXOM7wLfcwnEV8iWzoPWu2v5nIq8WL3U9JVIWfoommzvKE28Fzx+Kuy4t9mV /MZMSDqxtMAtMo/4dQz7nKlmHaq7adk70M2G9l/iDJHr/j4u02qVT91EIFWK 2OoLzaPOoUDzvM22m9Vbdc5Qq3fk9CQK5T1WOxeLPC9s/yVph1J9Sp180Fxj Esbx+kJ4Wi0pI6lS0oJGmcY/1Y91uats45vD0lA8ZGGuLiYwbeGhBCxqPV8q osI4+k3KaEkDQjQUCwsqX0EFHfY/rA31yLHdYUesbTtW/lxaS+TqX+78FPq8 9d2bGwzOIVVzW8ZvQ1NX6OZOLrgVeoIrmgtT8qxJIwiPVIqdqBhZkol8vNl+ TuVvJGAUE3G3osO3QrgYzdTClrgwivK2Wfr7DiU1HWOEiF2hua15rPXjTuLI rwtpohJyXtiZPzDViERDeY3bOrF4EN8LVQYBZRdfE6EgixIxeUIVCxugmD/Z 8JTkTw48pfmTC0/3NJiQl/IYA7d+cuUAik9x+QL3bswWvDyBHZSxkKc6pzbs 7Kz7NPDjmAfQzTjoCiUgY17onto1tR0skYVJsAhATqmEo0sI6qLQPbV9artY wuGOFVjpQpRwdYm8STGWcKkExxKJvUiTLMtECd6Eg2scSy9IrGW8FCW8Jhye xgGgg8R3YlHCb8Lhaxxx6Frct11RImjCEWgcy5T7kWfZokTYhCPUOPwotKIw lf0RNeGINI5wwfkyUMhtqwmIbWkkS/jPWyxku2y7CYptayxh5CVpsJB9YjtN YGyngGYRYfgOR5ZxG8XL1XiWaRQGdiS5bPNGPLzQM34QcTdUbfMa8XgaD48W 3AodxQMSgOLokQBPTysAkYYjpM63M8fzFb5AFzHxkRA5BC+xuLVwuSWLhLpI CZ6oRgwg38u82FNNjXQZEx71sEPosmjhJ0EspduxmsB4GkzqO0vb8lJZxG4C IwRJoHE4t7kn+8pxGsF4GkwaxnbmhxKM4zaB4QUwQeouF4kcFA5vAhNpMI6d 2UmaKS3lNYLhha5x3cAKUlXGb0LjajBLnnpWGgaySNAEJtRguOfFNs8Um8NG MXM1mjjK3CyyPFkmakLjaDDLJFvG7lLyzLWawAQajB/4S8tJI1nEbgIjRrhA E6ZOzJNQypnrlEeR7N6zs1rBc22pjWI34nIUuYUiJjpioiuUXhDYy1yIXK6L 1I0iV8BLo9TPlZHr6TIleCQSrlTgmeeGViLL+E1obI0m5ossizmXRYImNFyj 4Ys0S5axYnzYhCbQYJb+YsEXvlQjbtQIxtJgFtkCRlEgy3CrEYyr0ThhtAiy RI4JbjehsTSaLI5tJ1hKkeBOExpXo0l5tnStUMo3d5vQ+BoMD0M7VSOC8yYs kYYC3c9Ty5Vc5l4TFCHeEoufLqIoU9X4jXLmaTD2MnaCRI08HjSBcTSYhMeJ 5/uqmrA8iiS8waB2JcfFKOJO5DhK7niki5jwSIi4kDvXiZfLSGovz9JF6qZa LqbaBYxUN1ZlbF3GREcM4WIQJZEb54z3nCYwgvECje95Cy9K5MziuU1oXI0m XFpJkkRyfHu8EY2l0cBWfLnkgVTGnteExtZoQi/kXppK1eP5TWjCAphlHAYZ V4vToAmMkCKBZpk5SeZncrB6YRMav9A1LsZFtaUEeFEjGFej4ZkV2nYs0fhW ExpeELTAc4MslHz27UY0tkazSN146bhSwH2nCY2j0ThxGqTOQu4afLcJTaTB ZIvQT91IgeFyGOUnyA+/ZvGT/IU4bFvoFw69SPQLl16k/5a9672xa73X21Wx ed7JcyR99LffMHEFwMyL7s5j1t3tbvFcD7+yEuYLMbu6Xe9XN2typ8SrO1m1 RS/do3zYLYq8HBenwjVnwBRboe6I9wdiXX52Bwz4gc7S4NdXVIqtHj7Elw/p m73iyaNowIsfXhpHK8QAeW75YvWSzlKWy/xwURViD5ldW1CX/OYbFnbeUd55 f3nbfxcB9/0EHF4i8IuUCbG5z2WiRMSQDSEvv0km1BFCo0zIfn//jdpHlgnJ 1RVx1DgcB/kQN92ltyQAdBcOnfyz7Jy6XI7IhV1ZT8YVGRyeD9jRZk+W6BQA lx0gkvVmcyMcXqHmuE7jbcqkXchqWTx7L7i6UgdMyoCkuRukDmFGP6iXv7YD StzHQ3PN9iq7lbj+evCo/yrga7CTnlTYpU38e7AbnnT+fbjbuV8YUVtHSpwY dbLC/zYTdGH//foPtP+2uOf4VfvvT/Hff3f//yQJ//Hu/9npcPy0O3x8Juyw L/onwpGPClUvLA3y3GRyh843poXg5qiUcJK9Ji8HWHBzvSZlLqNu36zWGFBb uH2k6VaZn2GkQDIlxcv+/QaqRsfd0k61EAhcmOYWak+zZQwTNtZrYU2rPXsd iwDp8RrjMNGt4iJDX1rCQbZQuj3dHvQyqMzEpN2+riA37CnUaRVM7HNdK7IB v9ir7Drboj/MzYp8oZI3CyBe8X4uFKckIEz1cCZ1CrT2dxu6ymcUsrqOCLB/ u89drTuaDC+QWW5utyadj+7V3cimuaVNNVe7vEfSDG/byG77mr3e3BWZXcgW LzY/ibv4AdRG9iA6I/lGvS5WIL6K2uWfoB8ysh25W6GdO9mYqBzxtRpl0i2f 4E+TFBD5NubtUAnJh8Y87U6RBTCD0yh7Td9/MPRArKyge497nz5n+PQ5w6fP Gf5zP2eQV+XKyKOoksUHtQ/Ubrx0y032GeICvd192jvuKFMOkU+YOzgyn2l4 Qc6sb9cb5vzd56y93i0YBVbMSZTuzoWtDF6eF4zRhAUOFfjlgbQegclC2dKT PaNhSJ9bmOCpi8omDR5K3wHkWT/gSwBFSVjEGDWaXzTYeEhnNOLPtP5X3o7/ qPW/7det/wPrU/yv33v9ryShZgsQqa8vYc2Onx4dOfyIh+aavZuietRfDOBy AUMdkGERfiAKU3J2VRfDIDSow+4CKvB4iTpQSMXECBMMRolhFye9HbTFC2mW hD+iKumgQBq/Sj2y7CPPq2u4XBMpV0qj7pQNjrX/gCppvy4eRVRHOlbEcSkj Y0BAFTBpLFf3+FWFwBVrLsklDC1XyBM9uscnbmYxzHjweru5fVUMaapiBVfb 6ZW/nOXWkfU7RKbgep+Hn6s5R1ZwZFnlfV4C68GdCESxucMguzKYsbJogyY5 nvUYp00Qozv8sdtcZcrDpm4SkiOuZfdJlollIPH4kVqVS9ddS5CwsCmAxx8Q SOM/aXv9KTDHp8AcnwJz/LeG11MLABFeL2K2DfPxlxFn5Q+kRRy+gwf5SUL3 cnY2f9bvzcYX82F/1GoVvjimtEl3Oq1PEe6BRZrDLbIkj+9XV7dXyAtH2Aa8 03W6IldIHRy3WtyJhvlxRmnvw27u5jEosvnrdJvvg27ntBVIZPz4/MUqVY/i CEvMTEaWn2AS2GxflNjw0siDMzTum2hfQznP0MWwyQ14JVjRKnzf3TvrToSz HEw7nZ0RF/UxzndzKnt5PJlPxhczTOWekdzrzcxks3jBTzPUbFWSpKNlSLOr aeQqGRtcSUJ3x5DgCjEj59hiTlHHC+LkFqULBpYs3ZJw+qPZoNfFOAbzi/5f L/vTma68Jk+3922hCbVE/gId03KNLL3e+BKygPypOlq8McN0Mh5NAZDXkGM6 684up62WX2QECv5344tjXUFQm0ztb4UNRanpraih4vP+dNo9hZbZVqnXIWEO 0jNEscF0u9oV3ZJrctEbRndcTvsX81H3vF8UgFahha0S60lgdaLB895wAL1C I9TktUxAEaVUr9IE+P/ZoNcn4SqwGdNPLqB5x3PapffGwwKXC6koqMCRApsL iaP+7Lw7/bbEZZl4Mb6c0eDQHC6kngyGs75QOrZdk34+u0TOOTVJvfH5BNsE Ego5DEYNx6eD0fxsjDLTsnk1SbIDEr1q4qynR3tRKMbD42K32aY0Iu9zaWrZ hjgeD7rDpyCm89EY06L6NJISx5DD/vPJ4IIGIcqJoUEK7MUKHacmcTB5Dn0D iW4xEQcbFeHFt71hF/u35RjqrzRlQLLBkqng/3w2OO9DQyDZYMrgeNjXaS3H YAr0+/lgpFSQwOgYrOnh6Dum9mImFBLXKmdQ6iPPYXAJ9qLwFnXZyQC1sGuw CWT++fc5P1yDS0IWht2ZFhaX12cYjY8x1atPPYUumkCyX9NB3clk2J91h9/O Ace3LTd4Zx7oS5A9yBaaTKhk/Nt41G+5UWUeE2pWKgFuVdKP+8Pu99RhkGxX kgejyeVsPu7N+rMpLhIqGaCbjRxutQVSYGiVwSvJ+cQDqV5jYdlAv6GBExhN ov6gqYU6S1jJouSyD5y9xEmLVxl5fjmcDYpgvCozsUfnNNGAQjaYSTq+MLf4 VllkSZtIXW1X1MxwcD7A8eQ79RInlJfvFtaochnCZhfd0XRIo2WaH3YLk6Yp JtN1HJNBg6uqETOVZzIpfTLJ0NS5biuWdmtzGFQMwYAuewpcVGmmWBxDVw1g +QWInvVlDr/CzQuYKmYyNSgv/uRCR5WuV9zVjJFmnWg7UzPoVMVzLrFwMgE1 UGLedDigl+ZYuujSS7dShZxMVQSyShUjHPjFdSi+fHox7h73umIyNPoUOCcW zLXZ8/RqOwpzb1FmKu151h3N/9LtjZ9O+2JeRbSGQMMUNT/rd49hEVCc0B1d JckOk0p4Wqli1h/SHGdivqBSZcDYgt6w360IKo4YWMLMSITNaaCLtEEi8/aY i2M27D/rD0vQ832F7A+rkiBWkOVdASUNxzCtUQPzKoXe1pwuVSXVOvy6mJVJ 5mnjSVnMZFJ3CENHSVsLD2+RG7KyUk2kfrrT70e9MipKkQlVjTWYHo9kqlOf SETnz+a2Y5kdUJPFtkwNQVmeDS5ml8Q4T1qKCqORY3m6y07wVH2ELu4NVHng N+j6gy+zfYLXOunioJhBTI4ix+1u+2WcXmGuOEn2BzWUVAi51oH2OXtQzibW 7CACB8l6lV3vd5UcqGYwnU6pK6lnsByFxNebdVqfAUYApK83r/CUuZJ63h/B yvoAj80PkF14/piJnbb2Giw4Vdr/5x7B891/HljwhevIjXvJEPEDg/qJjJVA L08Y7ap0gLVyS9gXylfuL9p5+ZP6llOrzKYr1726+e9HVCFZaQPp6GojKPP8 Jl69l38F7/sfgYfiSnpdgCRCzO639OpF6YTppQFbgyjCFucsk+6ghvd0ZLTN /lG6OheRpcxDotv0Zo5Hkw0nSfUnTfIYyfbNk6NdlmyzvX6tm8i+gNbApn2v uZu8Xq3T+Q1URRf0E+GSBu+yNkuRaN7nkw+RfXx1Y/BGIZWcQUoj9NcQJ2SD ImtVt/RiNuj/tXCaddx/ennaWi3bOkBuRwQL0Xmm/d54dAxLG5g3j7vfw7LF 55ZWyOfd5+rURKyWC/smnABHlxOx2C+upwqFprhdt4zQbagwYD8KC4KpWDwa h4eUCgsgjIQJv/sng+eMHUDKI0x5NJj1zw+k9AlHM1WK4ijrz3P/o+7/04/o A/qd9/+253GX7v9tP3Bd18d0m1se/3T//yfz/5xLEvmAtiN57ex+6YQoh/DP sT7MCXSRUtkUwc5tEUzCNffur/eb6zW72+Jt2RbN4uhrS7xxkfF68FYGr5Ho EgbaMYfFUHazb3fovplttqtXaPyDFIcrAuWT0mavRaQzWJDB1MYGUDi7Ehf0 r9EdzXKzfbXZ7zOkjJeBd2jwOZB3/2l+U01XV+i5hGq72W4W6+yKLbIEr+eg 0fEW20eFyWRPHNjuxCLnDp1AbX6S5NB6YL3a79ePkJ3xNbtZx3sy9ruji/MV 2SuDBlm/QduurbQxTLbxTlgRjLK9WD3Rlez4NfsuW68/q1EvoWa/5SH7OWgs 12Q/WnZSDxzDvlZd0mGC85idgzAJQwdYmt1srjGie4JL29V1/uVdTbVBxQLF O7K891ug4PVZwfhEsPq4f9K9HM5k9CwpAMKOAgshLWRvEgvbXWFpCDTQKnO1 W66AoW1ISTKdROSFfQIZcpLZC9qSid4uku/UwPM/2E6F5E9cVOeGKrmx51aZ uIrOVtBA8NZ4a1XHWE/XbLlkpsGP7FLNvdzMIdtugaFCpshcWVhp3ElL9kWG /NrdLvbbmPJLA4k1xShDUjdx8iNGcibbdpxaxeLvkVr8FSw6qLNW+M2bMPuJ UyD1kzBAlBfcN/FuT+1AH0jillnWQJe+ZOAufO3tbm63q83tjrWFSe0tcOQN 5d/HKxrhclbdaRvZNVIX5Do0LGabzY8w0O5gv4K2KNmPslpZJYKW9/C06tlh szEYCN3o4tcGn31WN6T4n8SSyHZ1Q52IWS7Kildq6GXBLIiBftpuV/itIzbo MZrDq4ro6weVj6QhJtWGV/247EZawNrJZCIN5vOCK/JgmwhLzQ3mkGYCArUS fbSeRUvktAZIMZoAzCHhEfeOcAz+1jWX/QHRCT6GjZVt/SojK2lbi58pSzG3 YQolEyuf5CZJNlcbMpxdx9tX2VYaY+HgvkNSZKUl1rVkR5LdSasqaKuyHqi2 MvqjTKvCQsUOdrPlH/ESd05W9zSwYLwW9BoyHjZfWfKjMsHfwnboBlQGqXit 65bbTEzB0Euwyli/edxkhJg3IzjynCPXLzdju9vTpz7rDOGJAYxPuVEL6MPz +AcQlgR5dXuDEiIMMv6/vW9ta+PIEp6v4le0NYmNiLj6kgSCswRwzMYGFuw4 eROvHiE10BshadUSmJn4v791blWnqqslYSMn2eCZJ0DXverUqXM/TbBVZpSI INMxiAoqIO3A2KB13oO7BdcOvYwuzEO8VGbWqCb76OH62lcffDUe+92Zs19d X1354O4eFbpbWV/9+oO7e+h3h5j34eoHd7fmd2d4r6/WAdf8MZ5yd4Z8d4Z8 d4Z8fxtDPrNx3QdDRP0IodaU3RwzncFgJK90O1m8TMi5/zfYfq6y1FJe/CR6 bLXyrP0LZJuoOhNBw5lXkCeb6qbCNlY3nP1g5Zv8Ol9G06+l86fB57wHpHTx O4gpi1+BLvK/dlNIyjJczrrwXVcftrNeoW77xP902uoOO/6n/lXb/1CcSgsW 438adQ2cBg3BaagZ9G7o426vuLCrZjbkBZwm98TXdf/g+PnWzsGbmq593mz3 rrAHkkwaSLgnFT27zUpVSLTq3ByeLvBTDfbCerTyNciXWeDcbce+L0j65o05 EDXDWZ226XdQI8nvTuTL9frNq676G+qihJp7pWk12tlAfcFK+Ink1OYWZBTt uJGnrV63nUsJ04buc/rOwF4XpeG4vTYfi8ipkwV0S2tY4Tk5e5nzaZwa7qeD +Zjtp3NDk3ofmP5yH810G4YVzZklg+9zEEDaMJuDs1YdfMYvdUZi89HL/rgA FSisBe5XE6Nc0B/m6o86Q4pahKJ52HXQN0C1XguyQ8aKBvjIR8oaZloLBunr IhD8mKEW8kvUAlhDV1FguH0DvYDZNf+jcObzGOeGtFFmQTQ11PjIL33SgKCe wqBQ+P203QB3fPCAP23nUgoHNsopJDrDXLKZ4D5RaHXYw8VFrODATSJ8O4Az XzCbgAIoSFPhtKFcyPBHZaxKNZ1DX3hpk/njve+fvz6sC0TgUlWZgcS6A6Cw 9L9e740r3nvxYkzpq6Otw3GND8Z1/exwd1zXu0cvxxRvP3+xU9cgTyGIJdGx OQKJ6qRSixI0QybSB4sPJFHoCKnceUoSKqmLEUbgWOepyRfJqg21JOfrqsK5 85+5eRpb5zgDyDwKY8xVUIj4oPlgHcbDFNymC8mS62WtV5Ox+eZ9AOELWXHz qLhJmF9PDLj+tmEHbX/4oA7wbjhm/mAdFXzHBvV1Ukk9AbRuyinsvVuwEuvj kubNr79MLqj0jip5t2zVr8ixLdaDk7Y1ODHse460tifpQYjXdvYFLnUBqqQz TF1SA1Ba8cOHpe+gZHHVBtYqdLzd655mZyN6MZIfSd5vu29h6Q0HMNjRLP0s HQK+PLlGnDTPb2q1nlRH7X4V62OCXai8iYl2PRRbC0c6Ja0o1Gyb18r083m+ nuz3yKGfJWKiElk2Y/zardYFqCxytPemMPGE0DhGKyO8XoOVLD7NWT8NK8OH HEKRI/WVzG89a+zt7xq8cnyw/UNj5/ujLYMmVtziqP434Vrm4TWsAR0OUuL5 KrwW3Ge1fIaIczBMfuypqiX31UNnI+9JLCfTsp48+HXlgYu+x9VrjM26ZqmZ uQfNi6xzbUbhtXmFMNpSjj9Mjb19sBRvbO3/7FXibezYbaOn2Xw6wXzhtCt1 O18Vxd40r9nd42bT7R50PX7v2KA/Oein3WSrJeLx5JgoaRu4ELz6yyAYjYA0 CCeToVjmPSUAf54vf54j7HqAa6qXjA9rdUtN3tMqBJhBt5cn891h79z8wK81 +4AQMTo9PHP9ySfSYuj8W8Az7cotwjPs3vTwbP7tZLnB1F1w9kZpdZ7mJONS SW70u1RA431UYRtG+DcmTgWwoQAnTORJHIa3IV4U8NTQAaHdio9zK94SbP5z GeGpG4GqrdTCx7B0rcPhtV0nBraDg3m4tpEMIZ3PQ/NzcbGY130Ibxmj5/v3 E/yTzlEm0uqAVGt+6M3E4zJfNl7v7/1UC1GLYUtBnwR0O6i/mpBlAzZL5/TK zRx7UHm+utxOL5e5srnaB403Rwf7L35Ofje/7h9sv3r1swUgbGgmuuavpz3q r1Fh3RTJ6fH84bOFGmsRJhPeO02uUoyDgy7loHMBYkioJJDtXIHWqdMhbXjS JNMoam2qQzwkswzYeIVSmV8EzaQZodsbum6opWpmKJuLpDca5Gnn1E/L5Ogy f73CFsch1pbOFmztMAp2ecsZjoguFQy7uKo6wOhSXhsCRWpjqQzV5v1ccA2O 0lYKFmaoxpD9tts3Ca8K1yt3ZmMjYFCe7TT+3+7RQTJ/nxlOb495hk833dpN g+PdV+pxd+0K+1bS1OJRr6mwMsjowlOVYlCLeYhMLjXryf5rYA3df/3pclvY URkUvqPQAz7vGq70iBmRFmeyo6Nwko7VlQIMqG0AJGLWsXcc3wQZFSUWsAj7 ZNFJ0MHbdwWkBIjcbE/23VOiKIBXom/nMdeSdKqq1MI6K3V3/PRiUY6kivdE PS2yZSzQgMmJFAO6NqVAWnTQzqPwptLwXCdXdZAMkUK9JN4D4f4SGg3sX+Ch pTnUE31bmEWEKxW8snAm0SO2i7IbvuK6KgFW/4ALoPrBByw93R2wPmCNQmdz wBxj+rb+kX6h8oyD1q3LJvL3Q9JlrFu0/XrnMCFXAIu868nJCKyOm108i95A 0oJyBein4sz1SVXUHA6bhnuw1hCLZGYAxtoYDs5GS6PWIEYQm2Tzeottgu2U 9SS39W95bs5JP+csXJ33IHajWH7XEwENMpLyom5DVQlvHLUYF9vvBepEhUaW 8AMYBJkr9YcDK5J9vnNEclorfe0N0fxL/vZM8uUDl1vHA9PFkDpVn6yvAhg1 KWkvWYlQFrSiUT6HEu83YNHEc2JTbcZO8ng43rAEEk0XvnG9iFxaUROHg3QR DFZazWFqQUKgxPcRYQJDMoQ6nDHvhqglF9gbYAPCV1JWq9XMTRWuR7fAJ3sK cQ/aLl30BtdArk0h1JkjvGYniGdeSxysyJmbGozCoP7iUwZFyjEHJvrE/wP8 wiWmvUEMDoeVfN55h+Y4m58bVJ618Qd1YX5lQdT8qAFxVGsJgT+NQzY89Htm Gsl8at4JPQPK2YYXTTttR+nxEZjWfeZi5crYErkwpkzfHdcSaE2ZgleCNpSb aqrMimOgdluLvDFkFfJXEOPDX9DuOzR8jOMtuzZzW+3oAIcwOhtSLm56cUBQ QWKvBhy3vgYEX5hp0lySslInsOcxnjouWTgPGwNiE3EJqVikhMDI/45UBJd9 A4wbkQk8grxLiuZ8H3RoFrq2MTfJC0h2lv0yDWOXk1bdPCZgPcdRwPKC9dy3 c86XM9oRJeZA24dTbYiXRwzx5vFCWAtpyL07ArWD6s/ve0X++Ip/gm0h/lt7 xL88XPObfLHI/8b94jf5HfqDjn9PXtC+G956cNbsygOLVg4fO8jeTjL/aO1r 5Kdgn8wg8MMaLN7KICoKCf37nQLE0iLpy0eMYoFAwJaBfTMSHcKCMsSGfvXC /JeoTEEP9/FbHS6xE4hRXgmi62AMJi2xKrwNfmyikJoDfPDFZtCZJSTVjSmp 4XBHSQUD+xW9e9+nQ7YMKYF5slbqEfWAJj9e+7AdPqaGOG/aaqSBSpIJ+8ah VitFNOTt4MYn2imkop0ZRQQrMZUgsITAZGbrE0Z2HUgXJPOKghKSgGBMXmCm ntvJqPtbt3fVVTtBz6z74AkPLO8gK3+6GQbVCofSPZuz7SGc1+EP0zYcDCVH 3He90HM4EyWBmI8/VyEB5UqZhOJjirxj4Z2Zgo6aq0S0ZJUCReVYMUMOIqjC 5BefknYCVk+/U1Uq05BKNZjatTUwlr4UkserLQOXytLXuqLU27axXT3LckAx 68ftWg/vGw0lnrB87/gs1YXyav3C5ZAXBXQQthoJ2fFQYcN7lPo9G7iO4NQ1 pbJZcogAI5WAqCFyvlJ5b08HoYmrAm1j96xQlSkf/k7frF66sFccQWQ9VoRx zGIlEMassL33O3pfY++A216q6pAa/V37v7C7WvOPWgxGM/D754Zyes0I7RVc h8/bNYtf/PuFMG5HAJt6AuBaOCpfVkdP8ougWFgfzwtm/ALITdGIWxJfuMHN xGdAKd+C5QUkOdRspSooLCoKVkiG5NxGzDMhopV1rl1JSoPmJYuhofdAcXnY uFJpisymmw4hTD/IqcCYJLcegW6UQsg8GKGgIvnA3sNoeabv10oRoNyemuD7 lUOSkNuX7ZSI7sAzEfRoNoBKwSRO7Pu4KsloLDbX3KfHgAm2iZ/gupbMK9UR vbZgekhfybc/MuG4ggYaNh1kpBNayq335luABZkrdu6AItp1eb8hFOhetZnl dL1aFOUVCSqQm75Cd3zWt1yfVXjVj6Eo5xgNVlMJMN9PB5CJ0oJ80vSuNF0f INkHDluwtzDHZRFfSsk+QulGqCHa9uXkeUXuRzwHJ8GFvs1dBRfTXLwcUhCb QXv0bexco4OjmKHxRNiHIAVZrtzh+fao30GQo+YyCqprT7POEHz2IEfbTC72 pMty09vtarZGg4JlLLyf/JGzZ4wGYD7ujHtx7Q28KVZWepGf/bL2mKJ9lAlP /VAfAOncNRCWnOYQ/5wnMxdvJLGTpSnb10/FEuGJhxJQkTexQInb39ucJPVE LT9WNuhPZk2Ky+T+fRQVcakNR2JebC/IR/LNpixRcB8kUGagso5zdXPfEYSz ITOhaIwhy4nONOAs9F4km3ZmFCJGEXZEpkgxNwipGCp2X8u23FcIhQICmr6l 02Y0JW+YoubQcpvSv4hmNwvSWjpT1TtJY3XFtjpFRE0g1UssbrDoYjH5H8iR 0x70+u5Mc+H+zFUxrN+OKeyj75A0XychtiFBF5O9nfVEpNUwK+8yBTOv1b0p bpAk6KxhWEwczDGBtJchJUnlXpmoSN07E3uO9b7qOxAGwVHXQO1y8W7dY6MA D45kq2VvIWxFbqNWnI/MDi4mv4FQ3u40OSnYG1scyYKRdyaO967+YPqDsxl1 OeAD6An5kTNd6pPxBlNSm8IBxNfMliVUjMuYt4X1hAz4PYbfYTlB3hV1HQq3 zMOhaJXt2zU7MNaaJmv346Pgp16oIh9dloG3fUJBcHPR7F7XyuCcN/NGoB7d 7BC3RABe4xYH86KodmCvt2qr3SZBfqC1BQOqQAEk0pLYO+Ro6gAIVJG7TZvu +Z2b5l3w9HbBq+DRBQAGeJc928MAaQctaB/Q0AtyHqrIXHotyhAMMYQtKlhb BjDzDBqeNjMInnHaG3h82YzB5X1hskXDTHVbKECJqVoHrMNJOs96SRMUgx5V a8X40/EuWtIXwt9RegameuQgue32PgpQCtcVGAbMdew7hTk/LnZiQjvUhvV+ KpKMRXM1bb4KvoDw2/w8dlMzZ7cKJjDYez15s3/wfGv/e7vgCf47gQ0s2avR okgfZ7NYzjezd6LkImwqePSHPbREk9BNfpebm9aS0VoPaXMz7wUsp0Dh3zRk ZvH59OCOZuG9ghMejuIrHKOoo2KpMa/HJ7POURxyyGBui+iEAr0IN3nrbBbe icnM+k1ZLS3xBBQVsxbBkB0NCHwTlpgnGaYTa9TrtMuKzClCUfjZhQeJlmCk EMu99a8abUyjKREcIzYzVNGMdDI6/cXLmPJWuL3M+kZiOEiWdk7JMBLWE70f TBKLEOfJXiabBcGo4vVsrXslwueQ35MGnrYENa42n4TcXt9NzJuR60VCdLoH xlWbYkoBeSrU6aEFUU1K7fdI7oibBHJX8Lqf/qn8aGJK3ELspVlxOgZndTQN 6RVxrHgBTv82mpJ5sjhKmAv8pIzVEZ5P0R/EHYXTKt13N0H+QOCP+dTd6AT2 umYEg5rhGMB56CZ0SnGi4w8E3d0H6f+g/bXdcmu5StbXBcLijz7GH2F/xLQN j3IRC6j0TUpMHURC6UIIRCK3Ie4H6e2bEFTpGiN8GHxy3R9SZA9o2+sQ3QVc jDwSEjoPc8o2O5Aj10bgaOYpe070CJKgAyuep3ZkPoVJsjMMy9UdcklP3C6s dNNUSrs4J1CJ2xB87pueGLWFkBnDnEfhjnWtkj6p8cAs1sAdl8OqZLZdz7KU LNWWnLHgsrP4gnqoy9KGqhKBI7qhQuzLgzUe/ap60yJg16SIgkXELhhYvY5I 8LpXNCL+GdOvTi8jfavntaxvbxd0/xrp04b/CGLoaxJCn/SG5+pY3dZSnkjG 2w6ZeauM7mLyu9gZebOeYsch3zIEn8Hc8KkLRuid9o3RoHR5yP38ZVGhq+Je jLJCekFmjEQtMYSEOsSmEFRh4z/Kg8g3lUhBsDb1qD/HpGDx1LeT6k++miFx 5OZhuyiSRnY6JaBr4Nw1F9DAyvqoyyF8BLGDzDuAoZlCYP9IWH+BHd9B/C1C vPiLDVqGnZ0vHHw9qYLLZ7UWl9RsN8GbkBk5h9EQBUOM4gdDiVVJAW7HnX/J 2bNzqYUgHgxCl3HMyTs4uDXMt+MIPo9UYx9LYS/B3YuMZ4oQU9MW88TK1pMI XNnOIg2SL1xxXVMguoOiub3ppv24ATRoMm9Z63oikwga6EG8OTCzXdcPfWFg YcKxJYroMtSdJlnyjV/DfPrii0B6x+x89jb5700lBcjeBseRYTDxayJYKLIq Rz91R/Ptt98qD+LhoIs32S4isvX+Aj6eH5Mp3SHmmV5Ij2vBE7/Va1bwbpn9 BRt3sz/JBXvd9/jkPER4cJtgxpGNtYsIZ+vUWKTtc+HpEhwscxEIzuAQAkYA 3bQLEe2QeGRRc3hZ02FDjTGv5S7FjmqlG+DTtFbCM6IaURmPHmqChOeDruwU eGjUlTgOPFFHrBuYCfDQ9IimXHmHK+lfNVu/leuWoOEEdFOKakrRzPQopohe BLXMXseglW+hlkEyDpHmDh+0njj/Fs1QZ2LjNUk3+Gk1D5hLKVYwrRbBDwM5 WacgqgCrNYgrCUZFtQGOaz5PsjwzkMbhHZX/8fhES2l3dOFdMaxytHv44ufG wSEYvNaLBbsvD1/9HPn+fPfFYaz6T3uvIp9/3D2CWdCllSU8G5gltQ2wDnut XoftyNK2mMZBlZdmzkecpER/39863ts5Tp0dHXzchkwv3QOUH7qNOYIzlGzn m9ZugQqh/+OhgdFjeqg3VbIpm1m16upzNkBodkhJDkyL/d1X5Jb4NHFVXZVo CjQ3PIvZjzH4CFxL06OI3nP5+Gv310HVb/c87YBetLp12cw6iJtbvYsLc+Xz dahtEFy/T7/knQx/q5r21SQZpp1uOqSigUHHWaz33XfZ0G1a9fter31ynd7z a4JmQE6nfJXfURTbWLm+cD82O4d8qW36IxuJHZIgyR/rlILoM5jLZztoaRbL RvQZz9V3JismC3MCfc8xzyrorCzKosvkL6u0E9HUJLUdyKbmhfOMPOZktDDW +kW5PET1epBB8/+GOg/BxsrEU3G1gMd3m9U0RPiB4kZYN8NynmlgQnmkqc1v ikf2yzwi5N4yqpnaPXqe0ESHk1WBpblBDGVS7/IDOk4NEQ7h078bgNH4rHnM P8HZ6StfFD1/El1s+XHcaWHjJziG0mH17ELCyY4GKZmEuiTjkmJbcDrGsSEF YoudJxyuX0gk+5HpBWHkKsvPyS2knXFurW561htmcNObZv5A14AjBhI2/mSw hwcu7xJ7cJvuMIsSGeMFPdQ5dZSdDE0Dg/lBKFHd1E/gVLINkLJ5FzEUKGX/ d9TswGJApXBheOUWZxTCVV+RFlu6anYlLhw9+/J9CzKuZZxwAYfxEsypBFLO g0aeN+mDgwrlboXSfEmqbGM+IIPiYD2uHmYRbCbdXneRErtIw2/n5iT0qr3u nOcHe5IZB4cCSSMMvI76lDIieqLQK9MsopCy7AK//VJ8b7PkrecKxac+gFMb z66UYl7diBEEbn52pIAccDXG0DCFhUB4rPnSyRRpgw9Zq42YsLDgeSBiqqjg QJaS78GkPUMj5vPsAluS9fz0WzbNXPHiaItHUejYFu4xCHiLWjQmeRgX4g3Q mRyKgO+QZQIioR0C/mhVu4zEo66g6ZFYRUDmwj2XuTCKA5c0+vC66nXNKm34 TciGaA4gmv3QjBMNBFK6z6ZBY28HPDGf7e0exUDC3yhcyI46dvu6Oj4MAxQ8 rdaTwlmRManmKVc3ptzBbYip1F48pow0ixCqBTJu1kr20o+ko9Cyv5ecGZD7 QCiwqTSb0oPX10Vz2DoHDhYTai7B9gwNZA8lOaHBkC1rEoE5QeW9MNfD6wns eFSOQMhR5ucvg8yso9x1dJIaxtO8X+Ak5PfU7SGaxrY4r5sBwTbw3zt458AZ d29nMhzQcfBp7O1Q+ik3VcxW6GKpMGY5so9UzpSgd60wsDHmoCJpsqG2zYOk QI1jVvhdlQBZ9MLeDAeF1gl6N7Qawz604P6pbKT899utQ7QGE9ZRFMRXptMb +IjPkx3E1AfOoLsoZrCWuTpKht4HneUSiYMRBqwi4kDUKEjlp2y65NrafcOr iCZ8Z83BCUhCzIXMhhB/zdBcYM8/AIw36qtN5DcBGeciCIixf/lOrASBP96X rKwIoUSz1C3VJqDqmmKKTyR3Or1eOGmvw3uRaQZ29tOSGJYY3ysiFfuyCZVJ jnDddgefknbaT8mBedQHO8dT7skUQbZbd57STT05B6GY+jsQo9WT3kA6CUVs c47Li2zGTSme4M0wnRFqMf0ZQtksF4JyMKK9prVjSsgmOV8XEKXKhulkmLaA hPx+gZaGmqKCrHdDI5sCDBIQCooJZKjVKsJB+QgoNA4RGtJK54MQwTz49kHN EZa//w49W7LKr1qF4xUTmZK5iWh0wgxBfB2dYGRU8F+SUSdM8H9HrmrJBOmM xm/fT3uvwsmVDMiJY6zdUHRIJUmdMDLL6cPB/QYRYIq9Rc4utzm0nJUVr1ii JsBD8J0lLP5SJ8lWJtLV7QzzHybYedNRTDy1JUPYnUlow7bfGgQjDnvBLwX0 IXlEI0R6IOkBCAUVHe4HTqg36qItB5Cg+NMX9kiP/n6Ml/24VlEh0Fi33siN CpUUk/mM50zYUkLfK3xps7Zo5XFDIbNi0yWqHiCZSZvok5FtfLCS5lkz60ZJ SG/GlttmzzfZ/e84FrDhAj6HbEG6UV3pazhUPsjCbNZ2JbqSbgL2bmK0lwn3 CO58CMRxeVygnvEHHhfDALsDhqSvu3M3qV6U8E06ZcwZDRRQeCqfSChoZbL0 NAZHX6L79wKxq/dzfGsxEHB74UskJ+uZ2Hq+4DQiuYEsY2lREwuphhAjAGvp qOP89purmwRGwxuhV0PUXFr64hD0N3RvcICwwFK5cvubdk/b35A5zlL0Io9z bNj96XDvaMt/bZLnzdyX4MkgOBvyPKDYD5TozvAYUuINpgPCUaQAbPBN8WWx R6AcVtVBVK2GB6a2S2P9OjCYfMLtVKNSDH0OD2fx14ieD9v/G2BPaABgTD5v JzvN6xyHqvOCYT0Vb3ojNC1Q8eUm+H0ot1odSTgCBJ5YxEKwO0Tfk6d4/NZG o0QWqbyRXdUySFUuyWUQZTtR3yfwPNM79ajAILFxRMDxfOtQs/NjxsaML8EO +QflZZdwNcduUAjLk874mN3WkEeD44XzVj4/5xlkDBgoR7G6a4w5tXsXKXp1 a1skkNzA056TfALs4KnTtlXCOXAhTQNyTS3z9IDoSTmovTJgky6+aV4nsLeu 1Y2RTShk8Xb1hie5jGImVP8a/vaSNMWOPKRY5CSUsBiFYn1jTko3qhBwLuCL hEuFCJh6OUVST+L2ijn52MrWgHQ4mMpeVZqNMVqFhB2rEFEKdoogEoxrXj1P voCisfPSYZSTbUOjAYhhdie3i8Q7XJBNtq87D7qDHHWc26QwGctMMPL1L4hg zTIUvlwigCuGYhYRVGR6UfkaUkDTyNjk0SAztKhczeF+rlUuUpM4IWCRsA0R +2EO25Yo9ndfOFRZW9VSz447lemVENeScab6c2+UXDW7Q7NhHHGSq173Rt9+ C2/cwW/mku+hjK4q2WCqq1Wfep0YKKoyPRlaiUWVqjgqUO2r5+kTAejQ2Ue2 BenRbvYOozbELQxy1iUJmDL8RWmTInESUIkVgWY/Mu0U8w+nEb0t44d+H41u JkwbR+zUo98wCvPkRUQu33T3/zbiGxefII5RfM973JkuvdmEwpDAMZK1RJw7 lRuwl/BpWht0gYWoEbey/h5rwhrLR6HkyiLisVG6OOySIZFrRa1x3etHWztg rF8QUZxnSlo1b9FQLUpPjBUPRwRkPHPQXcrEcVDSVeztoLF9nlqimnSqdSXQ x2WzHgOPnOsEMjWl2YyIyoSI0JrSgp2rH6W9TDaiu5hePsJBjPjmTxRSRAHJ hfeZKHv4GPv+m3sTfBqPAHXliuGr2QFAx1FAVVAzOdr9T0PGLbH5DmX8klC2 16yqYamaAazLrJ3OINZzHF34BzzeXYCeFjaaL48R66XlChJYJi5zZaEMk1sa FmOcST5+ZyoroI/fRqMG2bRgDckmVsglxqnGNspyTeHGScIpEiF9h3ne8qHh tZqDttXySoYnq+EK8jBtxmI+B6lRbaamJKwNMDQmCl/YshBj228v6aISL1Rp mB7Kzw010Z1O73QSJnhiR7J+35PyC+DbPQM65t5Y93zfY1dbVkJ7zA5CsjbK 2VSSJ6SYm6qi+EHY+oOjV+ZtPD7e+n7XL7Rh9isBD4e3yaadYF4QYasSbM4X uhc/uOZxyiArwf1ZpKOBS+c4cznC9QjWc883jragygbQpY7Qdv/twVMt3+/S XQ2zFD18PWxXcN20TKzwkN6I9WC7SlwvfRiVnqKenvwcjZvyij/JG6ThnTa/ OecS/eAE53DQnaIeKpbtnGGikETOT4l3zKr/I3oYzCwxUi08ZJASb/7zvMam 0ApL1F0qvGAmUHGSh4FAOZjF2nCoTkIPB2Q+zsvLUgAMSpPqn5ykThWlsffm 6KNSh1E401rtk9APlqK7CQlhvaRuREVQhlEMz5mStfGM6IoYlYrIEIf+YAqD /sY+PpzmgNv69yE7CmTA9rZ5whoWfjbu3v4/8duvdogubdY97SmLKfpY2CI0 m5JNwTo11G6N2zuqJrunF4/W14UCL7dQsHa+5fI6K0G4SlVUugd3xM8d8fOH Ej9O1H5H/8ye/sFgEzegfbrJ1vYP+wdvXuzuGPKHKB70VLGKn/NmTmad+Qj9 AE5HHdMZhdSYlSSlNGTGB+XV+RPJTGZLjlh5hjnTmZEi8QdCUyR/wAOhh//4 B0L3NrMHwp/y3/iBOHyTbJnb/td5HfyT06/Dn+klIP3DBz8FEU6YLAyd2YiO UYy88CeWtxc0LKxcuYnYXdsVWdfXDxTHjxr5OVyAkDf9wCdHsbT1ZAE0xw36 1fTMvwF71fBZXtFrN5g5oIRxHba5sb36YX/i+QBi4f8/7PUay0P7ovTZPV0R 1PMJ8c4UHPyLXrMN/toUubF7mp2N2BYVT88FAncYq8hrK9NYtgeeaAYbSxzs RywM1NWHvTzDeaFGF/K7Qzg8yb3Uo9BcuXCXfUPLmeeJjOg5WnriHNWwEKC7 Ln/wJjWZVzfXDpz7JTs8jHMCHHwv5mMk1wTMZOleMHPuPoLtlBTIBbIlaxse P7/ix6MK0rjPaatXs1+LT02lHzGr/bEktb9Xojh/FawMzta0Ti6xuYRUaDl0 iyEJeNW2l+apZB+CtjQ0aN1h79SX40Jv2vlzQW2auZDBIskgwyafZjJA7cbe Ts0T2Mie1hOb3TqW2NpuPVj0eeXxEXmHvRT2tz8oiE02k7VkoVAc0/eLpXyw Zbiv/w63NlyANlAVWyGuw2ZCposy6yCH5BXhzK19W0i2IZLaTzcjcrvQlsJ1 HdSFpFHaioL3Sz85sGp332ISPXdWwYT12xVK+mwv5dI+ZUFUYs5UZsokywiP vHQpJcCpLfBvCJkfulJtJ1XwwRafSp5eMQ3Cn0Zo/IfLh28g9+RNI4IJUW3r ThJ6JwktMLozFUT+SVhNa+pbzBIH/lSRYMnaTcIyCGBKTEymi/gA8SBvn3MM bJPr7KVR02wfFHh8INUhvo93mZ07FvpX7Y3i17N02L8y3Wgp4ULabfWv3J9k ZB9UII+TBmWLgzSK9ziP4vz+wfHzrZ2DNzWdXXH+ZQO2rlacQY4T+ydbMglo 9HURWiw6QuaejODSEkFUuWJiHHKAdn/ZXA2oRYMhNhO3AbCZNbQSL74dkgVz cVWHmva3AR3e2otP+1cNOYayjfENpv1W9aT6LpqZglR/dtZ5Pzpr8TVS8zWv R/wkkEgM15CHi/inNTIrrZ0bbHLV7uv4nzSK8Dvvxx/f0air01E1O2e9wfXw /IKaIziChTTBoWyTPxcny2U3Ti99AO4z9lNoN/GgCzlQZ4ilVFTKEE+JK2uu JWLot0ohMPe3jpcSJ8nOiYMFTMWvO7GjBslRFHEOxiLOXIUcmaYhZjqTJGc0 DIRtyy6BgPgtvb59pOdF5QxDctIRibSJSjdKpWZwos/2Xuwa/IUzP20rqRK9 +TYaNH+l997LUYnSkgs/bPTk9JMRQRWJt+iJdn+be9zgHPIubeWzjCldPtkg XyG/y+Kpap/jE+dyv4w+94NmOxvlZjvNx6Otnb3Xx43tF3u7+6+ObYLledkb zL3c92g929+gSghmnrYzmi5aZpMP2+mAJmGgGXIbQ7oc7PlzlLxgQAiGJS+8 Zn/QO6OHjgYu5NT2riRvmsofoCRKpxinsbgSoT94gHoiq69NYB1gqxaYToRo Lf+0wVo8J07lC5O3mt2Sw8GzIbgSEhPHXxvXpyxXAwz14XExUm8zFP7FoxjD f09bHYNfEgsJHoEs014pbJ5AayQ5o8JNe4cJjA5R2ShbY7KPjhet0QAPepgY bIOBklL2v8eoay2IXtEF+w/uK/cCw/Iq70VW6bnGsK+F7LV3S8NYx0HcEIl/ OLDzv8hydLTGmCFm6CA6LA9yGxGWHXdCvJLafAaXcXdjzvrAUoRS5P3QxWbI IlvB/BA7YFrGT/F7sq0F2I5VFt7MMlkfnptFngN7m+18v4i2LMyzwISWTHgy 5E99Rp+OcnCy8WKCCrRDNAe/JRI9lbVTOL52mmOghmfZLJgZLbkHHhJ+4/ec HhV6nQM9F+Wd+DffeuoDwq+Fb88IsH0VfVnriQqWTK9SAwSZDQj14IbeCNpi GAflJDdjXpTC7vjHtJPl/U6T4ifm1wb5vUNcaDjPARNpGcbMPRs0L2bAbaI0 bb6Gu118zV9DMWK+X5LFJiW8N3RF8hb+zunHO/rRTtonVIabKs86bi0E92Jk NdsdZrwa7jEFnUoTU9SL2EnzVaBS0wXqm8ETtJlAHAU4i4v+7e+99wgUtLqO jjV/0jWJkbAwwcYQf2CqEk0iTkMZvjj43lGFOJIjCW375gdSgtshIXhKGwyx aT6CCOTFmoni8SCWVTPAVcAEFtceLa09ygF+zeJbVPk+t66hUJZaMimEDT8x /iY9aiPrZgXOz6wmM/TVvwxPF9O2rnP9SiQxVrKYvAFXW0wjhSFiSLQnfF4d G1ZQe3nRG3XR9wP3B5IYte2VkKSxUMRNejaAK9a/KoQcx4ieFP+H7PUqrzhe OSkHJSguYnybq2Fx1y6CGgn3k+FGNQfX0K47ujgxyzCTbTev8yXZgavmoAtq mWD1zRYEgOyk7TO1BX5+Jl4UrGSQXjSzrgRcochzOrxrtzeEmCLQCbUys/Aj IWGPM2COHYgIpt7Z235FMTUMQ8wpirxvZtfg6aMYf0Sz4w1v073xy6uRQ5Ab r3uN3fsI7AXMWYnHYrQhTM/QhUilLNhujne3D/Z3jhuHu0eNna2fgxTAE5b0 hmBj2vWEoDTdYoqtbriST4dw/Ax7Ic45Tl16RhVrDC/IybXDJz1kkMxv8ExC Awc5ToevyM1ZWFhNkymwVqQu/ThtiYhkXJtiMjRTFsuF1h+kl0q2Ls/SsB98 /BdkSh/+q2+voQ40O4X9Sym3Z8OBQZjedxnx3mpTMB44C1NpCYU4dbCGJDoH JViRxtOmV+L604SXC7Mp8HzUjjOy4NnbrouxMmyl6dLYu6SWMEvNGnkBJ1y3 Ya8XkLLZMKjCALrSGiIbNMcvjwsWl511e8Bj9gbXIRVd8chou19mIXvmYSBC wYq/tRjE7RgSWFWN44P99Q7MP69CTTABoUporLCjvYZsJZdyneMdBZ1YM4UA ySb+OZcBqDpMNANVmsxOBlkVXKhMA1a2Lw+45C45FXkh0yn2cpYO4S73Tg3l AVRkv57cN3ea+ZtwPcP+0vASnoPkCw+zfEpM78IwhlgeYk3lJBxKdSKC3Peq 4NZCZh3hzNeTfY8IS05Sg4FSvV+mx6Y8iUD3cXQY1C5gtoKrzJDbK8TnktMG WiksruInSKk1GsxAGqHjUppf4DhrwRMA3zw16hRIXTVvEBEpmgD3xVBvQ4v+ Y6RPaUZcDS8WXscBI4zgwO9p4q10rL4LWoaUTHmq3pJxDPEd9CEIz+0G3UGu bfvYCCotb5bTTV5N2Fzq0u6/0oX69WqeEDy4jJe9rD2XG1r7tAlCaIPZhTFH vU525qRSKArpGxbhabgvvwH/Y8vryfHe9z/sGbSvji+O+hG9m+tjxunC6J+3 a94jAKJGZlhPO6P8XJorEctqsI7zUb90FS5ozv99+7+l5UGzDbhtqfWPWf1b WV1ZefLo0T9WVlZWv3y8Cj/Nb2v0Ez49Mb8/ebjy5dqTlUcrj8331Ucrj8zP f3yCfyOQJ5ohh78Nsvy82yyrZ6qdno5bJPx7tMKL+/Iff5F//8xOu2Aj3TE3 YA78lbOWS4CKRvzVz56jD8B6snzZHCznvdGglS63LvNBrzdcJsHZMkQoc5BU v0xWl9YgL+qT5dW15dWHyeqT9YcP11dWk0veZmCLks9sglTK1LGQfPaid4YZ pm1Hn8Fnm4kVuo32azuG6hgXPEWLfPBWgDw8A8iUByIWg4IYC8PzCyZf5qth 4Bab3TxLFvtpuwkyEHpi9cCrauBVSPT6+Mv1h1/6AzPBaTqmZtTLMq4OyinA PcoX3Z9oC5Zs+dmxd6CbvS55dB5TVj3qzTZ8kV3CKoam9i7Y8RvUmad53bRq LdlKT75eW0l+6JlVb6dQKTlsDn67al7bCodmr3KzZEhPsr1lPnz96PGTJ3qc 7V7/epCdnQ9h/WuThnUdp4OLLMfNo0hylA6pnlz0zIGbn0DYtLNcyGoU5+e9 0+EVuAoQ7+am2ScKjTIhZcNziN5/mmKMf/BOMAd4NjCrSNt1Jb0+xwxUkDeM e2nZpUA/fTdDEGG1TO/9PqTVQYubDtSGzIgYOXjUB1ABtl76avdaowvQyVJq F5QNgG7TUH/jtggD7bHZie3LvOnN9mVqBshZhtAfnXSyFiRCNbMcsvgNUz7y hsGsKaGW2yPShdj9sZ4IZnzo0i6X9p7XbOZyll1Cgkc3Gbdcf5m0pbCLKDfU B4jkraF51ZG57Z20J5BObDrANrzlb+ZMDDNoLi8mFhuyz0rzxKzZ9oFKo1E2 bJ5kHdjF3mkcwASwzBz2hokCFQtFVUhJllftrhqqCdXfpn120e9kporpEIBP zH9ABqMwad5q5Vn7l7fJ5lz1P+b/WbPYrbK69Hi62wVLr6L1XLfVGbXTyjf5 db4MtEa+dP40+AxWpOnQ/95NzWGmw+WsC991g2E76/l1R11zpu1C+/aJ/6l/ 1fb7qtJbsHReNR/Jti55ufXT4Zv9rZeVr7xPW8fHlcrqk7k5tjMyyPmSzY5/ ebTyNShwrAWSNUgOShaE+tuYQ+rNrBqUQVxKGvSIYzeX9zp4CEH0YbPFSGDP NwdnLXNLBmeXikCEjxu+zRXU+OUtE78wi6aKdEMhSuN+hOBr1fkIF0Mpgszv ZqiF/LKvHRnzyxaaM2+UuDvS7CXLuPpmGHzYl9XCxoQ11sprQLE5svIKF+3H UB4Ymy2YM6FjKzUHk88UotaajsmqcVPtuqcPNsSF0XBFmTNqA8tYND8mtYHA H7jxARisvLV8LEAKWzBpBkh0yo6xXA7yP2N/KFWxGeC591Xq3ZwzW7uakz+5 JmsavnmGI6qO2v2qZXaxsjLQF2ApcKxFtmu/BwKIc0noC5rCZTLwSWKjkWDK CuFkeQKGkBJ+2DsHEzQ+qxqsxDA8vtG97IWykuKkkb5yipaiIkrOK4gIjMJ4 uovURLQdcc69uA9WUYvaEzBgSrz+fu2O2QDYAURLwOkhVk7m2YvBcL8H2z80 dr4/2npZT1bckVH9b8KZzQPnWoM3FVTx81XqbsLYE9wzLA6azjsDq3+4c8be PjhtNbb2f8bTdncVElGurD2Gpu2e76Bk63zxhTVLiztyOLhyjRQgSirhE9SB 0SbX7R6Md8TAw6CUGmrS3yRPHhlOzx6cKjKMOpV5i2FVOo1tzy08V5jg+FMV EK1uQyAXDMNg7flNF4hG+KYKDgnvV4bvn5chIGIdxk9kPbF4r3pgWslo69Wa XfwC13WZ+3yFJqxiJVDRuLmAUHnCXORZ0pPZN82ik5HKtzAbdHkZP6c1Paej dBHF/2VzE8v7yMIK/dYiwc3t4esBcgjgDTgKzTEnYSTr4990y6SYQDaqhPX2 HxsvYGxUXozhG4QDQBWGIZTbvYsGPfQG/PHnGK+1D46tF3Oxt6agg2TfvrTa gfH18e5Rw9CrqLGxHReMP9XFss6SUPWpJXgLnpbUkxQ7zKQ9JMmXb01vBvpI ynD1xPozaldJJl8izpK2Q1q4Bpri2uX0NvR3j4bTfe12XaoRv8/ybRNgj2+b GWTMrplSt2nyYDGlidamYd4StYdSy102tY+FaEeQKWdnWjNgRnxx+1qic9XV 1rVldlSpaAg8rRUwedHySJNMgC2J7aIsmPX/JCH+5RwlUzXuhTaJniYLjD5C hiNIA8NMQfZWmasFEFsKbPrdKQLuwYudTwC8+uz+ANi1r/GfHHQthN0i3P4V oDTihd6JeaH/iX2mG5P9pYWh47WwK7TQ07NyhIahmgzF4cI3dF5KkCOhi2tx SkrEZNPT0mSkS1WjFlRZqevJ3sfJONtBHv5pUUEN3xvQL+gai9vPo3h7Xfdm yn0EBN2K4mxCBgJaEwFYZDhca0MJerMDxtbQGewE71xKGHK1LQBUtVIwkrtI u0A45gjFxBe1xINwWXnN2EhWtntUmTbGBHDkesqD8iPiPLq1yBSdTENffQcV tt49nzItIeiP0laaXaZtm9uZIoAwQkGgnk7iAEleKckfuZ5BLxo5CvLW+zcV xXFj8nzq16fgE+XH6bNPX1mMDHXEYyNCusORXH3+Jnj9hCsax42xKS0E6Yue Iu9/9BTfz6msKPGUKFvbP5QMbImXWIhXPUbENFeBHrF9O2k381u9D/xgbBPn /iK8ySTfljjf5yMMkf6KNB3adHtKEgtABR/N7WL/BrL6iL337ug2ArSMvcJr 0WQbcD90t4D0faroHid4CmxtXoiKPUQ2NKxDixfAjv659P9Ly2jeNkPrj0n2 Hw+fPAGzCd/+4+HjR1/e2X/8xew/GJLQ+uMxqDO/XF55uLzyGIwlHq2trz6a zvrDdRPafjxOor16JhirS2C/bDDwzv7esSiyoWBtKXlp1kHJ9CTQU045EjPz axciI16mRcOPRzLq2rIZbG1lfe3xuhneG5WGzNN+cwC8GAZWwVzqMBhmUF9K MHDgzu6zrdcvXrEBOrvykIUpNIK+rpowK5dVGPswZPZFlp9Ctm0gJVupK6IE 7VcQo7EJgV/ZmShDjb7ffa24uoeyulWzrcnql+sPv1p/9HVgT0PiQTCLpf0c H6EQ40eSV9WgB8OKP1KJHc+a2dW19ZUv11dWQnMa895jyA2mDHL0+cJndHXt K5jQ2uMn6JnVavUueuhw32kOzqAq2sKBpcAVdAUW6Vdk6SNeHGSRbKYqeus7 m587m587m587m58Z2Pzwm1YxKGXtE5n8YHVDJX+4IVC50Y/7UByhBXPkzjH8 7s53L/VA7ZMLKrXxr0wF3MCoJVH6zmxJNwlNfvgz8AUuDMKGX9s5dW/Y0wFp iXkK004baX1Dl3MB9ASnZF7wPA0LQPnfALkaapGBjRRrpmd7+zuNlwc7u6g1 qqxECo52D1/8XFmNlBz/sHdYWYsUPHvx+vh55eHcuHTEM/SPAbKiAWsO3WNs IKYupjK25IcQMvhBwjJB8C3zfA9TF3gL5JnmVsb8IHPKtA6ef4BjiG/GcAPY kgJom8vsxkQyQMeBWkpu2zHGboSEHKSc1DhfjoFLf5QFIdS+WQuqcaxYdadY 4HTIXsyS9A3IGvs3aDG/I+u4wN7fBeMqLZ9z4cEXIMjWIAc834U3yT1tQFyZ dxGopwERy5iq2jY7S7vpQPQPTO9xS3g3VErrDvtkLtnQRaJ1cKuoW+kBLdTw H65Q+V3yPgRifNtm2KP52nobc9pDQqxJ3sMb5KJCfOeiQixiYAR77Q6PDiDA g/m5+2zvp7qaE/ZMPiPkbT3v4wrpswxwbLgJGMcLkSMn/z5x/4Lg1QFKYKpz hlFa0sE0aAFJf4+1mS1KwPGK2OC2kYFd/h+CDMQhywev8ROxwAVmDcezDymr 5zYBRvSrwTSr+TpbOCl5NajWHtkZAoZrWGEAmF4iJQxkLhDxK4T92gYpEjKU yUmD3PASrXMJEWltOpeS7UDOwDXTnHOVDlQkSnzjpPy24ZgQCRM3N4Mm2bIG yRJYRXbb0K668wbUkX9gY8tD/5QEpVRGvzBPZeRr2NM0jGFAUz6FVzEsouly kaJyMUvB6IJAfMP+CeELDQy1NyI0L+prKBDgtg33R6qDrNuHfB7/Sgc9UQNB xwSIyGgNwXeJX1NQiJAhlk+SkqkyWkLJ4cgbCl/vxUzk0IoO25hS87/ff0/s n78OH+jI79Z/3U+yYPOJwlOrg7XzxiuNkDNQhGGl/JtkdZqAmnpzrMW0tz9F vURZ4AgVvfGgn6oLjPGsHdEyVRAp/6oEUILB204uKG4Na5w99RJGGFZgwkbO BPWRMFRjA5IWgO6mcakMJm5/TFwqvID2MpXH1FDXqjSugb+ReNGW2j5480eQ FRbBLLG3EbYxRdddbOBAUCpIFwW1nzdqlSW61Q2/NBjeVrMbVT4PdwmjU6G7 ZeCHFfy1jViAa6UPJpg+RMbWxRWlWFkWrGk1bkBGlt6HX/z5vLWXX0VvYf6Z 0maoY4/pT4MQo3ChaZZkzBCYM0dgz7vTBYDWIUSjcUXhwTkdpBDrVU3UZhjS OzwmOEABnXYfQNKMcvTKaFEHF9CNg8q3Mkc7ZBEaiFwKoCF6mup+xk4zjqE/ 4kDHL92V6nnddGO8egW8W4igXBo4mVDzNGGTL1jB7z/TQaIpFfOaNEU26iVm /HOcFWyYSgjF2bAHXbRukNm6vQXbCUQj5M/APghMPnGFt+rZj5UABVAzhSrq gD+cxXX15EuJ2+8HKmBT+Cmawa7YzOT3eTpfGqKuUnkvvRHFEa0pE/fq22Re Y9BixaUnU3OeBsHJRG6K3JCaLtyESqUUsUFRgNZwA0puDfbEsM7QSh/9l8Nt U4GcREGmiyERIfjCsOBMO6ovRD56wFByHB5emngcAkQxJCUnEu4j7/nHHM24 zS5DUDc8CPxBexxsW/ImRb6xDQF33M4U++a9U0wYPPWav5EqihGTuCdBFR0Y xocEHTvdjl3C8bzu2+DoLbCSgwBLko3QPkCaHpwmwNq4BU5eX1lQoeBc3jvZ /+HW0fGuEv4r6b8q2v2v11svlPhfFeGClAJAFe3tm8K9HdABzFiihxeoECIb PlI0Ur68w16SvhsOmi2SDUflMDOIZWh1MHORy44n11ChsyN2p56cwTVwEnbh /bEtLMs8TF7GC7NA9QnDZG69egWGq0OikdUnjLUJ32180Q8ISRqL+e1/62Td 33QODTO/NUhx6jlJF3ynJUbXRbIwvCgJkcxIPwBtLTVgeNCUrv7kiN2SVBHR NyH8VLdCBvqIYoQgEUQQgAlmjo0k9JK/hHWirlzId+sBBujYKgQZAOpCQbhI TFgk4VTdEXMDG9cQCSoFETa0oYe8fVRv0Xxx9xF7xDIkBlVkebv/C3lJIVCW ogj1zm4W3t/ioAhqFuN7J1D+HpUsqXTaOIhM+0cKBxscBt08fRb2MD488CQe UDT4pLecKYJQigA0CaJRBpbZbi9E36WjTmKIzaeucTHaJNXgNNBjUtoGaWox CTiYbSC+BvU4aeQM1ILBEVhpsX2EGyzLXXtrSWIw/+vj5Kh3ArYjuWI2aKrF xLky5UKJtfezjTlWJtWHP+iI5U67Sv7xlMVW09E9/TibdUbj7oQsYBY6dFlH VR6ZvJ2dwZEucD+KN/EDXDaHvUxAt1bgU8ZEZpaOEU4tbxYLy2wJWqQuOX/D OFLe55D8+ap4zF6bMfvj0q8KI67608/O9HsOUVJtj7Ew9lJ0Aa6y4GsfBK23 NVBNx2EgHQoZXjgh7Ku9l7svDra3XpSsQIJDQA84VDJPzUU6YDtQVHdJHxe/ 0Ty4AyGGYz14m6OTwyI68o56LMadHB1WngVHDpWGBvaRotciIcpk7KMAhIqp 6RFeXMT0BNTg2ZbR+AK43Jlr4cGr6qg4tTKypiwf7+T65bEyZ6pgpaexkLIT 0HyT05FDHafmpKdzKUm2zEUXu2H6aNN2Dq1ClFrPjI7H8JvufSdrjHoy6g99 Ct5ZudhPCyOUSP/b1+ZZwTUXB7qrarnktSi3rRbEtv7fXaf4EjMSGNhXcmkr FB3YuTCtmIYsoWU432x3y5UuJZx3EsxzOHEdJPyzXzb9CvUHUbMab7U2ekFh scEKXCzVmVumYAj+AidLkoZcklwEqQOXwBa732m2mNntDcwr3212OH0Iil6t xJUINomhDdYILU6tmV7kZF9rzRWkBkmx2ET/PDNEDUhswNYWrEhnkbbI7oTo 83X8f/wd5zSNkUohIUChELvSivlep016+an19PRt1X4sVc/fNIEPGb1sFJut jm/3/ODFjnU6f9m7TANNMJrEJeZE+70BZF8BEsFFQyfBFbmryix52OmVJlYN yz19nn+M8nVZKbQh7g/ZSyEScV4mbj0uBhnSqniioc559WOyYH6wknl1kuOr XSb4d7hlTqFBv7rVxVwNsuHUGvPYWkpMOcbbT0A4COH34Jw5OoLZi3rS6xo0 NAD/2abNcMtuoiq3+ZTKLgSJj9d1fTJllSVjtezcHJHZphEFfMq65tgu7DUO ZQAENnjivw6rTgPgERIqd8kkSraQh08GcH0wR+cnRbGEsmUQS4ZhIrx0Heb/ PAASyJUk0ZlXknBEj9Au9vZr91cMRRfZD3r/Pm4/6L0K9oMjpt/WftglhFtC C9hMwkEnbonakMJtBsP/CZwTJ2KUW+ErcwLtW8ldg1FqEc2cIhq15LaomRs7 h8iy0G1hrIKwtMeiComQzEZMqfQpWS489/6A87z5yULMFHLyiUe6gGlhDEvD EcdBXsFidyAmMzT3nAlrxQkSe93heY5+R4CHq//ZxIidz9IT+PGyOYAfW/0B /XUNP/5zBK8U1B11sHR0Bj+O0z78OGgBvqvu9y7hx07aqr7fYCozJmPRRCV9 5lcu0D38O6AIH3311nfzV8FAcU3xwD6ra5FoPp5xAW9I9lYEgPXkYc0zpBpe LD4dXjRMRdNvRsIRCEn5MDSjshPaaXLqKGkKuUZE8Hef1UWP3tpHeb93he2u wc9QN8QPYcMv39YgV8PXKysA2rO2/1taHg2zzkzd/yflf3i4+mUh/8PDh4+f 3Pn//9X8/xGSguQP2rl7Ovd/6eWzO4/xO4/xO4/xO4/xv6fHOKLBT5gi4s/g Lx7x/54haa9Cy4WkPWX0gxDJlrrH2O8k1zOHqiLUZ+APNoSLIolVndeZE/Wq FjNIhIwv9pwXK4+DOerQfZIxQWXxg/qYE+Cc0/g5iDynnqxglvro2rwLII1y Ifc5jqQKIXnOmQpgiJNrUghbedF9aVqI/cghEmt1CV5pI66e9yPOGNTLmmls KtCM64mahRaLcnnEtO+8v/j0vMGFs2UonX68DOi6AXQh5KF5l8AYETRNLCFw o0dlUAaUtw9yCA1zWtkPk/EYQIoUOR2wMR/4cO1tqV0bQ8FZr9f2x4xAhZyr 7gLrBgHxiK/yIZWuD9XW6TPs7MdlInaJJYpABuEizRVZoDrQD4Edwurs4c7t W0F9HHge+uBnjqnbbg7aMwYo71wV6uJEOxZxYciP3rDR6o26Ns8LGufIJ0wk wX9J2HlVQT6JHhVH1JpS+yGJ+UUSvjOlS1aLa0djI7nCYEVp3T1nUETHH3Zl Gj6Oe1Wq3nk89CdUYz5NHoaivLDfQEQHcwh9klwTsxcPp8iSWogwWTSmfj/j B13egmlRaxS25e1m+wgh8cZi5Nu/D/phE0GP96ZHjJ2LzzzmrYJIyifXw/SX R2+9tEZU/R0U4a0JxWuPItI1rA2SMrqpT59Ci4XkK/vYSgX6ed+l2nlH8p5n zzYU0NG8srfSQOUOKup6R0vy/2pdtX74Vv+19pZ0bu7Lqle+8nb2+aXZ86MI hcBGS+g+MCMln/8TMN4Ri4HAsl6MdGZiXu9cVJQRfdH4/N+B+TnpPxwKRXuw aTw0lHWWzlMfmLc5gzrw6lXZ7GeNPYRW+EjCjI4MnHIs8f/pnlGiyzTdY7iC PLCvok++GP6XklAJmfxiH1wfy3DhiK4XkWnCFHjJ66fBLmQ7ZGbjvKTViy2x +gPbKnnIaVX4ci/RS66+8ONO/ZnBtWJMPca8WWX2+pq8c+o7m3CCm1tvBXmi 33s+3fhEbyaPQGfN61P6iOhQ78tXLztvFQlm93wncqnwTbKCQ8rfT5O1x4+n GtYtSzNd7hX45pvkq+R3e9wOGEIS2DJmf7Y4yH/Xf0vLl+kApG9/WP7vlcdr K6vF/N9PVu70P38x/Y+FJFQBrUYVIVOpgHRHn92mguVOw3KnYbnTsNxpWFDD YrFMBXTLH6RkkbiMpbqWgpJkitC2BkklEI7uujfCXcbtIVvNnGw69f71iaUc iUM9bx0vLumOLk7SwQZ6zoLvNkPUf3Ts+pZavQugE81w2PIKDFrNewADQ4qM M7xK3F+OanFwH6RIdddgQDmiIHrL1jO+Uvlx9whCUlYqVYOxnyRfP8b48k9m q8/hOYbc206W9ztNSYfDDwnti4sNyHf21tkxOQdMoDJXZkRMT5E9NE7f6iyG eTutRdE5BvvHgP8dMuXtmVcUdsG8Vqdp0xDb5PKJ0RTMG5/QwbTnd77D1JTF aYBxUNX6qHlt9g+On2/tHLwpaSjFqnXJLM0tgRCM2G9G2MIAXz/rEFIbwQ0L 5ttoNDv982bJ0FxaMu9Go5efNhqlbbG0pG0ze1fSzpSUtDkxXGRJIygqaZWP uiWNTElZm+v8cVkjU1TSatTN3gHOKGkpxSWtXzZe7+/9VNKWClXLWC3JLOQl Brp7///Q9/+OA777d/fv7/vv/wNXQB5cAFADAA== --416219727-1566035913-875087279=:10057--

On Wed, 24 Sep 1997, Colin_McFadyen wrote: > Due to the nature of our setup (multiple hardware and OS), we use > syslogging for most of our data collection. > > Is it possible to customize the syslog data returned by the TC? What type of customization are you looking for, the data is regular log type, it can be auth log or a variation of that level. krish \ T.S.V. Krishnan \ \ Network System Engineer \ ( : - : ) \ 3Com ............ \ ----------------------------------------------/ tkrishna@bubba.ae.usr.com ----------------------------/ http://interproc.ae.usr.com ----/ Any Sufficiently advanced bug is indistinguishable for a feature. - Rick Kulawiec > > Thanks. > > > > Colin McFadyen > > Carleton University CCS > > 409 Robertson Hall > > voice: 613-520-2600 ext. 3721 fax: 613-520-4448 > > >

Scott Portmaster List said once upon a time: > > >What happens when it locks ups and your only recourse is to powercylce? >(only happened once, but still) I think it is better to pop cycle the card than power cycle. All of our modem problems have usually sourced to bad power to the TC's.

Jim Seidel - Family Based Internet L.L.C. 708-957-5586 said once upon a time: > >When I attempt to FTP this site, I get an unable to find the file or >directory named /pub/lists/usr-tc/archives >> You might want to download the archives at: >> ftp://ftp.xmission.com/pub/lists/usr-tc/archives Sorry, the "archive" is not plural as I stated.

What happens when it locks ups and your only recourse is to powercylce? (only happened once, but still) On Tue, 23 Sep 1997, Jim Seidel - Family Based Internet L.L.C. 708-957-5586= wrote: > We have experienced the same thing. We were told "don't ever turn the > power off" by the USR Tech Support person. We haven't since. >=20 > --=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Jim Seidel - GM Family Based Internet L.L.C. > jimseidel@safeplace.net > 708-957-5586 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > Pascal Gosselin wrote: > >=20 > > Our TC chassis (the "newer one" if that makes any difference) has a pro= blem > > with its dual PRI card. > >=20 > > The T1 on it (it's going to two T1s this week) needs manual interventio= n > > before it will come up after a power cycling/reboot. This is a PRI > > connected to a Nortel switch. > >=20 > > We've never had such problem with our Max 4000's, so I assume this is > > a USR glitch. > >=20 > > Question: what's the fix for this ? > >=20 > > -Pascal > >=20 > > +--------------------------------------+-----------------------------+ > > Pascal Gosselin http://www.Mlink.NET | Mlink Internet Inc. > > pascal@Mlink.NET (514) 231-1923 | Montr=E9al, Qu=E9bec & Toront= o >=20 >=20

Anyone else here beginning to get pissed now that USR/3com is going to partner/include vital-sign's net-medic useless software with its modems? Read all about it at: http://biz.yahoo.com/prnews/97/09/23/coms_x000_1.html I'm still waiting for vital signs to make an 'anti-spam' list built into their net-medic software and include my email address in it :) Right now my procmail filter autoforwards all net-medic spam sent to our www domains and 'egress router problems' right to their sales people :) Their software is so usless its insane. Now USR includes it? That's one black mark in their column from me. Adam Wills Global 2000 Communications Director of Networking Systems 1840 Western Ave. sysadmin@global2000.net Albany, NY, 12203 http://www.global2000.net (518) 452-1465

>Anyone else here beginning to get pissed now that USR/3com is going to >partner/include vital-sign's net-medic useless software with its modems? > >Read all about it at: > >http://biz.yahoo.com/prnews/97/09/23/coms_x000_1.html > >I'm still waiting for vital signs to make an 'anti-spam' list built into >their net-medic software and include my email address in it :) Right now >my procmail filter autoforwards all net-medic spam sent to our www domains >and 'egress router problems' right to their sales people :) > >Their software is so usless its insane. Now USR includes it? That's one >black mark in their column from me. > >Adam Wills Global 2000 Communications >Director of Networking Systems 1840 Western Ave. >sysadmin@global2000.net Albany, NY, 12203 >http://www.global2000.net (518) 452-1465 |----------------------------------------------------------------| |Jordyn A. Buchanan mailto:jordyn@bestweb.net | |Bestweb Corporation http://www.bestweb.net | |Senior System Administrator +1.914.271.4500 | |----------------------------------------------------------------|

>Anyone else here beginning to get pissed now that USR/3com is going to >partner/include vital-sign's net-medic useless software with its modems? > >Read all about it at: > >http://biz.yahoo.com/prnews/97/09/23/coms_x000_1.html > >I'm still waiting for vital signs to make an 'anti-spam' list built into >their net-medic software and include my email address in it :) Right now >my procmail filter autoforwards all net-medic spam sent to our www domains >and 'egress router problems' right to their sales people :) > >Their software is so usless its insane. Now USR includes it? That's one >black mark in their column from me. I agree (just for the benefit of the 3Com people that read this move). This software is junk and indicates a lot of non-existent problem with ISP. As an ISP, I am extremely unhappy with this move by 3Com. Maybe it's time to go buy some other hardware in protest. Jordyn |----------------------------------------------------------------| |Jordyn A. Buchanan mailto:jordyn@bestweb.net | |Bestweb Corporation http://www.bestweb.net | |Senior System Administrator +1.914.271.4500 | |----------------------------------------------------------------|

Once upon a time Charles Fator shaped the electrons to say... >We at Texas Networking are not happy with this either. What are these >people smoke'n? SPEAKING FOR MYSELF: To me it seems like USR is WAY out of touch with the ISP marketplace to have even considered bundling this. Anyone who so much as glances at the industry lists and newsgroups periodically would have seen posts ranting about how much NetMedic sucks. It was all over the mailing lists and all over USEnet. If anyone in out Marketing department even thought about possibly suggesting it I'd've pounced on the idea and gutted it messily. The only USR rep regularly on inet-access was a sales droid, and even he hasn't been around in months. Whereas all of the other major vendors have a technical presence. This is just another sign. NOTE - THIS IS MZ TALKING, NOT LIVINGSTON. GOT THAT? -MZ

> Has anyone ever configured a menu using Merit radius? > > I have several users that want to run PPP as well as text mode using a > single login name. Can it be done? I set up the menu option for an Ascend Max 4000 running Livingston radius :), but what I have found to be the best option for our users on our usr-tc's is the "Prefix=" option in (once again) Livingston's radius 2.0.1. I have users type in ppp:<username> for a ppp connection, and just their username for a telnet connection. It works well, and you can offer quite a few options for users to login with by setting up DEFAULT profiles which include this Prefix= option. A sample line in the users file would look like this: DEFAULT Password="UNIX", Prefix=ppp: User-Service-Type=Framed-User It strips out the ppp: and starts a ppp session. I am not familiar with Merit radius, but maybe they have something similar? Brad -- ___________ Brad Hilton Smartlink Communications bhilton@smartlink.net

Lets start a class action lawsuit against usr for distributing fradulent software that may affect our buisness and lets see how fast they drop that garbage company.... Jordyn A. Buchanan wrote: > >Anyone else here beginning to get pissed now that USR/3com is going > to > >partner/include vital-sign's net-medic useless software with its > modems? > > > >Read all about it at: > > > >http://biz.yahoo.com/prnews/97/09/23/coms_x000_1.html > > > >I'm still waiting for vital signs to make an 'anti-spam' list built > into > >their net-medic software and include my email address in it :) > Right now > >my procmail filter autoforwards all net-medic spam sent to our www > domains > >and 'egress router problems' right to their sales people :) > > > >Their software is so usless its insane. Now USR includes it? That's > one > >black mark in their column from me. > > I agree (just for the benefit of the 3Com people that read this move). > > This software is junk and indicates a lot of non-existent problem with > ISP. > As an ISP, I am extremely unhappy with this move by 3Com. > > Maybe it's time to go buy some other hardware in protest. > > Jordyn > > |----------------------------------------------------------------| > |Jordyn A. Buchanan mailto:jordyn@bestweb.net | > |Bestweb Corporation http://www.bestweb.net | > |Senior System Administrator +1.914.271.4500 | > |----------------------------------------------------------------| -- Richard Mazurowski SurfNet Corporation sysop@surfnetcorp.com Voice (773) 283-9000 Fax (773) 283-9009

Ditto here, lets keep this software out of our hair. At 01:32 PM 9/24/97 -0500, you wrote: >We at Texas Networking are not happy with this either. What are these >people smoke'n? > > -Charlie Fator----------------------Technical Support------------ >| Texas Networking Inc. | Austin : (512) 427-1652 | >| | San Antonio: (210) 357-9200 | >| | Dallas : (214) 953-1005 | >| Hours Of Phone Support | Houston : (713) 222-2260 | >| Monday - Friday : 8am to 12am | Boerne : (830) 249-7058 | >| Saturday - Sunday :10am to 7pm | Dripping Sp: (512) 858-5092 | >| http://lonestar.texas.net/ | Georgetown : (512) 869-5947 | > ----------------------------------------------------------------- >| 'As one goes through it one sees that the gate one went | >| through was the self that went through it' - R.D. Lang | > ----------------------------------------------------------------- > > >On Wed, 24 Sep 1997, Adam Wills (Global 2000) wrote: > >> Anyone else here beginning to get pissed now that USR/3com is going to >> partner/include vital-sign's net-medic useless software with its modems? >> >> Read all about it at: >> >> http://biz.yahoo.com/prnews/97/09/23/coms_x000_1.html >> >> I'm still waiting for vital signs to make an 'anti-spam' list built into >> their net-medic software and include my email address in it :) Right now >> my procmail filter autoforwards all net-medic spam sent to our www domains >> and 'egress router problems' right to their sales people :) >> >> Their software is so usless its insane. Now USR includes it? That's one >> black mark in their column from me. >> >> Adam Wills Global 2000 Communications >> Director of Networking Systems 1840 Western Ave. >> sysadmin@global2000.net Albany, NY, 12203 >> http://www.global2000.net (518) 452-1465 >> >> >> >> > > > Greg Coffey, CoffeyNet 142 S. Center St. ** $20 local Casper USR x2 56k access ** Casper, WY 82601 Wheatland, Pinedale, Lander, Lusk http://www.coffey.com Douglas & Rawlins (307) 234-5443

We at Texas Networking are not happy with this either. What are these people smoke'n? -Charlie Fator----------------------Technical Support------------ | Texas Networking Inc. | Austin : (512) 427-1652 | | | San Antonio: (210) 357-9200 | | | Dallas : (214) 953-1005 | | Hours Of Phone Support | Houston : (713) 222-2260 | | Monday - Friday : 8am to 12am | Boerne : (830) 249-7058 | | Saturday - Sunday :10am to 7pm | Dripping Sp: (512) 858-5092 | | http://lonestar.texas.net/ | Georgetown : (512) 869-5947 | ----------------------------------------------------------------- | 'As one goes through it one sees that the gate one went | | through was the self that went through it' - R.D. Lang | ----------------------------------------------------------------- On Wed, 24 Sep 1997, Adam Wills (Global 2000) wrote: > Anyone else here beginning to get pissed now that USR/3com is going to > partner/include vital-sign's net-medic useless software with its modems? > > Read all about it at: > > http://biz.yahoo.com/prnews/97/09/23/coms_x000_1.html > > I'm still waiting for vital signs to make an 'anti-spam' list built into > their net-medic software and include my email address in it :) Right now > my procmail filter autoforwards all net-medic spam sent to our www domains > and 'egress router problems' right to their sales people :) > > Their software is so usless its insane. Now USR includes it? That's one > black mark in their column from me. > > Adam Wills Global 2000 Communications > Director of Networking Systems 1840 Western Ave. > sysadmin@global2000.net Albany, NY, 12203 > http://www.global2000.net (518) 452-1465 > > > >

Jeff Mcadams said once upon a time: >What we needed (and got setup) was the ability to have the person start >PPP and auth with PAP, but if nothing was forthcoming, fire off a telnet >to a shell server with no authentication on the NAS. Works like a >charm for us...no double authentication, users don't even know the >terminal server is there, and runs PPP on the terminal server >automatically and gets all the benefits therein. I modified my radius server and rlogind to do the following: PAP upon connect PPP upon username/password SLIP upon username@slip/password SHELL upon username@shell/password Thus, people aren't locked into using one protocol. Shell access comes in handy when you only have a terminal to work with.

Jeff Mcadams said once upon a time: >Drop me an email if you want the setup for it...if there's enough >interest, I'll post it here. The one thing you sacrifice is the >ability to login as !root from a dialup connection (no login prompt >presented by the netserver). I should add that my previously mentioned method still allows !root.

On Wed, 24 Sep 1997, Adam Wills (Global 2000) wrote: > I'm still waiting for vital signs to make an 'anti-spam' list built into > their net-medic software and include my email address in it :) Right now > my procmail filter autoforwards all net-medic spam sent to our www domains > and 'egress router problems' right to their sales people :) Actually, after the first couple 'egress router' complaints I emailed the net-medic people about it, and sure enough they acknowledged a bug in their software.. they said they would adjust the thresholds for the next version. They seemed pretty helpful and wrote back right away. Even to the point where they took the time to dial up to my usr-tc for testing. The new version was released in a couple weeks, and I haven't heard of any problems since. - lv

You wrote: > We at Texas Networking are not happy with this either. What are > these people smoke'n? The same thing that Net.Medic is smoking. We have stopped recommending USR modems to clients because of = this, and are aborting plans to support X2 at all. It's actually not that hard now since USR modems are having = trouble connecting to just about ALL PRI based NAS's. Watch this = company go down the tubes folks. -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

Hi all. Has anyone ever configured a menu using Merit radius? I have several users that want to run PPP as well as text mode using a single login name. Can it be done? > Colin McFadyen > Carleton University CCS > 409 Robertson Hall > voice: 613-520-2600 ext. 3721 fax: 613-520-4448 >

We just have two default entries, one with Framed-Protocol= PPP check item and PPP reply items and one without the Framed-Protocol= PPP with telnet reply items. We are using Livingston RADIUS 2.01 with some modifications. This seems to work with Portmaster 2, USR TC, and Computone PowerRack. DEFAULT Auth-Type= System, Framed-Protocol= PPP Service-Type = Framed-User, Framed-Protocol = PPP, Framed-IP-Address = 255.255.255.254, Framed-MTU = 1500, Framed-Compression = Van-Jacobson-TCP-IP DEFAULT Auth-Type = System Service-Type = Login-User, Login-Host = **.**.**.**, Login-Service = Telnet At 12:23 PM 9/24/97 +0000, you wrote: >> Has anyone ever configured a menu using Merit radius? >> >> I have several users that want to run PPP as well as text mode using a >> single login name. Can it be done? > >I set up the menu option for an Ascend Max 4000 running Livingston >radius :), but what I have found to be the best option for our users on >our usr-tc's is the "Prefix=" option in (once again) Livingston's radius >2.0.1. > >I have users type in ppp:<username> for a ppp connection, and just their >username for a telnet connection. It works well, and you can offer >quite a few options for users to login with by setting up DEFAULT >profiles which include this Prefix= option. > >A sample line in the users file would look like this: > >DEFAULT Password="UNIX", Prefix=ppp: > User-Service-Type=Framed-User > >It strips out the ppp: and starts a ppp session. > >I am not familiar with Merit radius, but maybe they have something >similar? > >Brad > >-- >___________ >Brad Hilton >Smartlink Communications >bhilton@smartlink.net > > J.S. Nakamura -- Kiva Networking -- Phone (812)337-5070 -- Fax (812)337-5082 jnakamur@kiva.net

Thus spake Colin_McFadyen >Has anyone ever configured a menu using Merit radius? No. >I have several users that want to run PPP as well as text mode using a >single login name. Can it be done? Yes....but we don't do it with menus. :) Drop me an email if you want the setup for it...if there's enough interest, I'll post it here. The one thing you sacrifice is the ability to login as !root from a dialup connection (no login prompt presented by the netserver). -- Jeff McAdams Email: jeffm@iglou.com Chief Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Due to the nature of our setup (multiple hardware and OS), we use syslogging for most of our data collection. Is it possible to customize the syslog data returned by the TC? Thanks. > Colin McFadyen > Carleton University CCS > 409 Robertson Hall > voice: 613-520-2600 ext. 3721 fax: 613-520-4448 >

At 02:55 PM 9/24/97 -0400, Jeff Mcadams wrote: >Thus spake Colin_McFadyen >>Has anyone ever configured a menu using Merit radius? > >No. > >>I have several users that want to run PPP as well as text mode using a >>single login name. Can it be done? > >Yes....but we don't do it with menus. :) > >Drop me an email if you want the setup for it...if there's enough >interest, I'll post it here. The one thing you sacrifice is the >ability to login as !root from a dialup connection (no login prompt >presented by the netserver). Actually you can get all of this if you use something called Realms in Merit's version. You configure the realm shell and every time a user wants to login into shell, they'll have to type username@shell. Garry Shtern shterng@akula.com Chief Network Administrator http://www.akula.com Akula Communications Corp. tel. (212) 292-8892

On Wed, 24 Sep 1997, Jeff Mcadams wrote: > Thus spake Garry Shtern > >Actually you can get all of this if you use something called Realms in > >Merit's version. You configure the realm shell and every time a user wants > >to login into shell, they'll have to type username@shell. > > Hrmm...never thought of doing it that way....still wouldn't be > backward compatible with some of our customer's setups, so that still > wouldn't work for us...neat idea though. > > What we needed (and got setup) was the ability to have the person start > PPP and auth with PAP, but if nothing was forthcoming, fire off a telnet > to a shell server with no authentication on the NAS. Works like a > charm for us...no double authentication, users don't even know the > terminal server is there, and runs PPP on the terminal server > automatically and gets all the benefits therein. Interesting. But how do you authenticate legacy trumpet dialer login.cmd scripts and MacPPP folks. We found a surprising number of long timers still on the old stuff. --jeff > -- > Jeff McAdams Email: jeffm@iglou.com > Chief Network Administrator Voice: (502) 966-3848 > IgLou Internet Services (800) 436-4456 > ========================================================================= Jeffrey A. Lynch, President 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

Thus spake Brad Hilton >> Has anyone ever configured a menu using Merit radius? >> I have several users that want to run PPP as well as text mode using a >> single login name. Can it be done? >I set up the menu option for an Ascend Max 4000 running Livingston >radius :), but what I have found to be the best option for our users on >our usr-tc's is the "Prefix=" option in (once again) Livingston's radius >2.0.1. Blech...I still think that's a horrible kludge. >I am not familiar with Merit radius, but maybe they have something >similar? Not that I'm aware of... -- Jeff McAdams Email: jeffm@iglou.com Chief Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Thus spake Garry Shtern >Actually you can get all of this if you use something called Realms in >Merit's version. You configure the realm shell and every time a user wants >to login into shell, they'll have to type username@shell. Hrmm...never thought of doing it that way....still wouldn't be backward compatible with some of our customer's setups, so that still wouldn't work for us...neat idea though. What we needed (and got setup) was the ability to have the person start PPP and auth with PAP, but if nothing was forthcoming, fire off a telnet to a shell server with no authentication on the NAS. Works like a charm for us...no double authentication, users don't even know the terminal server is there, and runs PPP on the terminal server automatically and gets all the benefits therein. -- Jeff McAdams Email: jeffm@iglou.com Chief Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

At 03:31 PM 9/24/97 -0400, Jeff Mcadams wrote: >Thus spake Garry Shtern >>Actually you can get all of this if you use something called Realms in >>Merit's version. You configure the realm shell and every time a user wants >>to login into shell, they'll have to type username@shell. > >Hrmm...never thought of doing it that way....still wouldn't be >backward compatible with some of our customer's setups, so that still >wouldn't work for us...neat idea though. > >What we needed (and got setup) was the ability to have the person start >PPP and auth with PAP, but if nothing was forthcoming, fire off a telnet >to a shell server with no authentication on the NAS. Works like a >charm for us...no double authentication, users don't even know the >terminal server is there, and runs PPP on the terminal server >automatically and gets all the benefits therein. >-- Cool.. I remember at the time when I was seting this up(2 years ago) I was looking for a solution like that, but couldn't find anything. I wonder how you guys implemented that. Garry Shtern shterng@akula.com Chief Network Administrator http://www.akula.com Akula Communications Corp. tel. (212) 292-8892

Thus spake Garry Shtern >Cool.. I remember at the time when I was seting this up(2 years ago) I was >looking for a solution like that, but couldn't find anything. I wonder how >you guys implemented that. Hrmm..ok...2 people want the information...that's enough for me. :) Keep in mind, first of all, that this is not a way that USR expected this to be done, but it does work. set connect off set pppmsg off (turns off annoying, IMHO, not necessary messages so it looks like the connection goes straight to the shell server) set radius prompt delay 12 set radius prompt none (12 second period to start up PPP and use auth pap..after that, telnet to shell server, and don't print a login prompt) set all login network dialin set all service_login telnet add user USR_NETS save all reset all Basically, it has a 12 second pause during which the person can start up ppp and use PAP auth, after that 12 seconds, then it uses the default username, USR_NETS, which has been added as a user in the netserver table (could also be put in RADIUS...just haven't done that yet here). The USR_NETS user is just a basic login user, uses default host to use the service_login service to connect to..in this case telnet. That's really all there is to it...the setup part that I wasn't aware of was the set radius prompt delay 12 and set radius prompt none which turned off the login prompt from being shown and uses the default userid of USR_NETS after the delay time for the "authentication". -- Jeff McAdams Email: jeffm@iglou.com Chief Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Thus spake Jay Nakamura >We just have two default entries, one with Framed-Protocol= PPP check item >and PPP reply items and one without the Framed-Protocol= PPP with telnet >reply items. Yup, then you login once on the terminal server, then get telnet'ed to the shell server and have to log in again.... Our goal was to not even have the users have to interact with the terminal servers at all (since we're still dealing with some users that were set up on our system back when we were using Digiboard multi-port serial connections, so there *wasn't* a terminal server to connect to). Additionally, many of those users are still using login scripts that connect them to our shell servers and run a pppd to run PPP off of our shell servers (again, for backwards compatibility), so we couldn't change the login procedure drastically. -- Jeff McAdams Email: jeffm@iglou.com Chief Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Thus spake Pete Ashdown >Jeff Mcadams said once upon a time: >>Drop me an email if you want the setup for it...if there's enough >>interest, I'll post it here. The one thing you sacrifice is the >>ability to login as !root from a dialup connection (no login prompt >>presented by the netserver). >I should add that my previously mentioned method still allows !root. Actually...now that I actually went back and tested it, so does mine...didn't even realize it...you just don't get a login: prompt displayed to tell you. Bonus! :) -- Jeff McAdams Email: jeffm@iglou.com Chief Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Thus spake Jeff Lynch >Interesting. But how do you authenticate legacy trumpet dialer login.cmd >scripts and MacPPP folks. We found a surprising number of long timers >still on the old stuff. Well, for the ones that are scripted to connect to our shell servers, the 12 second pause doesn't mess with them at all, then they get a login prompt on our shell servers just like they always have and proceed as normal starting pppd on the shell servers. Some of the newer ones are just scripted up to the point where they see the CONNECT from their modem and just fire up PPP at that point and use PAP auth (which trumpet does support) and away they go running ppp on the term servers. -- Jeff McAdams Email: jeffm@iglou.com Chief Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

I, too, heard about net medic, and its bad rep, a while back. I would *love* to see some really useful user end diags, like "You can't see it, but the server said 'Badpass' - check your capslock key!." It's pretty darned irresponsible of USR to bundle s/w that is going to give more headaches to a big part of their customer base. I've alerted support staff to be prepared for net medic suggested calls, which we are sure to get, as we have been 'officially' recommending usr user modems for years now. - P Sears Greg Coffey wrote: > > Ditto here, lets keep this software out of our hair. > > At 01:32 PM 9/24/97 -0500, you wrote: > >We at Texas Networking are not happy with this either. What are these > >people smoke'n? > >

Good luck this ISP stuff can be fun and profitable as long as you got big enough bottle of Maalox. "3 months into it." Just make sure you unit has the PRI code in the T1 cards. Wescon shipped us with Channalized T1 and we had to fight to be able to download the PRI firmware . Also make sure you have the "Do it Yourself x2 Chassis Installation" guide 30 pages It's got everything you need in on place. PS If your marketing person would like to exchange ideas with ours, her is her e-mail laurel@drfast.net Mike Hamrich Technical Director DrFast.Net, Inc.

This was extracted from their page.. http://www.vitalsigns.com/product/new.html ============================================================ Of Special Interest to ISPs * Improved Demarcation Algorithm Previously if an ISP had only two routers in their domain and the first router did not respond, Net.Medic incorrectly reported that the ISP egress router was not reachable. This situation is now recognized and handled correctly. * Local Database to Facilitate ISP Identification This version improves the database of ISPs in the product to identify the ISP name from many different ISP Point of Presence. It also handles many more ISP exchange points. * Improved Notify Capabilities Three major improvements have been made to the Net.Medic E-mail Notify function. First, automated E-mail notification is now only available for chronic problems or extremely severe warnings. This should help to minimize the possibility of flooding webmasters, system administrators, and ISPs with E-mails about intermittent problems. This, in turn, will enable them to focus on solving chronic problems that plague their users. Second, the text automatically included in the E-mail notification now includes a larger number of variables. In particular, IP and TCP errors are broken down into individual error conditions. The use of modem and the connection rate are also reported. The ISP entry and egress router addresses are included along with the actual server IP address contacted by the browser. Third, in order to help E-mail recipients understand and interpret the contents of a Net.Medic E-mail, the E-mail notification now includes an event number. This event number is a link to the Vital- Signs Web site. E-mail recipients can click on the link to open a Web page that contains more detailed information about the specific problem reported by the Net.Medic user. [Image] Bug Fixes 1. IP Address in Notify Mail Target The SMTP address in Notify target can now be an IP address rather than a fully qualified domain name. 2. Revised Thresholds Several Net.Medic thresholds were revised to reflect the feedback received during the Net.Medic 1.0 public beta. In particular, the thresholds, which caused the IP and network error conditions to be reported to system administrators and service providers, were revised. 3. Enhancements to the AutoCure Feature There were several improvements made to the Net.Medic AutoCure feature. There is a new AutoCure control panel that contains a list of previously cured AutoCures with the ability to undo or redo the cure. 4. New Filter For Hiding Low Severity Error Conditions You can now hide entries that have a low severity. This enhances the ability to filter and view health log messages in a Net.Medic report. To use this feature, choose Hide Low Severity from the View menu in the Health Log window. 5. CPU Load Monitoring The alarm thresholds for CPU and memory usage performance conditions have been significantly changed. 6. Invalid GDI Handle When Net.Medic is used with a debugging version of the kernel, it issued a few invalid GDI handle messages. These have been corrected. 7. Low Memory Condition on Windows NT A problem relating to the identification of low memory on Windows NT has been fixed. 8. Notify Against Slow SMTP Servers The timeout for notification has been increased from 4 seconds to 60 seconds so that the Net.Medic client can send E-mail notifications using SMTP servers that are slow to respond. In addition, the E-mail notification has also been moved to a separate thread. 9. Interaction Between E-mail and Browser Socket Activity A problem relating to E-mail (SMTP/POP) and browser socket activity caused the "Connection to Server" status message to be displayed in the Net.Medic status line. This problem has been corrected. 10. Memory Leak Problems Fixed There were several memory leaks that were fixed. In particular, if the browser auto-loaded more than 128 URLs in an hour, this caused a memory leak that lead to a memory corruption and Net.Medic crash. This problem has been fixed. ==========================================================================

I belive it was e-mailed to us by our USR rep. If they don't not about it, ill see if I can find the pdf file. It also has the title "Chassiss Installation.... Quick Reference Guide" > Have TONAGE worth of paperwork and CD's etc... Which one would that be!... >Not trying to sound sarcastic... > > >>PS If your marketing person would like to exchange ideas with ours, her is >>her e-mail >>laurel@drfast.net >> >>Mike Hamrich >>Technical Director >>DrFast.Net, Inc. >>---------- >>> From: John Campbell <sparky@intrlink.com> >>> To: usr-tc@mail.xmission.com >>> >> >> >> > >73's >John Campbell - KC4LWI >http://www.intrlink.com/~sparky >mailto:sparky@intrlink.com > > >

At 02:42 PM 9/24/97 -0400, you wrote: >Hi all. > >Has anyone ever configured a menu using Merit radius? > >I have several users that want to run PPP as well as text mode using a >single login name. Can it be done? > > There are patches available for Liv Rad 1.1x.. (Free one).. They give you the ability to add defs like DEFAULT.telnet DEFAULT.some_host etc.. in your rad users file.. Users would then login with username.service_type and they would get that default service type.. Users who just used their username would get the default service. These patches are floating around the web somewhere.. -M `'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`' Mike Wronski(mwronski@coredump.ae.usr.com) 3Com/U.S.Robotics Network Systems Engineer (Level 3) PGP: http://coredump.ae.usr.com/pgp

I was looking to modify the contents of the syslog records, not the facility or level of the messages (found the facility in netserver help). I would really like the negotiated IP address to be included in the syslog record. Right now the string looks like '... dialnet: port S23 PPP succeeded dest Negotiated.'. What is the 'dest'? > Colin McFadyen > Carleton University CCS > 409 Robertson Hall > voice: 613-520-2600 ext. 3721 fax: 613-520-4448 > > > ---------- > From: Tatai SV Krishnan[SMTP:tkrishna@bubba.ae.usr.com] > Reply To: usr-tc@mail.xmission.com > Sent: Wednesday, September 24, 1997 5:55 AM > To: usr-tc@mail.xmission.com > Subject: Re: (usr-tc) Can data be added to a syslog record? > > On Wed, 24 Sep 1997, Colin_McFadyen wrote: > > > Due to the nature of our setup (multiple hardware and OS), we use > > syslogging for most of our data collection. > > > > Is it possible to customize the syslog data returned by the TC? > > What type of customization are you looking for, the data is regular > log > type, it can be auth log or a variation of that level. > > krish > > ----------------------------------------- > \ T.S.V. Krishnan \ > \ Network System Engineer \ ( : - : ) > \ 3Com ............ \ > ----------------------------------------------/ > tkrishna@bubba.ae.usr.com > ----------------------------/ http://interproc.ae.usr.com ----/ > ---------------------------------------------------------------------- > ---\ > Any Sufficiently advanced bug is indistinguishable for a > feature. > - Rick Kulawiec > ---------------------------------------------------------------------- > ---/ > > > > > > Thanks. > > > > > > > Colin McFadyen > > > Carleton University CCS > > > 409 Robertson Hall > > > voice: 613-520-2600 ext. 3721 fax: 613-520-4448 > > > > > >

This post showed up on Livingston's mail list today. I think it hits the nail on the head perfectly. I really wish USR would at least respond to our concerns here- because our investment in their TC technology is just as vital as the end user's we recomend to buy sporster's and couriers. This can't go on, Vital signs must go away! USR: Is there somewhere we can voice our concerns about this with management, do they even care about our input? Calling our sales people this time isn't going to be enough to stop this from ruining USR at this point. Adam Wills Global 2000 Communications Director of Networking Systems 1840 Western Ave. sysadmin@global2000.net Albany, NY, 12203 http://www.global2000.net (518) 452-1465 ------------------ FROM LIVINGSTON PORTMASTER MAIL LIST --------------- From nezsez@iglobal.net Thu Sep 25 15:17:42 1997 Cc: rbatra@vitalsigns.com At one of the lectures at ISPCON 97', I won't say which one, someone in the audience asked about NetMedic, to which the lecturer (representing the IETF) made a joke about it's accuracy. The whole room busted out laughing, which indicates that a majority of ppl in this industry have allready had negative exposure to this product. This reminds me of a similiar fiasco with a certain "memory doubler" for win3.1/95 but I can't remember it's name. One of the big tech companies determined that this program actually did nothing but increase the default page size....something anyone could do by editing the system.ini or win.ini file by hand....only this program cost around $35.oo. Yes this company was nailed by a class action suit, and they were supposed to refund the money, or you could get the new version when they actually made a truly functional program. The company was SyncSoft or something like that.... does anyone remember what the actual program name was? Was it Ram95, then later Ram96? Of course they refused to give away "trade secrets" like their compression techniques....."well we change this line to this in the .ini file" hardly makes for a good $35.oo program. Contrast the previous scenarios with the plethora of computer testing/monitoring/benchmarking tools available which all clearly state, even encourage/demand that you read, the exact processes and variables which come into play and affect the results of that particular programs output. They do this because it is *essential* to a proper interpretation of the data, and is necessary for a proper solution to any problems. On 25-Sep-97 Joe Hartley wrote: >John Sulima <jsulima@riconnect.com> wrote: >> Pick one: >> >> 1) They won't disclose methodology because they consider it a >> trade secret. >> >> 2) They don't have faith in their own methodology and don't want >> to open it up to scrutiny. >> >> I suspect the latter. > >(Note: I've refrained from joining this thread until now because I didn't >want my opinions to be dismissed due to the severity of my initial >reaction. I'm calm enough now to respond :) <major snippage here>

Have you had any problems with the radius prompt delay affecting certain types of end-user software? I have a customer using an old dos client which can't seem to interact using ppp any longer now that I enabled the radius prompt delay. I noticed the default was 0, but I really like the options that the radius delay gives. Had any problems with it? Thanks, Brad > set connect off > set pppmsg off > (turns off annoying, IMHO, not necessary messages so it looks like the > connection goes straight to the shell server) > set radius prompt delay 12 > set radius prompt none > (12 second period to start up PPP and use auth pap..after that, telnet > to shell server, and don't print a login prompt) > set all login network dialin > set all service_login telnet > add user USR_NETS > save all > reset all > Basically, it has a 12 second pause during which the person can start up > ppp and use PAP auth, after that 12 seconds, then it uses the default > username, USR_NETS, which has been added as a user in the netserver > table (could also be put in RADIUS...just haven't done that yet here). > The USR_NETS user is just a basic login user, uses default host to > use the service_login service to connect to..in this case telnet. > > That's really all there is to it...the setup part that I wasn't aware of > was the set radius prompt delay 12 and set radius prompt none which > turned off the login prompt from being shown and uses the default userid > of USR_NETS after the delay time for the "authentication". > -- > Jeff McAdams Email: jeffm@iglou.com > Chief Network Administrator Voice: (502) 966-3848 > IgLou Internet Services (800) 436-4456 -- ___________ Brad Hilton Smartlink Communications bhilton@smartlink.net

>> 1) They won't disclose methodology because they consider it a >> trade secret. If the processes were useful, they'd patent it. Disclosing something that's undergoing patent consideration doesn't invalidate the claim on the patent. > They do this because it is *essential* to a proper interpretation of the data, > and is necessary for a proper solution to any problems. 100% accurate. -- Brad Wilson KA8RJS bradw @ pobox.com http://www.thebrads.com Objectivist, Software Engineer (Win32, STL, MFC, and sockets spoken here) "Life begins at 128 ... megs of RAM ... gigs of drive space ..."

Dest is the clients destination address. What it means is that a user dialed in he started ppp his ppp has succeded and his IPCP is over his destination address has be negotiated ( either he got a assigned address or he got some address ) that is the information that is sent to syslog. krish On Thu, 25 Sep 1997, Colin_McFadyen wrote: > I was looking to modify the contents of the syslog records, not the > facility or level of the messages (found the facility in netserver > help). > > I would really like the negotiated IP address to be included in the > syslog record. Right now the string looks like '... dialnet: port S23 > PPP succeeded dest Negotiated.'. What is the 'dest'? > > > Colin McFadyen > > Carleton University CCS > > 409 Robertson Hall > > voice: 613-520-2600 ext. 3721 fax: 613-520-4448 > > > > > > ---------- > > From: Tatai SV Krishnan[SMTP:tkrishna@bubba.ae.usr.com] > > Reply To: usr-tc@mail.xmission.com > > Sent: Wednesday, September 24, 1997 5:55 AM > > To: usr-tc@mail.xmission.com > > Subject: Re: (usr-tc) Can data be added to a syslog record? > > > > On Wed, 24 Sep 1997, Colin_McFadyen wrote: > > > > > Due to the nature of our setup (multiple hardware and OS), we use > > > syslogging for most of our data collection. > > > > > > Is it possible to customize the syslog data returned by the TC? > > > > What type of customization are you looking for, the data is regular > > log > > type, it can be auth log or a variation of that level. > > > > krish > > > > ----------------------------------------- > > \ T.S.V. Krishnan \ > > \ Network System Engineer \ ( : - : ) > > \ 3Com ............ \ > > ----------------------------------------------/ > > tkrishna@bubba.ae.usr.com > > ----------------------------/ http://interproc.ae.usr.com ----/ > > ---------------------------------------------------------------------- > > ---\ > > Any Sufficiently advanced bug is indistinguishable for a > > feature. > > - Rick Kulawiec > > ---------------------------------------------------------------------- > > ---/ > > > > > > > > > > Thanks. > > > > > > > > > > Colin McFadyen > > > > Carleton University CCS > > > > 409 Robertson Hall > > > > voice: 613-520-2600 ext. 3721 fax: 613-520-4448 > > > > > > > > > >

Thus spake Brad Hilton >Have you had any problems with the radius prompt delay affecting certain >types of end-user software? I have a customer using an old dos client >which can't seem to interact using ppp any longer now that I enabled the >radius prompt delay. I noticed the default was 0, but I really like the >options that the radius delay gives. >Had any problems with it? Nope, actually we initially had a problem with it being too short. We had it originally set to 4 seconds and found that if someone had marginal lines, oftentimes they would connect and their modem would do an almost immediate retrain and they'll miss that 4 second window. We then upped it to 12 seconds and have had no problems since. -- Jeff McAdams Email: jeffm@iglou.com Chief Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

We are running release 3.4.23 in the netserver and am going to update the code to 3.5.34. Will all the settings remain the same in the netserver? Also will updating the modems, NMC and Dual t-1 cards. We do not run PRi here so I am in dark as to all the references to PRI. Is there a certain order to do this? The current code is as follows as reported by the inventory listing in the windows tcm software: Modems 5.1.7 5.5.7 NMC 4.3.4 4.3.9 Netserver 3.4.23 3.5.34 Dual T-1 4.1.5 2.5.3 TCM windows 4.3.1 ??? This last has me confused as to why 2.5.3 would be an upgrade to 4.1.5? I have never upgraded this rack since purchasing it 4 months ago. Any procedural help would be appreciated greatly. Terry Kennedy, Lost in USR land... Thanks ahead...

I know I'm not supposed to send this kind of stuff to the list, but how do I get off this list. It doesn't put those nifty hints at the bottom of the messages like the ISP Mailing list. --- Mark Zedwick ProAxis Technical Support

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Which version of the NETServer 8/16I-Modem software includes support for the X2 modems? If what I have doesn't support X2, how do I get an upgrade? Since we purchased the box in August, I assume that the upgrade should be free? This is what I have: > Command> ver > > U.S. Robotics > Total Control (tm) NETServer 8/16 version 3.2.3.1 > > Build date: Sep 12 1996 > Build time: 15:37:35 > Command> Thanks for your help. Butch Butch Kemper | Free sound advice available Brazos Internet Consulting Group | "95% sound and 5% advice" 409-361-2324 | Refunds cheerfully provided -----BEGIN PGP SIGNATURE----- Version: PGP for Personal Privacy 5.0 Charset: noconv iQA/AwUBNCx47ihIHyLj1QScEQL8XgCeL3TrKsAY8EX06v1K+CD5vkncuQcAn1kr YErA3g6jHz8gNrnqfxYbZYjf =+qw0 -----END PGP SIGNATURE-----

We have a client that got a Royal Pent2 266 with a USR 56K internal voice modem. It had Windoz 95B on it with 128megs RAM. It had what appeared to be the correct 56K driver for it (came with the system), and when we called up the 888 number to re-verify our lines being X2 compliant (we knew they were but had to show client at office), it showed Yes OK for X2. What happens is that it refuses to connect over 31200. I even got down the USR latest x2 voice INF file and removed the modem copied in the file to the INF directory, replaced the modem and rebooted. It detected the modem as a U.S.Robotics Inc. Sportster 56000 Voice Internal (this is spelled, spaced and punctuated, verbatim), but would NOT use the INF that I put in the INF dir from USR. It would only see the INF if I removed the new one from USR and put in the one that came with the machine. I know X2 works for Many of our clientele, but this poor guy can't even get it to work at Our facility. Any one see this happen before? Am I not seeing the forest for the trees? Any help would be greatly appreciated. TTFN Bill Sheeler William M Sheeler, Sr www.talon.net ceo TCRA Computers and voice 610.670.6491 TALON Network Services, Inc voice 610.670.4923 Fax for both fax 610.670.6495 ( Total Area Linked Online Nationwide Network Services, Inc) " Live with Passion " " It's in your moments of decision that your destiny is shaped " ANTHONY ROBBINS

William M Sheeler Sr wrote: > > We have a client that got a Royal Pent2 266 with a USR 56K internal voice > modem. It had Windoz 95B on it with 128megs RAM. It had what appeared to > be the correct 56K driver for it (came with the system), and when we > called up the 888 number to re-verify our lines being X2 compliant (we knew > they were but had to show client at office), it showed Yes OK for X2. > > What happens is that it refuses to connect over 31200. > > I even got down the USR latest x2 voice INF file and removed the modem > copied in the file to the INF directory, replaced the modem and rebooted. > It detected the modem as a U.S.Robotics Inc. Sportster 56000 Voice Internal > (this is spelled, spaced and punctuated, verbatim), but would NOT use the > INF that I put in the INF dir from USR. It would only see the INF if I > removed the new one from USR and put in the one that came with the machine. > > I know X2 works for Many of our clientele, but this poor guy can't even get > it to work at Our facility. > > Any one see this happen before? Am I not seeing the forest for the trees? > > Any help would be greatly appreciated. > > TTFN > > Bill Sheeler > > William M Sheeler, Sr www.talon.net > ceo > TCRA Computers and voice 610.670.6491 > TALON Network Services, Inc voice 610.670.4923 > Fax for both fax 610.670.6495 > > ( Total Area Linked Online Nationwide Network Services, Inc) > > " Live with Passion " > > " It's in your moments of decision that your destiny is shaped " > ANTHONY ROBBINS Welcome to the wonderful world of X2!!!!!!!!

Dear Richard/William, > > INF that I put in the INF dir from USR. It would only see the INF if I > > removed the new one from USR and put in the one that came with the machine. Yep - that's the final fix. > > Any one see this happen before? Am I not seeing the forest for the trees? Yes. Perhaps :-) Get the client to dial the USR X2 test facility and take a careful note of the SNR value. I think 39dB is the theoretical floor value for X2. One case I'm dealing with the client has an SNR of ~40.8dB and sometimes the tester says "Your line will support X2", other times it says it won't. This is consistent with his connects - very few are above 31.2Kbps. Many Regards, -- David Carter, 2nd Level Support, NETCOM Internet. david@corp.netcom.net.uk I am filled with humidity. Texas House Speaker Gib Lewis.

Keep in mind that you should be calling the USR X2 # with a _NON_ X2 modem, otherwise you will get false posistives. On Sun, Sep 28, 1997 at 01:49:53AM +0100, David Carter made some electrons appear in the following form: > Dear Richard/William, > > > > INF that I put in the INF dir from USR. It would only see the INF if I > > > removed the new one from USR and put in the one that came with the machine. > > Yep - that's the final fix. > > > > Any one see this happen before? Am I not seeing the forest for the trees? > > Yes. Perhaps :-) Get the client to dial the USR X2 test facility and take > a careful note of the SNR value. I think 39dB is the theoretical floor > value for X2. One case I'm dealing with the client has an SNR of ~40.8dB > and sometimes the tester says "Your line will support X2", other times it > says it won't. This is consistent with his connects - very few are above > 31.2Kbps. > > Many Regards, > -- > David Carter, 2nd Level Support, NETCOM Internet. > david@corp.netcom.net.uk > I am filled with humidity. Texas House Speaker Gib Lewis. > -- yackity yackity yackity, don't you ever shut up?

On Sun, 28 Sep 1997, Brett Hawn wrote: > Keep in mind that you should be calling the USR X2 # with a _NON_ X2 modem, > otherwise you will get false posistives. Also, the USR test phone # is running x2 modems. If you have an x2 modem, and you call the test number, you should get an x2 connect. I've seen people call the x2 test line with an x2 modem, connect at V.34, and yet the program still says their line is x2 compatible! Brian

On Mon, 29 Sep 1997, Jeff Mcadams wrote: > Thus spake Brian > >On Mon, 29 Sep 1997, Pete Ashdown wrote: > >> I would emphasize that you have to get your retrains down to 0 (checkable > >> via ATI6). This is done by lowering the maximum connect rate with &N. > >> Retrains were the most common cause of 999 pings we've found here. > > >So this is on the client side, as per client right? I mean when I dial > >into a multi port serial board with sportsters hanging off it, or a > >portmaster, I have no problems, its almost like tc hub > >related.............. > > Sounds like the retrains are tickling a bug in the netservers, is USR > aware of this? Checked the field reports on totalservice and didn't see > any mention of retrains in the field report concerning Quake Lag (2135). > USR has not yet fixed this problem. 3.5.93 does help in resolving some quake latency. The same fix is ported in 3.5.34. We do know that there are some customer who have seen this quake latency problem with 3.5.93 and 3.5.34. We are working with the customers. I request all of you who have this problem to please send me an email with your phone number. I would like to talk to you and some back ground on the problem to help us analyze and solve this problem ASAP. regards krish \ T.S.V. Krishnan \ \ Network System Engineer \ ( : - : ) \ 3Com ............ \ ----------------------------------------------/ tkrishna@bubba.ae.usr.com ----------------------------/ http://interproc.ae.usr.com ----/ Any Sufficiently advanced bug is indistinguishable for a feature. - Rick Kulawiec > The following from totalservice: > > Report generated: Monday September 22, 1997 > > Product: NETServer (All) > Title: Quake Causes the Latency in the NETServer > ID: 2135 > Revision: 3.4.23, 3.5.31 > Date: 30-MAY-97 > Frequency: Repro In House > > Description: When the NETServer has combination of users playing quake > and browsing the web there is a high amout of latency. The ping to the > NETServer, with no traffic from an ISDN connection is around 35 ms. > When one users logs in and starts playing quake, the ping delay is > still 35 ms. When another user logs in and starts browsing the web, > the ping delay increases from 35 ms to 512 ms. > > Workaround Notes: Netserver 3.5.93 code does not have this problem. > The customer who have this code have been satisfied with the > performance and do not see the latency problem. This fix has been > ported to 3.5.34 code > > > Sounds to me like USR thought they had it fixed and thought it was an > issue of quake and web traffic. Maybe they found another bug? > -- > Jeff McAdams Email: jeffm@iglou.com > Chief Network Administrator Voice: (502) 966-3848 > IgLou Internet Services (800) 436-4456 >

Brian, We have been working hard to find a solution to this quake problem. We have seen this problem in our lab. We cannot succesfully reproduce this problem as and when needed. Please let me know how we can reproduce the problem, time and time again. Any help from you is greatly appriciated. krish \ T.S.V. Krishnan \ \ Network System Engineer \ ( : - : ) \ 3Com ............ \ ----------------------------------------------/ tkrishna@bubba.ae.usr.com ----------------------------/ http://interproc.ae.usr.com ----/ Any Sufficiently advanced bug is indistinguishable for a feature. - Rick Kulawiec On Mon, 29 Sep 1997, Brian wrote: > Is there any new information on the Quake lag situation? > > Not a day goes by that I don't get flamed for the lag when users go into > Quake via a USR TC hub. I'll try anything at this point......... > > Brian > > > /-------------------------- signal@shreve.net -----------------------------\ > | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | > | Systems Administrator | Perl, Linux | Web hosting, online stores, | > | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | > | 89 CRX, Akimoto intake, DC |-=*:Quake:*=-| http://www.shreve.net/ | > | headers, Eurosport exhaust |LordSignal/SN| Quake server: 208.206.76.3 | > \-------------------------- 318-222-2638 x109 -----------------------------/ > > >

Ported means that the fixes in 3.5.93 is already there in 3.5.34. 3.5.34 is released code and this code was released after 3.5.93 ( we have different scheme for ER code releases - thus the numbering ). So there is only one 3.5.34 and this code has the same exact fixes that are present in 3.5.93 - in regards to quake. krish \ T.S.V. Krishnan \ \ Network System Engineer \ ( : - : ) \ 3Com ............ \ ----------------------------------------------/ tkrishna@bubba.ae.usr.com ----------------------------/ http://interproc.ae.usr.com ----/ Any Sufficiently advanced bug is indistinguishable for a feature. - Rick Kulawiec On Mon, 29 Sep 1997, Brian Elfert wrote: > > > On Mon, 29 Sep 1997, Tatai SV Krishnan wrote: > > > USR has not yet fixed this problem. 3.5.93 does help in resolving some > > quake latency. The same fix is ported in 3.5.34. We do know that there > > What exactly does it mean by 'The fix is ported in 3.5.34'? > > Does this mean that 3.5.34 downloaded today is not the same as 3.5.34 > downloaded the same day it came out? > > Brian > >

I am trying to use Livingston Radius with the Total Control Unit and am having problems. It will connect and appear to authenticate using the Win 95 Dialer, and then disconnects after about 25 seconds. If I add a user inside the Total Control Unit it will authenticate correctly and the connection will hold. This leads me to the conclusion that something with the Radius server is not working correctly and I would like any input on tweaking Livingston Radius to get it to work with the Total Control unit. Here is the Radius version information, running on Redhat Linux 4.2 RADIUS version 2.0 96/10/30 NDBM PASSCHANGE flat_users Any clues would be greatly appreciated. Thanks. Scott Smith

> Any other ideas? Any reason why the telco would reject > ISDN calls to a PRI? Other calls are OK. I've had major problems with configuring users for isdn usage as the tc's won't answer both 64K and 56K calls at the same time. They have to be set to either/or. So, if your customer is trying to call in at 56K, the machine won't even recognize his call. Through our telco, the customer actually has to dial the call with 11 digits instead of 7 just to enable the 64K speed. So...you may want to look into that. Brad

Kent Tambling said once upon a time: >1) is the resource pool assignment to the incoming PRI call >necessary or even recommended? Without it the calls would >initiate on the last PRI port (s28) and walk backwards. With >it it seems to start at port 5 and proceed to highr ports. I would recommend it, that way your modems get more even use than without it. It also helps move things along in case a modem goes bad. >2) Can't answer a simple ISDN single B call! Are there any >all to obvious settings that we may be missing? Set to answer >'both' analog and digital, analog calls are fine, gateway set to >same pool id as succesful analog calls coming in (id 1). I'm >hoping for simple dial-up ISDN just like dialup 56k... Not sure what your problem could be here. It may be telco related. Do you have your ISDN-GW slot set to your Netserver? (Click on PRI card, Configuration, Programmed Settings, PRI Settings)

Thanks. USR repeatedly told me that the equipment couldn't answer for both speeds, and though it seemed ridiculous, I thought it reasonable to believe them. I'll try your recommendation. Pete Ashdown wrote: > > Brad Hilton said once upon a time: > > >I've had major problems with configuring users for isdn usage as the > >tc's won't answer both 64K and 56K calls at the same time. They have to > >be set to either/or. > > Huh? My TCs can accept both. Here's a snippet of "show all": > > I0 64k-sync 207.135.153.129 Netwrk ESTABLISHED 10466015 18466704 0 > I1 56k-sync antrym.users.xmi Netwrk ESTABLISHED 2430386 6154843 0 > I2 64k-sync aspengrove.com Netwrk ESTABLISHED 127795 399929 0 > I3 56k-sync 166.70.35.1 Netwrk ESTABLISHED 666293 2170451 0 > I4 64k-sync splat.mindwell.c Netwrk ESTABLISHED 3426245 1243126 0 > I5 56k-sync niche-associates Netwrk ESTABLISHED 1643911 10847557 13632 > I6 idle 0.0.0.0 Login/ IDLE 10562 13410 0 > I7 64k-sync slc111.modem.xmi Netwrk ESTABLISHED 399272 3004492 0 > I8 56k-sync router.klmlaw.co Netwrk ESTABLISHED 697299 11365387 0 > I9 56k-sync unionpointe.com Netwrk ESTABLISHED 51448 157845 0 > > You've "set isdnservice rate auto" I presume? -- ___________ Brad Hilton Smartlink Communications bhilton@smartlink.net

Kent Tambling said once upon a time: >Should b-channels avail = 46 or 23 or what? (only one >PRI is used, the rest is analog). I'm not quite clear on what you're stating here. You have two PRIs or one? How do the analog lines come in? Do you accept analog calls over your PRIs? >Any other ideas? Any reason why the telco would reject >ISDN calls to a PRI? Other calls are OK. They may have provisioned it only to accept analog calls. Also, verify that your switch type meshes with the switch that the telco is using.

Brad Hilton said once upon a time: >I've had major problems with configuring users for isdn usage as the >tc's won't answer both 64K and 56K calls at the same time. They have to >be set to either/or. Huh? My TCs can accept both. Here's a snippet of "show all": I0 64k-sync 207.135.153.129 Netwrk ESTABLISHED 10466015 18466704 0 I1 56k-sync antrym.users.xmi Netwrk ESTABLISHED 2430386 6154843 0 I2 64k-sync aspengrove.com Netwrk ESTABLISHED 127795 399929 0 I3 56k-sync 166.70.35.1 Netwrk ESTABLISHED 666293 2170451 0 I4 64k-sync splat.mindwell.c Netwrk ESTABLISHED 3426245 1243126 0 I5 56k-sync niche-associates Netwrk ESTABLISHED 1643911 10847557 13632 I6 idle 0.0.0.0 Login/ IDLE 10562 13410 0 I7 64k-sync slc111.modem.xmi Netwrk ESTABLISHED 399272 3004492 0 I8 56k-sync router.klmlaw.co Netwrk ESTABLISHED 697299 11365387 0 I9 56k-sync unionpointe.com Netwrk ESTABLISHED 51448 157845 0 You've "set isdnservice rate auto" I presume?

We have a total control configured first half PRI, second half analog. Am using a single resource pool to insure proper partioning. Two questions: 1) is the resource pool assignment to the incoming PRI call necessary or even recommended? Without it the calls would initiate on the last PRI port (s28) and walk backwards. With it it seems to start at port 5 and proceed to highr ports. 2) Can't answer a simple ISDN single B call! Are there any all to obvious settings that we may be missing? Set to answer 'both' analog and digital, analog calls are fine, gateway set to same pool id as succesful analog calls coming in (id 1). I'm hoping for simple dial-up ISDN just like dialup 56k... Using USR Radius on NT. Thanks in advance. Kent Tambling AccelerationNet

Pete: Thanks for getting back so soon. ISDN-GW is already set to 16. Should b-channels avail = 46 or 23 or what? (only one PRI is used, the rest is analog). Any other ideas? Any reason why the telco would reject ISDN calls to a PRI? Other calls are OK. Thanks, Kent Tambling AccelerationNet

Is there any new information on the Quake lag situation? Not a day goes by that I don't get flamed for the lag when users go into Quake via a USR TC hub. I'll try anything at this point......... Brian /-------------------------- signal@shreve.net -----------------------------\ | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | | Systems Administrator | Perl, Linux | Web hosting, online stores, | | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | | 89 CRX, Akimoto intake, DC |-=*:Quake:*=-| http://www.shreve.net/ | | headers, Eurosport exhaust |LordSignal/SN| Quake server: 208.206.76.3 | \-------------------------- 318-222-2638 x109 -----------------------------/

Jeff Mcadams said once upon a time: > >Thus spake Brian >>Is there any new information on the Quake lag situation? > >>Not a day goes by that I don't get flamed for the lag when users go into >>Quake via a USR TC hub. I'll try anything at this point......... > >Have you tried 3.5.93 yet? Supposedly fixes it (no, I haven't gotten >it, but should be fairly soon now). I would emphasize that you have to get your retrains down to 0 (checkable via ATI6). This is done by lowering the maximum connect rate with &N. Retrains were the most common cause of 999 pings we've found here.

Thus spake Brad Hilton >> Any other ideas? Any reason why the telco would reject >> ISDN calls to a PRI? Other calls are OK. >I've had major problems with configuring users for isdn usage as the >tc's won't answer both 64K and 56K calls at the same time. They have to >be set to either/or. So, if your customer is trying to call in at 56K, >the machine won't even recognize his call. Through our telco, the >customer actually has to dial the call with 11 digits instead of 7 just >to enable the 64K speed. So...you may want to look into that. Uhm....no. I've looked at our netservers and had them answering both 64 and 56 calls at the same time...no problem....for example: I0 56k-sync Netwrk ESTABLISHED 1530277 3601113 0 I1 64k-sync Netwrk ESTABLISHED 75714 103380 0 I2 64k-sync Netwrk ESTABLISHED 10051 800150 0 I3 64k-sync - Netwrk CONNECTING 124 85 0 (IP addresses deleted to protect the guilty :) That I3 is an MPIP link BTW...any possibilities of getting these netserver to report MPIP connections in a more...uhm...intuitive manner? -- Jeff McAdams Email: jeffm@iglou.com Chief Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Thus spake Brian >Is there any new information on the Quake lag situation? >Not a day goes by that I don't get flamed for the lag when users go into >Quake via a USR TC hub. I'll try anything at this point......... Have you tried 3.5.93 yet? Supposedly fixes it (no, I haven't gotten it, but should be fairly soon now). -- Jeff McAdams Email: jeffm@iglou.com Chief Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

On Mon, 29 Sep 1997, Jeff Mcadams wrote: > Thus spake Brian > >Is there any new information on the Quake lag situation? > > >Not a day goes by that I don't get flamed for the lag when users go into > >Quake via a USR TC hub. I'll try anything at this point......... > > Have you tried 3.5.93 yet? Supposedly fixes it (no, I haven't gotten > it, but should be fairly soon now). Yes I run 3.5.93, and no it doesnt solve the problem. Brian > -- > Jeff McAdams Email: jeffm@iglou.com > Chief Network Administrator Voice: (502) 966-3848 > IgLou Internet Services (800) 436-4456 > /-------------------------- signal@shreve.net -----------------------------\ | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | | Systems Administrator | Perl, Linux | Web hosting, online stores, | | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | | 89 CRX, Akimoto intake, DC |-=*:Quake:*=-| http://www.shreve.net/ | | headers, Eurosport exhaust |LordSignal/SN| Quake server: 208.206.76.3 | \-------------------------- 318-222-2638 x109 -----------------------------/

On Mon, 29 Sep 1997, Pete Ashdown wrote: > Jeff Mcadams said once upon a time: > > > >Thus spake Brian > >>Is there any new information on the Quake lag situation? > > > >>Not a day goes by that I don't get flamed for the lag when users go into > >>Quake via a USR TC hub. I'll try anything at this point......... > > > >Have you tried 3.5.93 yet? Supposedly fixes it (no, I haven't gotten > >it, but should be fairly soon now). > > I would emphasize that you have to get your retrains down to 0 (checkable > via ATI6). This is done by lowering the maximum connect rate with &N. > Retrains were the most common cause of 999 pings we've found here. > So this is on the client side, as per client right? I mean when I dial into a multi port serial board with sportsters hanging off it, or a portmaster, I have no problems, its almost like tc hub related.............. Brian /-------------------------- signal@shreve.net -----------------------------\ | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | | Systems Administrator | Perl, Linux | Web hosting, online stores, | | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | | 89 CRX, Akimoto intake, DC |-=*:Quake:*=-| http://www.shreve.net/ | | headers, Eurosport exhaust |LordSignal/SN| Quake server: 208.206.76.3 | \-------------------------- 318-222-2638 x109 -----------------------------/

On Mon, 29 Sep 1997, Pete Ashdown wrote: > Jeff Mcadams said once upon a time: > > > >Thus spake Brian > >>Is there any new information on the Quake lag situation? > > > >>Not a day goes by that I don't get flamed for the lag when users go into > >>Quake via a USR TC hub. I'll try anything at this point......... > > > >Have you tried 3.5.93 yet? Supposedly fixes it (no, I haven't gotten > >it, but should be fairly soon now). > > I would emphasize that you have to get your retrains down to 0 (checkable > via ATI6). This is done by lowering the maximum connect rate with &N. > Retrains were the most common cause of 999 pings we've found here. > also users get better pings coming accross the router from other isp's, rather than local via a tc hub. Brian /-------------------------- signal@shreve.net -----------------------------\ | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | | Systems Administrator | Perl, Linux | Web hosting, online stores, | | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | | 89 CRX, Akimoto intake, DC |-=*:Quake:*=-| http://www.shreve.net/ | | headers, Eurosport exhaust |LordSignal/SN| Quake server: 208.206.76.3 | \-------------------------- 318-222-2638 x109 -----------------------------/

Once upon a time Mark R. Lindsey shaped the electrons to say... >bothers me. I'm wondering what it is about Quake that gives TC units >such fits. Is it weird bit patterns in the packets? Is it odd sequences, >or timing, or what? Lots of small packets that need to get through in a big hurry. It will trip up any NAS that doesn't deal with hordes of small packets well, or that have latency issues. Whereas MS Flight Simulator used to be the torture test for PCs, Quake is turning into the same thing for NASes. -MZ -- Livingston Enterprises - Chair, Department of Interstitial Affairs Phone: 800-458-9966 510-737-2100 FAX: 510-737-2110 megazone@livingston.com For support requests: support@livingston.com <http://www.livingston.com/> Snail mail: 4464 Willow Road, Pleasanton, CA 94588

On Mon, 29 Sep 1997, Tatai SV Krishnan wrote: > USR has not yet fixed this problem. 3.5.93 does help in resolving some > quake latency. The same fix is ported in 3.5.34. We do know that there What exactly does it mean by 'The fix is ported in 3.5.34'? Does this mean that 3.5.34 downloaded today is not the same as 3.5.34 downloaded the same day it came out? Brian

Guys, do tcs support digital over voice ISDN connections? If not, what exactly are 56k connections? At 03:43 PM 9/29/97 -0600, Pete Ashdown wrote: >Brad Hilton said once upon a time: > >>I've had major problems with configuring users for isdn usage as the >>tc's won't answer both 64K and 56K calls at the same time. They have to >>be set to either/or. > >Huh? My TCs can accept both. Here's a snippet of "show all": > >I0 64k-sync 207.135.153.129 Netwrk ESTABLISHED 10466015 18466704 0 >I1 56k-sync antrym.users.xmi Netwrk ESTABLISHED 2430386 6154843 0 >I2 64k-sync aspengrove.com Netwrk ESTABLISHED 127795 399929 0 >I3 56k-sync 166.70.35.1 Netwrk ESTABLISHED 666293 2170451 0 >I4 64k-sync splat.mindwell.c Netwrk ESTABLISHED 3426245 1243126 0 >I5 56k-sync niche-associates Netwrk ESTABLISHED 1643911 10847557 13632 >I6 idle 0.0.0.0 Login/ IDLE 10562 13410 0 >I7 64k-sync slc111.modem.xmi Netwrk ESTABLISHED 399272 3004492 0 >I8 56k-sync router.klmlaw.co Netwrk ESTABLISHED 697299 11365387 0 >I9 56k-sync unionpointe.com Netwrk ESTABLISHED 51448 157845 0 > >You've "set isdnservice rate auto" I presume? Garry Shtern shterng@akula.com Chief Network Administrator http://www.akula.com Akula Communications Corp. tel. (212) 292-8892

It appears that I have answered my own question. I was able to get this working by editting the Livingston Radius users file (/etc/raddb/users). I played with a few of the entries and finally commented out the following line Framed-Filter-Id = "std.ppp.in", This seems to have fixed the problem. Thanks. Scott Smith At 12:10 PM 9/29/97 -0400, you wrote: >I am trying to use Livingston Radius with the Total Control Unit and am >having problems. It will connect and appear to authenticate using the Win >95 Dialer, and then disconnects after about 25 seconds. If I add a user >inside the Total Control Unit it will authenticate correctly and the >connection will hold. This leads me to the conclusion that something with >the Radius server is not working correctly and I would like any input on >tweaking Livingston Radius to get it to work with the Total Control unit. > >Here is the Radius version information, running on Redhat Linux 4.2 > >RADIUS version 2.0 96/10/30 NDBM PASSCHANGE flat_users > >Any clues would be greatly appreciated. > >Thanks. Scott Smith > > >

At 06:32 PM 9/29/97 -0400, Jeff Mcadams wrote: >Thus spake Brian >>Is there any new information on the Quake lag situation? > >>Not a day goes by that I don't get flamed for the lag when users go into >>Quake via a USR TC hub. I'll try anything at this point......... > >Have you tried 3.5.93 yet? Supposedly fixes it (no, I haven't gotten >it, but should be fairly soon now). Where do you get that version? USR is not really anxious to give out anything to their customers but the released code.. Garry Shtern shterng@akula.com Chief Network Administrator http://www.akula.com Akula Communications Corp. tel. (212) 292-8892

Thus spake Brian >On Mon, 29 Sep 1997, Pete Ashdown wrote: >> I would emphasize that you have to get your retrains down to 0 (checkable >> via ATI6). This is done by lowering the maximum connect rate with &N. >> Retrains were the most common cause of 999 pings we've found here. >So this is on the client side, as per client right? I mean when I dial >into a multi port serial board with sportsters hanging off it, or a >portmaster, I have no problems, its almost like tc hub >related.............. Sounds like the retrains are tickling a bug in the netservers, is USR aware of this? Checked the field reports on totalservice and didn't see any mention of retrains in the field report concerning Quake Lag (2135). The following from totalservice: Report generated: Monday September 22, 1997 Product: NETServer (All) Title: Quake Causes the Latency in the NETServer ID: 2135 Revision: 3.4.23, 3.5.31 Date: 30-MAY-97 Frequency: Repro In House Description: When the NETServer has combination of users playing quake and browsing the web there is a high amout of latency. The ping to the NETServer, with no traffic from an ISDN connection is around 35 ms. When one users logs in and starts playing quake, the ping delay is still 35 ms. When another user logs in and starts browsing the web, the ping delay increases from 35 ms to 512 ms. Workaround Notes: Netserver 3.5.93 code does not have this problem. The customer who have this code have been satisfied with the performance and do not see the latency problem. This fix has been ported to 3.5.34 code Sounds to me like USR thought they had it fixed and thought it was an issue of quake and web traffic. Maybe they found another bug? -- Jeff McAdams Email: jeffm@iglou.com Chief Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Thus spake Garry Shtern >At 06:32 PM 9/29/97 -0400, Jeff Mcadams wrote: >>Have you tried 3.5.93 yet? Supposedly fixes it (no, I haven't gotten >>it, but should be fairly soon now). >Where do you get that version? USR is not really anxious to give out >anything to their customers but the released code.. Uhm...was gonna call tech support and chew some butt until I got it. :) I've been *fairly* successful with that tactic in the past. More concerned about getting the ISDN bonded idle timeout problem fixed first though. -- Jeff McAdams Email: jeffm@iglou.com Chief Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

At 06:34 PM 9/29/97 -0500, Brian wrote: >On Mon, 29 Sep 1997, Jeff Mcadams wrote: > >> Thus spake Brian >> >Is there any new information on the Quake lag situation? >> >> >Not a day goes by that I don't get flamed for the lag when users go into >> >Quake via a USR TC hub. I'll try anything at this point......... >> >> Have you tried 3.5.93 yet? Supposedly fixes it (no, I haven't gotten >> it, but should be fairly soon now). > >Yes I run 3.5.93, and no it doesnt solve the problem. > >Brian Where did you get that code? Garry Shtern shterng@akula.com Chief Network Administrator http://www.akula.com Akula Communications Corp. tel. (212) 292-8892

Being new to the USR, and not quite on line with it yet (ma bell has not install PRI Line). I have users asking about ISDN. Installed in my rack (1909 package) is a "1 Dual PRI Card, 6 Quad Cards, 1 Net Server Card, and 1 Net Manager Card". What do I need to add to support ISDN. 73's John Campbell - KC4LWI http://www.intrlink.com/~sparky mailto:sparky@intrlink.com

My header bears a silly question, because the tone of all of this furor bothers me. I'm wondering what it is about Quake that gives TC units such fits. Is it weird bit patterns in the packets? Is it odd sequences, or timing, or what? We should separate the networking code bug from the application that's tickling it. We can then develop other utilities to help us test and diagnose the problem rather than unleashing USR's code revisions on our customers just to see if they work better. I thank the people from USR that contribute to this list, but I know that we would all appreciate some forthright information from USR/3Com without our having to beg and plead for it. --- Mark R. Lindsey, mark@datasys.net Network Engineer, DSS Online Voice: +1 912 241 0607; Fax: +1 912 241 0190

On Tue, 30 Sep 1997, Tim Buchalka wrote: > I totally agree - I am sick of trying to fend off the constant flames. We > have USR TC Hubs running 56K (5.5.7) quad modem cards. > > Any help guys would certainly be beneficial!!!! > > Tim > its not so bad as quake, but if its lagging quake, it must be lagging other udp based serviced. Brian > > ---------- > > From: Brian <signal@shreve.net> > > To: USRobotics TC Mailing List <usr-tc@xmission.com> > > Subject: (usr-tc) Quake Lag > > Date: Tuesday, September 30, 1997 7:53 AM > > > > Is there any new information on the Quake lag situation? > > > > Not a day goes by that I don't get flamed for the lag when users go into > > Quake via a USR TC hub. I'll try anything at this point......... > > > > Brian > > > > > > /-------------------------- signal@shreve.net > -----------------------------\ > > | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 > | > > | Systems Administrator | Perl, Linux | Web hosting, online stores, > | > > | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & > LANs | > > | 89 CRX, Akimoto intake, DC |-=*:Quake:*=-| http://www.shreve.net/ > | > > | headers, Eurosport exhaust |LordSignal/SN| Quake server: 208.206.76.3 > | > > \-------------------------- 318-222-2638 x109 > -----------------------------/ > > > > > /-------------------------- signal@shreve.net -----------------------------\ | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | | Systems Administrator | Perl, Linux | Web hosting, online stores, | | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | | 89 CRX, Akimoto intake, DC |-=*:Quake:*=-| http://www.shreve.net/ | | headers, Eurosport exhaust |LordSignal/SN| Quake server: 208.206.76.3 | \-------------------------- 318-222-2638 x109 -----------------------------/

On Mon, 29 Sep 1997, Tatai SV Krishnan wrote: > Brian, > > We have been working hard to find a solution to this quake problem. We > have seen this problem in our lab. We cannot succesfully reproduce this > problem as and when needed. Please let me know how we can reproduce the > problem, time and time again. Any help from you is greatly appriciated. > > krish krish, Wish I could tell you how. Our TC hubs take PRI lines in. The users that see the lag is most prominent in analog connections such as x2 and v34 users, but I have seen it in ISDN as well. All you have to do is run a Quake server, and dial-in thru the TC hub, you will see much better ping times NOT going thru the hub, and getting to the Quake server over the internet some other way. At times the lag starts to really rise, to over 1000 at times. To check your "ping" time in Quake, you want to goto the Quake "console" and type "ping"..........I am not sure if this is the same as a normal tcpip ping......... Brian > > ----------------------------------------- > \ T.S.V. Krishnan \ > \ Network System Engineer \ ( : - : ) > \ 3Com ............ \ > ----------------------------------------------/ > tkrishna@bubba.ae.usr.com > ----------------------------/ http://interproc.ae.usr.com ----/ > -------------------------------------------------------------------------\ > Any Sufficiently advanced bug is indistinguishable for a feature. > - Rick Kulawiec > -------------------------------------------------------------------------/ > > On Mon, 29 Sep 1997, Brian wrote: > > > Is there any new information on the Quake lag situation? > > > > Not a day goes by that I don't get flamed for the lag when users go into > > Quake via a USR TC hub. I'll try anything at this point......... > > > > Brian > > > > > > /-------------------------- signal@shreve.net -----------------------------\ > > | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | > > | Systems Administrator | Perl, Linux | Web hosting, online stores, | > > | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | > > | 89 CRX, Akimoto intake, DC |-=*:Quake:*=-| http://www.shreve.net/ | > > | headers, Eurosport exhaust |LordSignal/SN| Quake server: 208.206.76.3 | > > \-------------------------- 318-222-2638 x109 -----------------------------/ > > > > > > > /-------------------------- signal@shreve.net -----------------------------\ | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | | Systems Administrator | Perl, Linux | Web hosting, online stores, | | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | | 89 CRX, Akimoto intake, DC |-=*:Quake:*=-| http://www.shreve.net/ | | headers, Eurosport exhaust |LordSignal/SN| Quake server: 208.206.76.3 | \-------------------------- 318-222-2638 x109 -----------------------------/

> > >its not so bad as quake, but if its lagging quake, it must be lagging >other udp based serviced. > I believe that the problems that we are having with radius validations failing to go into ppp mode ( customer does get authenticated ) is due to the same issue since in our case ( not sure about others) but the validation is via udp transmissions. This is not repeatable on demand but is significant enough to cause us great grief. We have 4 fully loaded pri chassis and typically see it on remote pops that validate via a central radius server. Sometimes even the local server right next to the radius server has this problem although less frequently. Eric > Delaware Online!.........The SMART Choice! With 56K X2 Modems Phone : 302-762-0375 Fax: 302-762-3462 WWW: www.dol.net Eight out of five people have a problem understanding statistics! ****************Customer support is our bottom line!*********************

Pete, I'm not sure what I'm stating either.... Let me bend your ear some more. > > >Should b-channels avail = 46 or 23 or what? (only one > >PRI is used, the rest is analog). > > I'm not quite clear on what you're stating here. You have two PRIs or one? > How do the analog lines come in? Do you accept analog calls over your > PRIs? One PRI being served by modems in slots 2-7. Analog through NIC adapters in slots 8-13. 24 Line rollover. Second Hub is silent right now, but probably will be reserved for all analog until 56k demand increases to merit extra cost, meaning that I would like to keep the first unit partitioned for both a/d. Potentially stupid question.... How do I know if I have QBCH-I Modems vs. regular QBCH Modem, and is this important factor at all? My comment about Max-b channels is way off. That setting is to throttle the load on the Netserver I think. > >Any other ideas? Any reason why the telco would reject > >ISDN calls to a PRI? Other calls are OK. > > They may have provisioned it only to accept analog calls. Also, verify > that your switch type meshes with the switch that the telco is using. > My switch type (5ESS) matches. BellSouth tech said that ALL PRI's would accept both types of calls. Should I ask that question again? In stricter language? Any lingo I should know about when asking this of the telco. Thanks for the attention, Kent Tambling AccelerationNet

Dear Mark, > such fits. Is it weird bit patterns in the packets? Is it odd sequences, > or timing, or what? Quake uses UDP, for which I can find references which date back to the days of ARPAnet. Regards latency, here are my observations on the client side: a) Get a good 'phone line (no retrains, BLERs NAKs etc.) b) Don't run OpenGL. c) Make sure you're not getting CRC errors, overruns (as per the Matrox cards etc.) d) Maximise the playing screen. e) Change the vid_mode to one that gives ~25fps. I find 7 is the best. f) Do X2 if you can. g) Run QuakeWorld, not Quake, as the former solves a lot of the known issues with Internet play. There's also an init string which someone posted to netcom.uk.support.quake, which I've used and seems OK. I don't have a record of it here (I can post it tomorrow if people wish), but I remember it included the setting S33=32, which "enables a reduced packet size" according to the Courier manual. There was also a couple of "reserved" S registers in there which I'd like to know their function. I find with all these fixes, I rarely get POD (Ping Of Death), but it does happen occasionally. It's for these reasons that we regards Quake here as an unsupported service - in other words I'm more interested in making people's mail work than sorting out Quake. Many Regards, -- David Carter, 2nd Level Support, NETCOM Internet. david@corp.netcom.net.uk Cricket is basically baseball on Valium. Robin Williams.

Dear Mark, > such fits. Is it weird bit patterns in the packets? Is it odd sequences, > or timing, or what? Quake uses UDP, for which I can find references which date back to the days of ARPAnet. Regards latency, here are my observations on the client side: a) Get a good 'phone line (no retrains, BLERs NAKs etc.) b) Don't run OpenGL. c) Make sure you're not getting CRC errors, overruns (as per the Matrox cards etc.) d) Maximise the playing screen. e) Change the vid_mode to one that gives ~25fps. I find 7 is the best. f) Do X2 if you can. g) Run QuakeWorld, not Quake, as the former solves a lot of the known issues with Internet play. There's also an init string which someone posted to netcom.uk.support.quake, which I've used and seems OK. I don't have a record of it here (I can post it tomorrow if people wish), but I remember it included the setting S33=32, which "enables a reduced packet size" according to the Courier manual. There was also a couple of "reserved" S registers in there which I'd like to know their function. I find with all these fixes, I rarely get POD (Ping Of Death), but it does happen occasionally. It's for these reasons that we regards Quake here as an unsupported service - in other words I'm more interested in making people's mail work than sorting out Quake. Many Regards, -- David Carter, 2nd Level Support, NETCOM Internet. david@corp.netcom.net.uk Cricket is basically baseball on Valium. Robin Williams.

Hi All, Can anyone tell me a way, via TCM, to change the configuration of the chassis (as seen by the PRI card)? So far the only way I've found to do it is via a serial cable plugged into the console port of the PRI card. I'm in the position of having half analogue, and half digital racks. As I cut cards over I need to tell the PRI card that they're there, and then set their line interface to priTdm. The second bit is no problem... Any ideas? Regards, Bob Purdon, Southern Internet.

I totally agree - I am sick of trying to fend off the constant flames. We have USR TC Hubs running 56K (5.5.7) quad modem cards. Any help guys would certainly be beneficial!!!! Tim

For details about how to keep your modem from retraining and causing trouble, we wrote a help page for our subscribers that may be useful to some of you: http://www.xmission.com/help/faqs/quake_modems.html As long as you have upgraded to 3.5.93, the above page has useful instructions that have proven very useful for our subscribers and can likely have the same results for yours. Generally, if you use an &N setting to limit your connections speed to one or two clicks below your average connection rate, then you should have a good and dependable connection for Quake. Problems after the upgrade seem to stem from pauses caused by the modem retraining--x2 esp. On Mon, 29 Sep 1997, Pete Ashdown wrote: > Jeff Mcadams said once upon a time: > > > >Thus spake Brian > >>Is there any new information on the Quake lag situation? > > > >>Not a day goes by that I don't get flamed for the lag when users go into > >>Quake via a USR TC hub. I'll try anything at this point......... > > > >Have you tried 3.5.93 yet? Supposedly fixes it (no, I haven't gotten > >it, but should be fairly soon now). > > I would emphasize that you have to get your retrains down to 0 (checkable > via ATI6). This is done by lowering the maximum connect rate with &N. > Retrains were the most common cause of 999 pings we've found here. > > > > Grant ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ "When ugliness, poor design & stupid waste are forced upon you, turn Luddite, throw your shoe in the works, retaliate. Smash the symbols of the Empire in the name of nothing but the heart's longing for grace." --Hakim Bey ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

On Mon, Sep 29, 1997 at 09:33:55PM -0500, Brian wrote: > On Mon, 29 Sep 1997, Tatai SV Krishnan wrote: > > Brian, > > We have been working hard to find a solution to this quake problem. We > > have seen this problem in our lab. We cannot succesfully reproduce this > > problem as and when needed. Please let me know how we can reproduce the > > problem, time and time again. Any help from you is greatly appriciated. > > krish > krish, > Wish I could tell you how. Our TC hubs take PRI lines in. The users that > see the lag is most prominent in analog connections such as x2 and v34 > users, but I have seen it in ISDN as well. All you have to do is run a > Quake server, and dial-in thru the TC hub, you will see much better ping > times NOT going thru the hub, and getting to the Quake server over the > internet some other way. At times the lag starts to really rise, to over > 1000 at times. > To check your "ping" time in Quake, you want to goto the Quake "console" > and type "ping"..........I am not sure if this is the same as a normal > tcpip ping......... > Brian If users going through a TC hub complain about bad Quake pingtimes, tell them to turn off *all* forms of data compression on their connection (esp. if they're using an X2 modem). We have found that this fixed the problem. Bill -- Bill Bradford Senior Systems Engineer, BOFH mrbill@texas.net Texas Networking, Inc. ICQ: 1864511 http://www.texas.net Catapultam habeo. Nisi pecuniam omnem mihi dabis, ad caput tuum saxum immane mittam.

Hello *, I setup a little bbs for x2 testing in my country. It's simple Linux box running a perl script and 'sz' for sedning files using zmodem. Everything works if I use multiport card and couples of TC quads. So I setup the netserver (Netserver-I/8 3.2.5.3) that it rlogins to the unix as user 'x2demo'. It works, but when it comes to zmodem download, the transfer simply freeze. It can push 100-200kB and then it stops while the modem connection is okay. Thus it's quite impossible to download a file of size 1.5MB I was also trying to use Netdata (tcp 6000) but it was the same. I did some outputs from tcpdump. This is when the transfer has stopped: 10:00:57.730934 cher.unicom.cz.6000 > netserv.unicom.cz.1031: . 157933:158469(536) ack 69 win 31744 10:00:57.730934 netserv.unicom.cz.1031 > cher.unicom.cz.6000: . ack 157933 win 1440ck 69 win 31744 10:00:57.730934 cher.unicom.cz.6000 > netserv.unicom.cz.1031: . 158469:159005(536) ack 69 win 31744 10:00:57.730934 netserv.unicom.cz.1031 > cher.unicom.cz.6000: . ack 158469 win 904 10:00:57.730934 netserv.unicom.cz.1031 > cher.unicom.cz.6000: . ack 159005 win 368 10:00:58.120867 cher.unicom.cz.6000 > netserv.unicom.cz.1031: . ack 69 win 31744 10:00:58.920731 cher.unicom.cz.6000 > netserv.unicom.cz.1031: . ack 69 win 31744 10:01:00.520459 cher.unicom.cz.6000 > netserv.unicom.cz.1031: . ack 69 win 31744 10:01:03.719914 cher.unicom.cz.6000 > netserv.unicom.cz.1031: . ack 69 win 31744 10:01:10.118825 cher.unicom.cz.6000 > netserv.unicom.cz.1031: . ack 69 win 31744 10:01:21.176944 netserv.unicom.cz.1031 > cher.unicom.cz.6000: P 69:90(21) ack 159005 win 368 10:01:21.196940 cher.unicom.cz.6000 > netserv.unicom.cz.1031: . ack 90 win 31744 (DF) 10:01:23.376569 netserv.unicom.cz.1011 > cher.unicom.cz.1642: S 127:127(0) win 4096 10:01:23.376569 cher.unicom.cz.1642 > netserv.unicom.cz.1011: R 0:0(0) ack 1 win 0 (huh, still would like to know what the hell is that connection attempt to tcp port 1642) Anyone experienced this problem? Kamil Kukura U N I C O M (authorized distributor of U.S.Robotics) Usti nad Labem, Czech Republic

Garry Shtern said once upon a time: >Where do you get that version? USR is not really anxious to give out >anything to their customers but the released code.. Call the support line and beg, plead, steal, or borrow to get 3.5.93. I told them I was affected by the Quake bug mentioned on their website, when the support technician asked me what I was talking about, I had to give them step by step instructions on finding the problem report.

Garry Shtern said once upon a time: > >Guys, do tcs support digital over voice ISDN connections? If not, what >exactly are 56k connections? They don't support it yet, although I can't seem to get a clear answer as to what the extra-cost-feature "ISDN Modem" does. 56k connections for us are generally caused by trunking not being clear-channel somewhere between us and the ISDN customer. Sometimes this varies due to our provider (ELI) botching their interconnect with US West.

Brian said once upon a time: >> I would emphasize that you have to get your retrains down to 0 (checkable >> via ATI6). This is done by lowering the maximum connect rate with &N. >> Retrains were the most common cause of 999 pings we've found here. >> > >So this is on the client side, as per client right? I mean when I dial >into a multi port serial board with sportsters hanging off it, or a >portmaster, I have no problems, its almost like tc hub >related.............. Yes, but are you hitting X2 on the TC where you aren't on the Sportsters? I'd still take a look at your ATI6 output on each connection.

Brian Elfert said once upon a time: >On Tue, 30 Sep 1997, Pete Ashdown wrote: > >> They don't support it yet, although I can't seem to get a clear answer as >> to what the extra-cost-feature "ISDN Modem" does. > >The ISDN modem feature is now included at no extra charge since the latest >modem code came out this summer. > >It moves ISDN processing from the Netserver daughtercards onto the modem >DSPs. So, how can I use this ISDN processing to accept 56K ISDN calls over DSS? Is there any benefit to moving the ISDN processing if I have a PRI card?

Brian said once upon a time: >> g) Run QuakeWorld, not Quake, as the former solves a lot of the known >> issues with Internet play. > >True, but everyone like quake on our server. Also, Quake should not lag >at ALL. Untrue Brian. Carmack himself confessed that he wrote the original Quake networking code based on his own T1 connection. It just didn't occur to him that people might be using modems out there (and not driving Ferrari's, I'd guess as well). Quakeworld makes up for those problems in the original code.

In trying to setup our RADIUS server correctly we have run into a slight problem. If we try using the Radius users file no password is necc. to authenticate. When using the UNIX password file we get a error in the logs: Acct-Terminate-Cause = NAS-Error And user does not log in. The only difference we can see between the two methods is that " Filter-Id = u" appears in the logs when using the UNIX password lists. I have created a filter with no rules for IP only called u, this does not seem to help. Any ideas? Terry Kennedy Olypen, Inc. terry@olypen.com 360 683-1172 360 452-9755

On Tue, 30 Sep 1997, Pete Ashdown wrote: > They don't support it yet, although I can't seem to get a clear answer as > to what the extra-cost-feature "ISDN Modem" does. The ISDN modem feature is now included at no extra charge since the latest modem code came out this summer. It moves ISDN processing from the Netserver daughtercards onto the modem DSPs. Brian

> e) Change the vid_mode to one that gives ~25fps. I find 7 is the best. How do you check your fps in quake? > f) Do X2 if you can. We have found x2 HURTS quake for us. Most of our v34 users can get 28.8k transmit and 28.8k receive v34. On x2, its more like 21-26k transmit and 43-48k receive. Quake is more transmit intensive than receive, so this hurts game play............watch the modem lights and count the packets, alot more xmit than rcv. > g) Run QuakeWorld, not Quake, as the former solves a lot of the known > issues with Internet play. True, but everyone like quake on our server. Also, Quake should not lag at ALL. And we arent really talking about things the client can do.......assuming the client is setup correctly, the USR hub still totally screws everything up.............dialing in at at least 28.8k to a Quake server on a good lan, should be fine for up to 16players...... > > There's also an init string which someone posted to > netcom.uk.support.quake, which I've used and seems OK. I don't have a > record of it here (I can post it tomorrow if people wish), but I remember > it included the setting S33=32, which "enables a reduced packet size" > according to the Courier manual. There was also a couple of "reserved" S > registers in there which I'd like to know their function. turning off software compression, and error correction would help, a little............also reducing the mtu to about 296 or so would help since Quake uses lots of small packets.......... > > I find with all these fixes, I rarely get POD (Ping Of Death), but it > does happen occasionally. It's for these reasons that we regards Quake > here as an unsupported service - in other words I'm more interested in > making people's mail work than sorting out Quake. > > Many Regards, > -- > David Carter, 2nd Level Support, NETCOM Internet. > david@corp.netcom.net.uk > Cricket is basically baseball on Valium. Robin Williams. > > > /-------------------------- signal@shreve.net -----------------------------\ | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | | Systems Administrator | Perl, Linux | Web hosting, online stores, | | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | | 89 CRX, Akimoto intake, DC |-=*:Quake:*=-| http://www.shreve.net/ | | headers, Eurosport exhaust |LordSignal/SN| Quake server: 208.206.76.3 | \-------------------------- 318-222-2638 x109 -----------------------------/

> e) Change the vid_mode to one that gives ~25fps. I find 7 is the best. How do you check your fps in quake? > f) Do X2 if you can. We have found x2 HURTS quake for us. Most of our v34 users can get 28.8k transmit and 28.8k receive v34. On x2, its more like 21-26k transmit and 43-48k receive. Quake is more transmit intensive than receive, so this hurts game play............watch the modem lights and count the packets, alot more xmit than rcv. > g) Run QuakeWorld, not Quake, as the former solves a lot of the known > issues with Internet play. True, but everyone like quake on our server. Also, Quake should not lag at ALL. And we arent really talking about things the client can do.......assuming the client is setup correctly, the USR hub still totally screws everything up.............dialing in at at least 28.8k to a Quake server on a good lan, should be fine for up to 16players...... > > There's also an init string which someone posted to > netcom.uk.support.quake, which I've used and seems OK. I don't have a > record of it here (I can post it tomorrow if people wish), but I remember > it included the setting S33=32, which "enables a reduced packet size" > according to the Courier manual. There was also a couple of "reserved" S > registers in there which I'd like to know their function. turning off software compression, and error correction would help, a little............also reducing the mtu to about 296 or so would help since Quake uses lots of small packets.......... > > I find with all these fixes, I rarely get POD (Ping Of Death), but it > does happen occasionally. It's for these reasons that we regards Quake > here as an unsupported service - in other words I'm more interested in > making people's mail work than sorting out Quake. > > Many Regards, > -- > David Carter, 2nd Level Support, NETCOM Internet. > david@corp.netcom.net.uk > Cricket is basically baseball on Valium. Robin Williams. > > > /-------------------------- signal@shreve.net -----------------------------\ | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | | Systems Administrator | Perl, Linux | Web hosting, online stores, | | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | | 89 CRX, Akimoto intake, DC |-=*:Quake:*=-| http://www.shreve.net/ | | headers, Eurosport exhaust |LordSignal/SN| Quake server: 208.206.76.3 | \-------------------------- 318-222-2638 x109 -----------------------------/

Brian said once upon a time: >Can you modify Quakeworld just like Quake, so that people can have there >homing missles, voting, ctf, etc? Yup. It comes with QuakeC source. Some of the cooler things like Painkeep, CTF, and other mods are Quakeworld only.

On Tue, 30 Sep 1997, Pete Ashdown wrote: > Brian said once upon a time: > > >> g) Run QuakeWorld, not Quake, as the former solves a lot of the known > >> issues with Internet play. > > > >True, but everyone like quake on our server. Also, Quake should not lag > >at ALL. > > Untrue Brian. Carmack himself confessed that he wrote the original Quake > networking code based on his own T1 connection. It just didn't occur to > him that people might be using modems out there (and not driving Ferrari's, > I'd guess as well). > > Quakeworld makes up for those problems in the original code. > Can you modify Quakeworld just like Quake, so that people can have there homing missles, voting, ctf, etc? Brian /-------------------------- signal@shreve.net -----------------------------\ | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | | Systems Administrator | Perl, Linux | Web hosting, online stores, | | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | | 89 CRX, Akimoto intake, DC |-=*:Quake:*=-| http://www.shreve.net/ | | headers, Eurosport exhaust |LordSignal/SN| Quake server: 208.206.76.3 | \-------------------------- 318-222-2638 x109 -----------------------------/

At 04:22 PM 9/30/97 -0500, Brian Elfert wrote: > > >On Tue, 30 Sep 1997, Pete Ashdown wrote: > >> They don't support it yet, although I can't seem to get a clear answer as >> to what the extra-cost-feature "ISDN Modem" does. > >The ISDN modem feature is now included at no extra charge since the latest >modem code came out this summer. > >It moves ISDN processing from the Netserver daughtercards onto the modem >DSPs. > >Brian > Does it include Digital over voice support? Garry Shtern shterng@akula.com Chief Network Administrator http://www.akula.com Akula Communications Corp. tel. (212) 292-8892

On Tue, 30 Sep 1997, Brian wrote: > > > e) Change the vid_mode to one that gives ~25fps. I find 7 is the best. > > How do you check your fps in quake? Hit ~ to bring up the console, and type 'timerefresh'. When comparing two different systems its best to start them on the same level and initiate the `timerefresh` right at the beginning, this way the position will be precisely the same. The closer you are to walls etc, less complexity in the room, the higher the fps will be from that position. > > f) Do X2 if you can. > > We have found x2 HURTS quake for us. Most of our v34 users can get 28.8k > transmit and 28.8k receive v34. On x2, its more like 21-26k > transmit and 43-48k receive. Quake is more transmit intensive than > receive, so this hurts game play............watch the modem lights and > count the packets, alot more xmit than rcv. Are you sure you dont have this mixed up? I would imagine the transmit (from the clients point of view) would require less data than the receive because in a room with say 5 players and rockets flying everywhere, you should be receiving much more data than the single instance of information you are sending back to the server (to be propagated to others) for your current position, etc. So I would think the x2 down channel could only help in this regard, assuming its locked into one speed and doesn't start retraining on you. > > g) Run QuakeWorld, not Quake, as the former solves a lot of the known > > issues with Internet play. > > True, but everyone like quake on our server. Also, Quake should not lag > at ALL. And we arent really talking about things the client can > do.......assuming the client is setup correctly, the USR hub still totally > screws everything up.............dialing in at at least 28.8k to a Quake > server on a good lan, should be fine for up to 16players...... > As others have already mentioned, Quake does lag much more.. in fact I've found some Quake sites on the net to be a little choppy even at 100ms latency (anything less than 70ms or so is much better.. i prefer something around 25ms or less if you can find them) over a T1. QuakeWorld sites on the otherhand, the latency can go up much higher and its still smooth. And dont forget the push_latency console command introduced in QuakeWorld, which creates a noticable improvement once the pings are up to the ~500ms range. - lv