June 1999

356 messages

« May 1999July 1999 »

Messages

Subject: Re: (usr-tc) HiPerARC CLI documentation
From: steve_batsford@ne.3com.com
Date: 1999-05-27 14:17:41
To get the latest released version of the HiPer ARC doc, go to totalservice.usr.com in your web browser. >From the Total Service home page click on "Documentation Library" Select "All" under Documentation Types. Select "Total Control Hubs: HiPer ARC" under Limit Search. Click on the "Start Search" button. It looks like there are two docs you will want to have the latest released information. They are "ARCREF10.PDF" and "arcref10ad.pdf". These are Adobe Acrobat PDF files. If you don't have the PDF reader there is a link on the Total Service page that will let you get it. It's free! Chapter 10 of the ARCREF10.PDF file has a listing of all the commands, their syntax, and parameters. Hope this helps. Steve Batsford Sent by: Jim Curran - GCSO / CSD / CSO Carrier Technical Communication, Rolling Meadows cc: Steve, do you monitor this forum? Thought you might be able to help these guys. Jim ---------------------- Forwarded by Jim Curran/MW/US/3Com on 05/27/99 09:50 AM --------------------------- Marcelo Souza <mpsouza@centroin.com.br> on 05/26/99 04:04:59 PM Please respond to usr-tc@lists.xmission.com Sent by: Marcelo Souza <mpsouza@centroin.com.br> cc: (Jim Curran/MW/US/3Com) On Tue, 25 May 1999, matthews wrote: | |Is there a file anywhere that completely documents all the ARC CLI |commands? I've been all over totalservice and I found the various release |notes documenting new features and (sometimes) what they do, but I didn't |see a full CLI reference anywhere with ALL available features. I may have |missed something though... The nearest doc I could found was: harc41user.pdf Download it from totalservice.usr.com. If you could find any other more up-to-date, please let me know. - Marcelo - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.
Subject: Re: (usr-tc) NO Phone support?
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1999-05-28 10:36:39
Well...some agreement...some disagreement... Thus spake ISPCnsl001@aol.com >Time to get on my soap box: Solunet does have some good people working >for them, but tech support isn't really meant to be used for hand >holding. You are authorized to call in to 3COM's when you are still >under warranty for any legitimate problems. Hah...just try it! If you don't have a support contract, they'll transfer you to logistics to buy a support contract...period. >After the warranty period is expired you should be beyond hand holding >and ready to move on to tougher issues. I'll agree with this...the "should be" part...but unfortunately, real life rears its ugly head. >The true value of 3COM's tech support comes into play when you need >help beyond initial setup. Heh...now this is almost funny. 3Com tech support, for the most part, has been almost useless for any but the most basic of questions. I can't even report a bug to them through normal channels because they won't talk to me because I don't have a support contract. You'd think that tech support would be interested in hearing about a bug in their software whether the person reporting it has a support contract or not. Instead, I had to get the information to Mike Wronski and Tatai Krishnan via this list (who handled it quite well, a pleasant difference from calling in to tech support). >As with any organization, you may not always get the most senior >technician when you call, but the resources at your disposal at 3COM >are immense. *If* you can get to them...that's the huge problem here...getting past the first person that answers the phone and wants access to log into your box directly is an absolute nightmare...made even more frustrating because, at least for people on this list by and large, we know more than the first level folks do about this equipment! >I have been able to get answers to literally thousands of very high >level off the wall questions over the years. All you have to do is >ask. If the person you are talking to doesn't know the answer ask >him/her to ask a team leader or a product specialist in the next level. >It's that easy. Hah...I wish...I've point blank asked to be transferred to second level tech support and been refused...maybe they're getting better with this...but I haven't seen any evidence of it yet. >Some people don't need access to these resources and that's fine. If >all you are doing with your equipment is a basic default setup then you >probably don't need it either. However, more and more customers want >their equipment to do a number of things that the default configuration >doesn't provide or that, perhaps, a feature does not exist for. However, these people, are typically the people that are willing to dig in and really learn the equipment inside and out...and 3Com really does a pitiful job of giving people like this support. I've found that 3Com provides the best support for people that want their equipment just to work, and don't care to know how to set it up to get it to work....this dovetails very nicely with 3Com's first level tech support, who invariably seems to want to log into your box themselves and do the work themselves without telling you what they are doing. >Once a new product is established and stable 3COM usually responds very >quickly to feature requests that make sense. OSPF on the NETServer card...'nuff said. >Solunet, or anyone else for that matter, cannot compete with the kind >of experience 3COM has, as a whole; talking to thousands of new and >existing customers each month. But the problem is....3Com has the possibility, but they don't seem to learn from it! >Anyone else would have to be at least a little behind the power curve >on existing issues, new features, emerging technologies that will be >supported, etc. Yeah...and 3Com's first and maybe second level tech support seems to be too! :) I recently had a private email exchange with a 3Com tech support dude that started in the totalservice newsgroup fora. I'll include the last message of that below...this is the message where I expound on my thoughts about 3Com's tech support. The origination of this thread was someone in the newsgroup asking about how to do a software download to the cards from a unix command line...the tech responded with information about pcsdl and tcm, and that was it. I responded with more information with a bit of an attitude (gee...I bet that surprises regular readers of this list :), and he responded asking why I was so down on 3Com. :) My response follows: >unless you want to right specific code on HPOV or similar gui to match >the mibs of the nmc's send request for the sdl and nac files -- then >tcm is the way to go -- thanks for the over clarification jeff -- Except for the fact that the guy was specifically asking about command line, not GUI, :) and it can be done on the command line...not *quite* as simply as he was thinking it was, but not too terribly more difficult either. :) >you may have noticed that I also included the sdl version .... True...and that certainly is good information...though I can't remember the last time I did an sdl to a quad...a lot of the people that I talk to don't even have quad nic's to do sdl's with. We keep a few around just for this reason, but have never had a reason to need to do it. >I do respect your opinions , and you are certainly a valuable asset to >this forum -- I sometimes feel that you look for ways to disvalue >anything that comes from 3com - why split hairs on the gui? I guess I do kind of look for ways to disvalue things from 3Com...maybe a little. I think, mainly, that I'm frustrated with 3Com. Let me see if I can explain where I'm coming from here. I see about 3 different levels of TC users. First, you have what I call "cluebies" :) (I'm gonna stereotype here big time...be forewarned...these are generalizations) This is typically gonna be a guy with one rack, running an ISP out of his basement. :) He runs S&A on an NT box, has never seen Unix, and thinks running an ISP is a turnkey thing. :) This type of person doesn't want to learn about the equipment he uses...he wants to turn it on and have it just work. Of course, you and I both know that this just isn't gonna happen. Second, you have the group of people that I think I would place myself in. People that are curious, want to learn the inner workings of the equipment and how to make use of it to its fullest. These types of people are going to learn the intricate ins and outs of the TC equipment with 3Com's help or not. :) They typically run Unix, and would cringe to sit down at a computer with any software from MS on it. :) Third, you have a group of people that fall somewhere in the middle of the previous two. These are people that aren't inately curious about the equipment, but realize they need to learn some of the details in order to run it well. These people will use either NT or Unix, but won't use either of them to their full potential. :) 3Com does a pretty good job of giving support for the first group of people. When they call tech support, they're more than willing to let the tech support person log into their box and do the work and not worry about what they're doing. You do an OK job of supporting the second group. The programming manual and stuff is out there that we can pour through to get the information we need to learn what we want. It'd be *nice* to have some better support avenues from 3Com, but we can make due with what's there. The last group is where I think 3Com really drops the ball. This is the group that, if 3Com were to put a bit of effort into it, could be taught enough about using the equipment that they could be self-supporting (like the group that I'm in) in a bit of time. Short-term, it may be a bit more expensive for 3Com to provide them this support...but long-term your support costs for these people is going to be much lower. Once they learn the ins and outs of the equipment, they'll be pretty much self-supporting and won't tie up your tech support folks. I guess you could take this point and generalize it even further...3Com seems to always look at what's the best answer to things in the short-term. They never seem to look at the long(er)-term. To pick out another couple of examples here. Continuing to charge for x2 enable keys, for example, short-term, its a win because you get the revenue from people buying the enable keys...long-term, you loose because you're ticking off your customers even more and they're deciding to switch to new vendors of equipment (Lucent commonly) because of this. Another example, support contracts. 3Com's support contract rules are insane...they seem designed to get the greatest revenue from the support contracts, even if it means ticking off your customers, again, short-term, 3Com gets more revenue, long-term you loose it because people start refusing to get support contracts at all (we don't have one because 3Com was gouging us on them IMHO) and start talking about pirating the code (witness some of the discussion wrt TCS 3.5) to get around not having access on the web site. The other long-term loss for 3Com in these examples is the bad publicity that 3Com gets from this. Your customers feel like they're getting screwed over, and they really are, so they let people know about it. This is probably part of the reason that 3Com's stock price is at about the same place it was over 3 years ago, honestly. Anyway...I, honestly, don't have a great deal of respect for 3Com corporately at the moment...there are certainly individuals that work for 3Com that I have respect for...Mike Wronski and Tatai Krishnan are definitely both very sharp techs that I deal with regularly on usr-tc...Tom Goodman is our sales rep, and he's definitely on the ball. But, overall, 3Com doesn't seem to be dealing with its customers very well. Please don't take this as a personal insult...its certainly not meant that way. You thanked me for my "over clarification", but my thought is that your answer didn't go far enough. The guy was asking about command line methods of doing modem upgrades, and, to be honest, your answer didn't touch on that at all. Another thought just occured to me that's at least tangential to these issues. There are a *ton* of tools out there written by third parties to assist in managing TC racks. As an example...Mike Andrews (from dcr.net...he's on the usr-tc list as well) has a whole list of perl scripts that he's written that basically mimic various functions of TCM...completely perl, and run on command lines. http://www.dcr.net/~mandrews/usrtoys/mystuff.shtml It would be *really* cool if 3Com could start really giving some support to people doing stuff like this. Even just having a contrib software area on totalservice would be great. Some of this stuff is *really* good. [snip a bit that needs to remain private] Anyway...I've babbled long enough. :) To summarize, 3Com is good at supporting "cluebies". I think they need to start better supporting the people that are really willing and even eager to really dig into the TC stuff and their their way around it really well. Long-term, this would be a win for 3Com as it would lower support costs, improve 3Com's image...particularly among the more knowledgeable people about this type of equipment, and make the overall tone of 3Com's public tech support fora (both the totalservice newsgroups/mailing lists, and non-3Com run groups like usr-tc) much more positive. :) -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456
Subject: (usr-tc) Mp/16 and Digi board concentrator -Problem _ with Modem Pool 1
From: "shimatsu, fernando p. btb tky"
Date: 1999-06-01 02:22:33
This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01BEAC10.F7AFCB60 Content-Type: text/plain; charset="iso-8859-1" I am setting up a Ras server NT4 with a digi board CX c/con16 concentrator and a modem pool USR MP16 . I need to connect the Modem pool RJ45 RS 232 connectors to each of the ports at the digi board(also rj45) The MP16 connectors are 10 pins and the digi board C/con 16 are 8 pins. This lines are not compatible so I think I need to do some changes . Does someone have tried to do this before? -0-------------- I had spent very long time looking for support for my USR MP /16 and try to connect to a COncentrator card ( DIgi Co)..I think for almost a 1 year ago we bought these 2 devices.......... I hope you can help me out how to configure these ....... basically I got a recommendation from the Digi board company that I need to setup a register entry in the MP/16 .. s58=1 this will make the pins to be "swap" this will mean the RI <---> DSR have to be switch by software .......... for your information to be more clear I am also sending a paint brush file so you can see very clear what I am tryin to do . ALso some screen shots of the Total control manager lit 4.2 that I am using for access............. I would like any help ..... The only I think I got after made the custom cable ....and setup the register .. is the incoming line dials up and hangs up after the first ring.... weird ........... I always get the same situation no matter what i tried to setup in my Ras server..... I think the MP16 is not allowing the initial handshake ...... I fyoucan take a look at the follow attachments..maybe someone outhere can help me.... ok... thanks ------_=_NextPart_000_01BEAC10.F7AFCB60 Content-Type: text/plain; name="digicable.txt" Content-Disposition: attachment; filename="digicable.txt" Content-Location: ATT-0-E5FB5CE8EE17D311909100805F15BDC8-D IGICA%7E1.TXT US Robotics MP/X Digi RJ45 10-pin US Robotics RJ45 8-pin DSR (2) - - - - - - - - - - - - - - - - - - - (1) RI RTS (3) - - - - - - - - - - - - - - - - - - - (8) RTS GND (4) - - - - - - - - - - - - - - - - - - - No Pin TxD (5) - - - - - - - - - - - - - - - - - - - (6) TxD RxD (6) - - - - - - - - - - - - - - - - - - - (5) RxD SG (7) - - - - - - - - - - - - - - - - - - - (4) SG CTS (8) - - - - - - - - - - - - - - - - - - - (7) CTS DTR (9) - - - - - - - - - - - - - - - - - - - (3) DTR DCD (10) - - - - - - - - - - - - - - - - - - - (2) DCD Having made the cables following the above pin out you must have the S58=1 command saved into NVRAM. The modem will interpret the RI line on the modem as the DSR signal. If you have questions concerning this, please contact US Robotics. Digi DB25 US Robotics RJ45 8-pin TxD (2) - - - - - - - - - - - - - - - - - - - (6) TxD RxD (3) - - - - - - - - - - - - - - - - - - - (5) RxD RTS (4) - - - - - - - - - - - - - - - - - - - (8) RTS CTS (5) - - - - - - - - - - - - - - - - - - - (7) CTS DSR (6) - - - - - - - - - - - - - - - - - - - (1) RI SG (7) - - - - - - - - - - - - - - - - - - - (4) SG DCD (8) - - - - - - - - - - - - - - - - - - - (2) DCD DTR (20) - - - - - - - - - - - - - - - - - - - (3) DTR Having made the cables following the above pin out you must have the S58=1 command saved into NVRAM. This will enable RI to be switched to DSR. If you have questions concerning this, please contact US Robotics. ------_=_NextPart_000_01BEAC10.F7AFCB60 Content-Type: image/bmp; name="MP16 SERVER.bmp" Content-Disposition: attachment; filename="MP16 SERVER.bmp" Content-Location: ATT-1-E8FB5CE8EE17D311909100805F15BDC8-M P16SE%7E1.BMP Content-Transfer-Encoding: base64 Qk3WYgIAAAAAAHYAAAAoAAAAWwIAAAICAAABAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA//// AAAA/wDHx8cAh4eHANcAVwAA/wAA/wAAAAAAAACAgIAAkpKSAKSkpAC2trYAyMjIANvb2wDt7e0A ////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAH//8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB3d3d3d3d3d3cAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB///AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB3d3d3d3d3d3AAAAAAAAAAAA d3d3d3d3d3dwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAf//wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHd3 d3AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB3d3dwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAH//8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAd3cAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB3dwAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB///AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHd3dwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAB3d3dwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAf//wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB3d3cAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB3d3cAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAH//8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAHd3AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAd3cAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB///AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAd3cAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAd3AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAf//wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB3dwAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHd3AAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAH//8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAd3AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAHdwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB///AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAHdwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB3cAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAf//wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHcAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAdwAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAH/wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB3cA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAB3cAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB///AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAHd3AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAd3cAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAf//wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB3cAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAd3AAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAH//8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB3AAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAHcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB///AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAB3AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAdwAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAf//wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAd3AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB3 cAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAH//8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAdwAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAdwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB///AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAdwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB3AAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAf//wAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAH//8AAAAAAAAAAAAAAAAAAAAAAAAAAAB3AAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAHcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB///AAAAAAAAAAAAAAAAAAAA AAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAf//wAAAAAAAAAAAAAAAAAAAAAAAAAHcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAdwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAH//8AAAAAAAAAAAAAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB///AAAAAAAAAAAAAAAAAAAA AAAABwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB3AAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAf//wAAAAAAAAAAAAAAAAAAAAAAB3AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAH//8AAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB///AAAAAAAAAAAAAAAAAAAA AAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAf//wAAAAAAAAAAAAAAAAAAAAdwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAdwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAH//8AAAAAAAAAAAAAAAAAAAdwAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB///AAAAAAAAAAAAAAAAAABw AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAf//wAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAABwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAH//8AAAAAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB3AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB///AAAAAAAAAAAAAAAABwAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAf//wAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAH//8AAAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB///AAAAAAAAAAAAAABwAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAf//wAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAH//8AAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB///AAAAAAAAAAAABwAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAf//wAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAABwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAH//8AAAAAAAAAAABwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB///AAAAAAAAAAAHAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAf//wAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAH//8AAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB///AAAAAAAAAAcAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAf//wAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAH//8AAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB///AAAAAAAABwAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABw AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAf//wAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAH//8AAAAAAABwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB///AAAAAAAAcAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAd3d3cAcAcAAAAHAHd3 d3dwAAd3dwAABwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA cAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAf//wAAAAAABwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAHAAAAAHAHAAAAdwBwAAAAAABwAABwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAH//8AAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAABwBwAABwcAcAAAAAAHAAAABwAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB///AAAAAAAHAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAAAAcAcAAAcHAHAA AAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA cAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAf//wAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAHAAAAAHAHAABwBwBwAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAH//8AAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAABwBwAHAAcAcAAAAAAAAAB3cAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB///AAAAAABwAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAAAAcAcABwAHAHd3 d3cAAAd3AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA BwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAf//wAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAHAAAAAHAHAHAABwBwAAAAAABwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAH//8AAAAABwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAABwBwcAAAcAcAAAAAAHAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB///AAAAAAcAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAAAAcAcHAAAHAHAA AAAABwAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAf//wAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAHAAAAAHAHcAAABwBwAAAAAABwAABwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAH//8AAAAABwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAABwBwAAAAcAd3d3d3AAB3d3AAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB///AAAAAAcAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAf//wAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAH//8AAAAABwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB///AAAAAAcAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAf//wAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAH//8AAAAABwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB///AAAAAAcAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAf//wAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAH//8AAAAABwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAAAH AAAHAAAAAHAAAAAAcAAAAAAAB3d3AAB3d3dwAAd3d3cAcAAAd3dwAAAABwAAAAAAcAAAAHAAAHd3 AAAHAAAABwB3d3d3cAAHd3cAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB///AAAAAAcAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAHAAAAdwAABwAAAABwAAAAAHAAAAAAAHAAAHAAcAAABwAHAAAAAHAABwAA BwAAAAcAAAAAAHAAAABwAAcAAHAABwAAAHcAcAAAAAAAcAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAA AHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAf//wAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAABwcAAAcAAAAAcAAAAABwAAAAAAcA AAAHAHAAAABwBwAAAABwAHAAAABwAAAHAAAAAABwAAAAcABwAAAHAAcAAAcHAHAAAAAABwAAAAcA AAAAAAAAAAAAAAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAH//8AAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAAcH AAAHAAAAAHAAAAAAcAAAAAAHAAAABwBwAAAAcAcAAAAAcAcAAAAAAAAABwAAAAAAcAAAAHAHAAAA AHAHAAAHBwBwAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB///AAAAAABwAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAHAABwBwAABwAAAABwAAAAAHAAAAAABwAAAAcAcAAAAHAHAAAAAHAHAAAA AAAAAAcAAAAAAHAAAABwBwAAAABwBwAAcAcAcAAAAAAAAAAABwAAAAAAAAAAAAAAAAAAAAAAAAAA BwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAf//wAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAHAAcAAAcAAAAAcAAAAAB3d3dwAAcA AAAHAHAAAAcABwAAAABwBwAAAAAAAAAHd3d3AABwAAAAcAcAAAAAcAcABwAHAHAAAAAAAAAAd3AA AAAAAAAAAAAAAAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAH//8AAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcABwAH AAAHAAAAAHAAAAAAcAAABwAHAAAABwB3d3dwAAcAAAAAcAcAAAAAAAAABwAAAHAAd3d3d3AHAAAA AHAHAAcABwB3d3d3AAAHdwAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB///AAAAAAAHAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAHAHAABwAABwAAAABwAAAAAHAAAABwBwAAAAcAcAAABwAHAAAAAHAHAAAA AAAAAAcAAAAHAHAAAABwBwAAAABwBwBwAAcAcAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA cAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAf//wAAAAAABwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwcAAAcAAAcAAAAAcAAAAABwAAAAcAcA AAAHAHAAAABwBwAAAABwBwAAAAAAAAAHAAAABwBwAAAAcAcAAAAAcAcHAAAHAHAAAAAABwAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAH//8AAAAAAABwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcHAAAH AAAHAAAAAHAAAAAAcAAAAHAHAAAABwBwAAAAcAcAAAAAcABwAAAAcAAABwAAAAcAcAAAAHAAcAAA BwAHBwAABwBwAAAAAAcAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB///AAAAAAAAcAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAHcAAABwAABwAAAABwAAAAAHAAAAcABwAAAAcAcAAABwAHAAAAAHAABwAA BwAAAAcAAABwAHAAAABwAAcAAHAAB3AAAAcAcAAAAAAAcAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAH AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAf//wAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAcHd3d3d3d3d3dwAAB3d3dwAAcA AAAHAHd3d3cABwAAAABwAAB3d3AAAAAHd3d3AABwAAAAcAAAd3cAAAcAAAAHAHd3d3dwAAd3dwAA AAAAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAH//8AAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB///AAAAAAAAAHAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABw AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAf//wAAAAAAAABwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAH//8AAAAAAAAABwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB///AAAAAAAAAAcAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAf//wAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAH//8AAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB///AAAAAAAAAAAAcAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAf//wAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAABwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAH//8AAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB///AAAAAAAAAAAAAAcAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAf//wAAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAABwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAH//8AAAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB///AAAAAAAAAAAAAAAAcAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAf//wAAAAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAABwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAH//8AAAAAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB3AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB///AAAAAAAAAAAAAAAAAAcA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAf//wAAAAAAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAH//8AAAAAAAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB///AAAAAAAAAAAAAAAAAAAA dwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAf//wAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAH//8AAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB///AAAAAAAAAAAAAAAAAAAA AABwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB3AAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAf//wAAAAAAAAAAAAAAAAAAAAAAB3AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAH//8AAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB///AAAAAAAAAAAAAAAAAAAA AAAAAHcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHcAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAf//wAAAAAAAAAAAAAAAAAAAAAAAAAAdwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAHcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAH//8AAAAAAAAAAAAAAAAAAAAAAAAAAAB3AAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAHcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB///AAAAAAAAAAAAAAAAAAAA AAAAAAAAAHcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHcAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAHAAcAAAAHd3AHd3cHAABwAAcAAHd3cHAABwAAAAcABw B3cAAAAAcAAHB3d3BwBwBwAHdwAABwAHd3cAAHAAAHAAd3AAB3cAd3dwB3dwAHd3AAAAAAAAAAAA AAf//wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAdwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AHcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAdwAHAAAAcAAHBwAABw AHAAAHAABwAABwAHAAAAAHAAAHAAcABwAHAAcAcAAAcAcAcAcABwAAcABwAAAABwAABwBwAHAHAA cHAAAHAABwcAAHAAAAAAAAAAAAAH//8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB3AAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAHcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAABwBwcABwAAAAAABwcAAAcABwAAcHAAcAAAcABwAAB3d3AABwAHAAcABwAHAHAAAHBwcHBwAA BwAHAAcAAAAAB3d3AHAAAAcAAABwAAAAAAcAAABwAAAAAAAAAAAAB///AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAHcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHcAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAcHAAcAAAAAB3AHAAAHAHAAAHBwAHAAAHAHAAAAcAcAAA cABwd3dwcAcABwAABwcHBwcAAAcABwAHAAAAAAcABwBwAAAHAAAAcAAAAAdwAAB3AAAAAAAAAAAA AAf//wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAdwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHcA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHBwBwAHAAAAB3AAB3d3B3 d3AAcABwB3d3B3d3AAAAcHAAAHAAcABwAHd3cAd3dwcHBwcHAAAHAAcAB3d3AAAAcHAAcAAABwAA AHd3cAdwAAB3AAAAAAAAAAAAAAAH//8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB3AAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAHcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAABwcAcABwAAAHAAAAcAAAcAAHAHAAcAcAAAcAAHAAAHBwAABwAHAAcABwAAcHAAAHcAB3BwAA BwAHAAcAAAAAAHBwAHAAAAcAAABwAABwAAAHAAAAAAAAAAAAAAAAB///AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAHdwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB3cAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAdwAHAAcAAABwAAcHAAAHAABwcAAAcHAAAHAABwAAAHcAAA cABwAAAAcAAHBwAAB3AAdwBwAHAABwAHAAAAAABwcAAHAAcAcABwcAAAcAAHBwAAcAAAAAAAAAAA AAf//wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB3AAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB3AAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAABwd3dwAAB3dwB3d3B3 d3AHAAAHB3d3B3d3AAAAAHAAAAd3AAAAAHd3cAd3dwcAAAcAB3cAB3d3B3d3AAAABwAAAHdwAAd3 AHd3cAd3cAB3dwAAAAAAAAAAAAAH//8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHcAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAB3AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB///AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAd3cAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHd3AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAf//wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAd3cAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAd3cAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAH//8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAd3AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAHdwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB///AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAHcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAf//wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAdwAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHcAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAH//8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAB3d3cAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAB3d3cAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAd3d3d3d3d3d3d3d3d3d3d3d3 cAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB///AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAd3d3cAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAd3d3AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AHB3d3d3d3d3d3d3d3d3d3d3d3AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAf//wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAd3cAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB3dwAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAABwd3d3d3d3d3d3d3d3d3d3d3dwAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAH//8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAd3d3AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAd3d3AAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAA cAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB///AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHd3d3cAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAHd3d3dwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AHd3d3d3d3d3d3d3d3d3d3d3d3cAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAf//wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAd3d3d3AAAAAAAAAAAAAAAAAAAAAAB3d3d3cAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAH//8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHd3d3d3d3d3d3d3d3d3d3d3AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAd3d3d3d3d3d3d3d3d3d3d3d3 dwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB///AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AHAHAAAAAHd3dwcAcAAAAHBwcHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAf//wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAABwcHAAAABwAAAHAHAAAABwcHBwAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAH//8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcHdwAAAAcAAABwBwAAAAcHdw cAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB///AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AHd3d3d3d3d3d3d3d3d3d3d3d3AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAf//wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAH//8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAAAAAHAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB///AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAcAAAAAAAAAAAAABwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAf//wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAH//8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB3d3d3d3d3d3d3d3AAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB///AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAABwAAAAAAAABwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAf//wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAHd3d3d3d3d3d3d3d3d3dwAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAH//8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAd3cAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAAAAAAAAAAcA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB///AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAdwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAcAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAf//wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAd3d3d3d3d3d3d3dwBwAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAH//8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAHd3d3d3d3d3d3d3cAcA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB///AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAABwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAcAB3d3d3d3d3d3d3d3AHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAf//wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAd3d3d3d3d3d3d3dwBwAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAH//8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAHd3d3d3d3d3d3d3cAcA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB///AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAcAB3d3d3d3d3d3d3d3AHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAf//wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAd3d3d3d3d3d3d3dwBwAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAH//8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB3dwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAHd3d3d3d3d3d3d3cAcA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB///AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAB3AAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAcAB3d3d3d3d3d3d3d3AHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAf//wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAcAAAAHcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAd3d3d3d3d3d3d3dwBwAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAH//8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAHd3d3d3d3d3d3d3cAcA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB///AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAcAB3d3d3d3d3d3d3d3AHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAf//wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAd3d3d3d3d3d3d3dwBwAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAH//8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAHd3d3d3d3d3d3d3cAcA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB///AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAcAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAf//wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAABwAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAH//8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB3d3d3d3d3d3d3d3d3d3cA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB///AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAf//wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAH//8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB///AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAf//wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAH//8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB///AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAf//wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAH//8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB///AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAf//wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAH//8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB///AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAABwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAABwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAf//wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAH//8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB///AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAABwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAABwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAf//wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAH//8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB///AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAABwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAf//wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAH//8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB///AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAABwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAf//wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAH//8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB///AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAABwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAf//wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAH//8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB///AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAABwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAf//wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAH//8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB///AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAf//wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAH//8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB///AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAABwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAf//wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAABwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAH//8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB///AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAABwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAf//wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAABwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAH//8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB///AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAf//wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAH//8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB///AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAf//wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAH//8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB///AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAABwAA cAcAAAAHAHd3d3AAAHd3d3dwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAf//wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAABwAAcAAHAHAAAABwBwAAAHAABwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAH//8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcABwcABwAHAAAHAAcAAAAHAAcAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB///AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAcHAA cABwAABwAHAAAAAHAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAf//wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAABwAHBwAHAAd3d3cABwAAAABwBwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAH//8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAcABwBwAAcABwAAcAAAAAcAcAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB///AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAHAAcA cAAHAAcAAHAAAAAHAHd3d3cAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAf//wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAABwcAAAcHAABwAHAABwAAAABwBwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAH//8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcHAAAHBwAABwcAAAcAAAAAcAcAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB///AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHcAAAAH cAAAcHAAAHAAAABwAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAAAHdwBwAA AHdwAHcHBwAAdwcAAHBwAHB3AHdwBwAAcAB3BwB3cAB3cAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAf//wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAABwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAB3AAAAB3AAAHBwAABwAAAHAABwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAHAAAAcABwcAAAcABwcAdwcABwB3AABwcABwcAcABwcAAHAHAHcHAAcHAAcAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAH//8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAAAABwAAAHAAAAd3d3cAAAd3d3d3AA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAABwAAAHAABwAAAHAAcHAAcABwAAcHAAcHAH AAAHAABwBwAHBwAABwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB///AAAAAAAAAAAAAAAAAAAA AAAAAAAAAABwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAd3cAcAAABwAA cAAAAHd3BwAHAAcAAHBwAHBwB3d3BwAAcAB3dwcAAAd3dwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAf//wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAABwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAHAAcHAAAAcAAHAAAAcABwdwBwB3AABwcABwcAcABwdwAHAHAAcHAAcHAAcAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAH//8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAHBwAAAHAABwAAAAd3AHBwB3BwAAcHd3B3cA d3AHBwd3AHdwAHdwAHdwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB///AAAAAAAAAAAAAAAAAAAA AAAAAAAAAABwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcABwBwAHBwAA BwAHAAAAAAAAAAcAAHAAAABwAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAf//wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAHd3AAB3cAcAAAB3cAAAAAAAAAAHAABwAAAAcAAAAAAAAAcAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAH//8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB///AAAAAAAAAAAAAAAAAAAA AAAAAAAAAABwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAf//wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAH//8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAcAAAAHAAd3cAAAAAcAAAd3AAAAAAAAAAd3dwAAcAAAAHAHd3d3AAB3d3dwB3d3d3cAAAAAB3d3 AAAAd3dwAAAHd3cAAAAHAAAAAHd3AAAHAABwAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB///AAAAAAAAAAAAAAAAAAAA AAAAAAAAAABwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAcABwAAcAAAAHAABwAHAAAAAAAABwAABwAHAAAABwBwAA AHAAcAAAAAcAAAAAAAAAAHAAAHAABwAABwAAcAAAcAAABwAAAAcAAHAABwAAcAAHAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAf//wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAABwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAABwAAcAAHAAAABwAHAAAH AAAAAAAHAAAABwAHAAAHAAcAAAAHAHAAAAAHAAAAAAAAAAcAAAAHAHAAAABwBwAAAAcAAAcAAABw AAAHAAcABwcABwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAH//8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAcAAAcAAHAABwd3d3dwAAAABwAAAAAAcAAAAAAABwAABwAHAAAABwBwAAAABwAAAAAAAABwAAAA AABwAAAAcAAAAAAHAAAHAAAHAAAAAHAHAAcHAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB3d3d3d3d3d3d3d3d3d3 d3dwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB///AAAAAAAAAAAAAAAAAAAA AAAAAAAAAABwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAHAABwAAAAAAcHAAAHAAAAAAcAAAAAAHAAAAAAAAd3d3cABwAA AAcAcAAAAAcAAAAAAAAAcAAAAAAAcAAAAHAAAAAABwAABwAABwAAAABwBwAHBwAHAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAd3d3d3d3d3d3d3d3d3d3d3cAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAf//wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB3d3dwAAAAAHAHAABwAAAAAH AAAAAABwAAAAAAAAcABwAAcAAABwAHAAAAAHAAAAAAAAAHAAAAAAAHAAAABwAAAAd3AAAAcAAAcA AAAAcAcAcABwBwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAH//8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAcAAABwAAAABwAHAAcABwAAcAAAAAAAcAAAAAAAAHAAcAAHd3d3AABwAAAAB3d3d3AAAABwAAAA AABwAAAAcAAHdwAAAAAHAAAHAAAAAHAHAHAAcAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwB3d3AAAAAAAAAAAAAA AABwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB///AAAAAAAAAAAAAAAAAAAA AAAAAAAAAABwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAABwAAAAcAAHAHAAd3dwAAAAAAAHAAAAAAAABwAHAABwAA AHAAcAAAAAcAAAAAAAAAcAAAAAAAcAAAAHAAcAAAAAAABwAABwAAAABwBwcAAAcHAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAcAcABwAAAHd3d3d3d3d3AAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAf//wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAcAAAAHAABwBwAHAAAA AAAAAABwAAAAAAAABwcAAAcAAAAHAHAAAAAHAAAAAAAAAHAAAAAAAHAAAABwBwAAAAAAAAcAAAcA AAAAcAcHAAAHBwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAHAAcAAABwdwBwB3B3BwAHAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAH//8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAcAAAAHAAAABwAABwcAAHAAAAAAAAAABwAAAAcAAAcHAAAHAAAABwBwAAAABwAAAAAAAAAHAAAA BwBwAAAAcAcAAAAHAAAHAAAAcAAABwAHcAAAAHcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwBwAHAAAAd3d3d3d3d3 cABwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB///AAAAAAAAAAAAAAAAAAAA AAAAAAAAAABwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAcAAAAAcAAAB3AABwAAAAAAAAAABwAABwAAAHBwAABwAA AHAAcAAAAAcAAAAAAAAAAHAAAHAAcAAAAHAAcAAAcAAABwAAAAcAAHAAB3AAAAB3AAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAcAcABwAAAAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAf//wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB3d3dwAAAAAHAAAABwAAd3d3 AAAAAAAAB3d3AAAAAHAAAAd3d3dwAHAAAAAHd3d3dwAAAAAHd3cAAHAAAABwAAd3dwAHd3d3dwAA d3cAAAcAAAAABwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAHd3cAd3d3AAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAH//8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAHd3d3d3dwAAAA AABwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB///AAAAAAAAAAAAAAAAAAAA AAAAAAAAAABwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAd3d3B3d3AABwAAcAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAf//wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHcABwcABwAAcAAHB3d3cAAHAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAH//8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB3d3cHd3cAAHAABwd3d3 AABwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB///AAAAAAAAAAAAAAAAAAAA AAAAAAAAAABwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAd3d3B3d3AABwAAcHd3dwAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAf//wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAABwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHcABwcABwAAd3d3B3d3cAAHdwAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAH//8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB3AAcHAAcAAAAAAAd3d3 AABwcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB///AAAAAAAAAAAAAAAAAAAA AAAAAAAAAABwAAAAAAAAAAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAd3d3B3d3AAAAAAAHd3dwAAd3AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAf//wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAA AAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHd3d3d3d3d3d3d3d3d3d3d3AAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAH//8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAA AAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB///AAAAAAAAAAAAAAAAAAAA AAAAAAAAAABwAAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAf//wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAcAAAAAAAAAAAAAAA AAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAH//8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAA AAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB///AAAAAAAAAAAAAAAAAAAA AAAAAAAAAABwAAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAf//wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAAAAAA AAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAH//8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAA AAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB3AAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB///AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AHdwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAf//wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAAAAAA AAAAAAAAAAAAAABwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAB3dwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAH//8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAAAAAAAAAAAA AAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAd3cAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB///AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA B3d3AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAf//wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAA AAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAd3d3AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAH//8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAAAAAAAAAAAA AAAAAAAAAABwAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHd3dwAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB///AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA d3d3dwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAf//wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAHd3d3cAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAH//8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAAAA AAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB3d3d3AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB///AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAf//wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAcAAAAAAAAAAAAA AAAAAAAAAAAAAAAABwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAH//8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAAAA AAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB///AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAABwAAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAf//wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAAAA AAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAH//8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAA AAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB///AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAABwAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAf//wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAAAA AAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAH//8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAAAAAAAAAA AAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB///AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAHcA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AABwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAf//wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAcAAAB3AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAH//8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAA AAAAAAAAAAAABwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAAdwAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB///AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAHcA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AABwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAf//wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAHAAB3AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAH//8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAdwAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB///AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAHcA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AABwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAf//wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAcABwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAH//8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAcAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB///AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAHcA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AABwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAf//wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAHd3AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAH//8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB///AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AABwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAf//wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAH//8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB///AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAf//wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAH//8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB///AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAf//wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAH//8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB///AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAf//wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAHdwAAAABwAAcAAHAAAHd3AAAH d3d3AAAHd3d3dwBwAAcAAHAAB3d3AAAAAAAAcAAAAHAAB3cAAAAABwAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAH//8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAA cABwAAAAcAAHAABwAAcAAHAABwAAAHAABwAAAAAAcAAHAABwAHAAAHAAAAAAAHAAAAAAB3AAcAAA AAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB///AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAHAABwAABwAAAHAAcHAAcABwAAAHAAcAAAAHAAcAAAAAAHAAcHAAcAcA AAAHAAAAAAcHAAAAAAcAAAcAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAf//wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAcAAAcAAABwAHBwAHAHAAAAAHAH AAAAAHAHAAAAAABwAHBwAHAAAAAABwAAAAAHBwAAAAAAAAAHB3d3d3AAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAH//8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAH AAAHAAAAcABwcABwBwAAAABwBwAAAABwBwAAAAAAcABwcABwAAAAAAcAAAAAcABwAAAAAAAABwcA AAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB///AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAHAABwAABwAAAHAHAAcAcAcAAAAAcAcAAAAAcAcAAAAAAHAHAAcAcAAA AHdwAAAAAHAAcAAAAAAAAHAAcAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAf//wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAdwAHAAAABwBwAHAHAHAAAAAHAH AAAAAHAHd3d3cABwBwAHAHAAB3cAAAAAAABwAHAAAAAAB3cAAAcABwAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAH//8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAH B3cAAAAAcHAAAHBwBwAAAABwBwAAAABwBwAAAAAAcHAAAHBwAHAAAAAAAAAHAAAHAAAAAAAHcAAA cAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB///AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAHAHAABwAAAAAAAHBwAABwcAcAAAAAcAcAAAAAcAcAAAAAAHBwAABwcAcA AAAAAAAABwAABwAAAAAAAHAAAHAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAf//wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHBwAAcAAAcAAAB3AAAAB3AAcAAABwAH AAAABwAHAAAAAAB3AAAAB3AHAAAABwAAAAcAAAcAAAAHAABwAAAHBwAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAH//8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHcAAA cABwAAAAdwAAAAdwAAcAAHAABwAAAHAABwAAAAAAdwAAAAdwAHAAAHAAAABwAAAAcAAAAHAAcAAA AHcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB///AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAHAAAAd3AAAAAHAAAAAAcAAAd3cAAAd3d3cAAAd3d3d3AHAAAAAAcAAH d3cAAAAAcAAAAHAAAAAHdwAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAf//wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAH//8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB///AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAf//wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAH//8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB///AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAf//wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAH//8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB///AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAf//wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAH//8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB///AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAf//wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAH//8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB///AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAABwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAf//wAAAAAAAAAAAAAAAAAAAAAAB3cAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB3cAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAH//8AiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiI iIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiI iIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB///AId3d3d3d3d3d3d3d3d3 d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3 d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3dwAAAAAAAAAAAAAAAA AAAABwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAf//wh3eId3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3 d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3 d3d3d3d3cAAAAAAAAAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAABwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAH//8Id3iIiIiIiIiIiIiIiIiIiIiIiIiIiIiId3d3d3d3d3d3 d3d3d3d3d3d4iIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiI iIiIiIiIiIiIiIiIh3d3d3d3d3d3d3d3d3AAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB///CHd4iIiIiIiIiIiIiIiI iIiIiIiHd3d3d3d3d3d3d3d3d3d3d3d3d3d4h3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3 d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3eId3d3d3d3d3d3d3dwAAAAAAAAAAAAAAAA AAAABwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB3dwAAB3cAAHAABwAAd3cHAHAHB3cAAAB3 cAAHAAB3cAd3cAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAf//wh3eId3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3h3d3d3d3d3d3d3d3 d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d4d3d3d3 d3d3d3d3cAAAAAAAAAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAABwAHAA cABwAAcABwAAdwBwB3AAcAAHAAcABwAAcABwAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAH//8Id3iIiIiIiIiIiHd3d3d3d3d3d3d3d3d3d3d3d3d3d3d3 d3d3d3d3eHd3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3 d3d3d3d3d3d3d3d3d3d3h3d3d3d3d3d3d3AAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAcAcAAAcAcAAHAAcAAAcAcAcAAAcAcAAAcAcAAHAAAAAHAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB///CHd4iIiIiIiIiIiIiIiI iIiIiIiIiIiIiHd3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3 d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d4d3d3d3d3d3dwAAAAAAAAAAAAAAAA AAAABwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAHAAAAAHAABwAHAAAHAHAHAAAHAHAA AHAHAABwAAAABwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAf//wh3eIiIiIiIiIiIiIiIiIiIiIiIiIiIh3d3d3d3d3d3d3d3d3d3d3eHd3d3d3d3d3d3d3d3 d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d4d3 d3d3d3d3cAAAAAAAAAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAd3cAB3d3 dwBwAAcAAHdwBwBwBwAABwBwAABwBwAAcAAHd3AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAH//8Id3iHd3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3 d3d3d3d3h3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3 d3d3d3d3d3d3d3d3d3d3d3d4d3d3d3d3d3AAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAABwAAAAcAAAcAcAAHAAAAB3cAcAcAAAcAcAAAcAcAAHAAcAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB///CHd4iIiIiIiIiIiIh3d3 d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d4d3d3d3dwcHd3d3d3B3d3B3d3d3B3AHdwBwd3d3d3d3 d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d4d3d3d3d3dwAAAAAAAAAAAAAAAA AAAABwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAAAHAAAHAHAABwAHAAAHAHAHAAAHAHAA AHAHAABwAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAf//wh3eIiIiIiIiIiIiIiIiIiIiIiIiIiIiHd3d3d3d3d3d3d3d3d3d3eHd3d3d3cHBwd3dwdw d3dwdwd3dwd3d3d3cHcHdwB3dwd3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d4 d3d3d3d3cAAAAAAAAAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAABwAHAA cAB3AAcAAHAABwBwB3AAcAAHAAcAB3AAcABwAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAH//8Id3iIiIiIiIiIiIiIiIh3d3d3d3d3d3d3d3d3d3d3d3d3 d3d3d3d3h3d3d2ZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZ3d3d3d3 d3d3d3d3d3d3d3d3d3d3d3d3d4d3d3d3d3AAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAHd3AAAHdwAAcHcHAAAHd3AAcAcHdwAAAHdwAAcHd3dwB3dwAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB///CHd4h3d3d3d3d3d3d3d3 d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d4d3d3dmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZm ZmZmZmZmZmZmZmZmZmd3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d4d3d3d3dwAAAAAAAAAAAAAAAA AAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAA AAAAAABwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAf//wh3eIiIiIiIiIiIiIiIiIiHd3d3d3d3d3d3d3d3d3d3d3d3d3d3d3eHd3d3ZmVVVWZmVVVW ZmYiImZmYiImZmYiIiZmYiIiZmZmZmZmZmZmZmZmZmZnd3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3 d3h3d3d3cAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAABwAAAAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAH//8Id3iIiIiIiIiIiIiIiIiIiIiIiIiIiIiId3d3d3d3d3d3 d3d3d3d3h3d3d2ZlVVVmZlVVVmZmIiJmZmIiJmZmIiImZmIiImZmZmZmZmZmZmZmZmZmZ3d3d3d3 d3d3d3d3d3d3d3d3d3d3d3d3d3d3h3d3d3AAAAAAAAAAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAACHd4iIiIiIiIiIiIiIiI iId3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d4d3d3dmZVVVZmZVVVZmZiIiZmZiIiZmZiIiJmZiIiJm ZmZmZmZmZmZmZmZmZmd3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3dwAAAAAAAAAAAAAAAA AAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAf//wh3eId3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3eHd3d3ZmZmZmZmZmZm ZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZnd3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3 d3d3h3d3cAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAH//8Id3iIiIiIiIiIiHd3d3d3d3d3d3d3d3d3d3d3d3d3d3d3 d3d3d3d3h3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3 d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3h3d3AAAAAAAAAAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB///CHd4iIiIiIiIiIiIiIiI iIiIiIiId3d3d3eIiIiIiIiIiIiIiIiHd4d3d3d3d3cAd3d3dwd3d3dwd3dwd3d3d3AHd3d3AHd3 d3cAB3d3dwd3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3h3dwAAAAAAAAAAAAAAAA AAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAf//wh3eIiIiIiIiIiIiIiIiIiIh3d3d3d3d3d3iIiIiIiIiIiIiIiIh3eHd3d3d3d3cAd3d3AH d3d3cHd3cHd3d3dwcHd3dwcHd3d3Bwd3d3cAd3d3dwd3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3 d3d3d3h3cAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAH//8Id3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3 d3d4iId3h3d3d3d3AHAHd3dwd3d3dwd3d3B3d3d3cHd3d3cHB3d3dwcHd3d3AHd3d3cHd3d3d3d3 d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3h3AAAAAAAAAAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB///CHd3d3d3d3d3d3d3d3d3 d3d3d3d3d3iIiIiIiIiIiIiIiIiIiIiHd4d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3 d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3eAAAAAAAAAAAAAAAAA AAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAf//wh3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3iIiIiIiIiIiIiIiIiIh3eHd3d3d3d3d3d3d3d3 d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3cH d3d3d3d3gAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAH//8Id3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3 d3d4iId3h3d3d3d1VVV3dyIiJ3d3IiJ3d3IiJ3d3IiInd3IiInd3IiInd3IiInd3IiInd3d3d3d3 d3dwd3cAcHB3dwcHd3B3AHB3cHcAB3B3d3AAAAAAAAAAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAAB3cAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB///CHd3d3d3d3d3d3d3d3d3 d3d3d3d3d3d3d3d3iIiIiIiIiIiIiIiHd4d3d3d3dVVVd3ciIid3dyIid3dyIid3dyIiJ3dyIiJ3 dyIiJ3dyIiJ3dyIiJ3d3d3d3d3d3dwdwB3cHcHB3B3cHcHAABwAHAHBwB3dwAAAAAAAAAAAAAAAA AAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAHAAcAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAf//wh3d3d3d3d3d3d3d3d3d3d3d3d3eIiIiIiIiIiIiIiIiIiIiIiIh3eHd3d3d3VVVXd3IiIn d3ciInd3ciInd3ciIid3ciIid3ciIid3ciIid3ciIid3d3d3d3d3dwd3dwd3Bwd3dwB3d3d3d3d3 d3d3d3d3cAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAABwAAcAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAH//8Id3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3 d3d4iId3h3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3 d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3AAAAAAAAAAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAHAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB///CHd3d3d3d3d3d3d3d3d3 d3d3d3d3d3d3d3d3d3d3d3d3d3d3eIiHd4d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3 d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3dwAAAAAAAAAAAAAAAA AAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAABwAABwAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAf//wh3d3d3d3d3d3d3d3d3d3d3d3d4iIiIiIiIiIiIiIiIiIiIiIiIh3eHd3d3d3Bwd3d3d3B3 d3dwd3d3dwd3d3d3d3d3d3cHd3d3cHd3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3 d3d3d3d3cAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAABwAAcAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAH//8Id3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3iIiIiIiIiI iIiIiId3h3d3d3dwB3d3d3dwd3d3cHd3d3d3d3d3d3d3d3d3d3d3dwd3d3d3d3d3d3AHd3d3d3d3 d3d3d3d3d3d3d3d3cABwd3B3cAB3cHdwAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAHcABwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB///CHd3d3d3d3d3d3d3d3d3 d3d3d3d3d3d3d3d3d3d3d3d3d3d3eIiHd4d3d3d3cHAHd3d3cHd3d3d3d3d3d3d3d3cHd3d3cHd3 d3cHd3d3d3d3d3dwB3d3d3d3d3d3d3d3d3d3d3d3d3AAcHBwd3AAd3B3d3cAAAAAAAAAAAAAAAAA AAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAABwd3AAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAf//wh3iIiIiIiIiHd3d3d3d3d3d3d3d3iIiIiIiIiIiIiIiIiIiIiIh3eHd3d3d3d3d3d3d3d3 d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3 d3d3d3d3cAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAABwBwAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAH//8Id4iIiIiIiIiIiIiHd3d3d3d3d3d3d3d3d3d3eIiIiIiI iIiIiId3h3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3 d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3AAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwcAAHAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB///CHeIiIiIiIiId3d3d3d3 d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d4d3d3d3dVVVd3ciIid3dyIid3dyIid3dyIiJ3dyIiJ3 dyIiJ3dyIiJ3dyIiJ3d3d3d3ERERERcRFxERERERcRERcRERERERERERERcQAAAAAAAAAAAAAAAA AAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB3AAAHAAcAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAf//wh3iHd3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3eHd3d3d3VVVXd3IiIn d3ciInd3ciInd3ciIid3ciIid3ciIid3ciIid3ciIid3d3d3d3dxF3d3d3cXEXcRcXEXd3d3F3dx dxF3EXd3cAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAABwAAAHdwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAH//8Id4iIiIiIiIiIiHd3d3d3d3ERd3FxEXEXEXERcXEXd3d3 d3d3d3d3h3d3d3d1VVV3dyIiJ3d3IiJ3d3IiJ3d3IiInd3IiInd3IiInd3IiInd3IiInd3d3d3d3 cRcAd3B3EBEAEQFxFwB3ABcHAXARBxEAdwAAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAd3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3 d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3cAAAB///CHeId3d3d3d3d3d3d3d3 d3dxERFxF3cRERFxcRdxd3d3d3d3d3d3d4d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3 d3d3d3d3d3d3d3d3d3d3d3d3d3EXcHcHBxARcBEBcRB3dwAXBwFwEQcRAHdwAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAA AAf//wh3iHd3d3d3d3d3d3d3d3d3cRF3ERd3ERERcXEXcXd3d3d3d3d3d3eHd3d3d3d3d3d3d3d3 d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3dxF3B3BwcQEXARAXEQd3cAFwAB cBEHEQB3cAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAABwAAAH//8Id4iIiIiIiIh3d3d3d3d3d3ERd3Fxd3F3d3Fxd3d3d3d3 d3d3d3d3h3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3 cRBwB3d3EBF3EQFxEHB3dxd3cXARdxF3d3AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAAB///CHeId3d3d3d3d3d3d3d3 d3d3d3d3d3d3d3d3d3d3dxd3d3d3d3d3d4d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3 d3d3d3d3d3d3d3d3d3d3d3d3d3EXd3d3dxcRdxFxcRd3d3cXd3F3EXcRd3dwAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAA AAf//wh3iIiIiHd3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d4d3d3d3d3d3d3d3d3 d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3dxF3d3d3cXEXcRcXEXd3d3F3dx dxF3EXd3cAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAABwAAAH//8Id4iIiIiIh3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3 d3d3d3d3d4d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3 d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAAB///CHeId3d3d3d3d3d3d3d3 d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d4d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3 d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3dwAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAA AAf//wh3iIiIiIiHd3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3eIiIiIiIiIiIiI iIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiI iIiIiIiIgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAABwAAAH//8Id4iIiId3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3 d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3 d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAAB///CHd3d3d3d3d3d3d3d3d3 d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3 d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3dwAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAA AAf//wCHd3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3 d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3 d3d3d3d3cAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAABwAAAH//8Ah3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3 d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3 d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAd3d3AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAAB///AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHd3d3d3AAAAcAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAA AAf//wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAHd3cHdwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAABwAAAH//8AAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAABwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB3BwB3AAAAAAAAAAAAAAAAAAAAAAAAAA AAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAAB///AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAcAAH AAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAA AAf//wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAHcAAHAAAHcAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAABwAAAH//8AAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAABwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAABwAAAAdwAAAAAAAAAAAAAAAAAAAAAA AAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAAB///AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAdwAAAAcAAA AABwAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAA AAf//wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAABwAAAAAHAAAAAAB3AAAAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAABwAAAH//8AAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAAAAAA AAAAAAAHAHAHBwAABwcAAHBwAABwAHdwAHd3cHAHAHB3d3BwAAcABwAAAAAAAAAAAAAAAAAAAAAA AAAABwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB3AAAAAABwAAAAAAAHcAAAAAAAAAAAAAAAAAAA AAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAABwAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAABwBwBwcAAAcHAAdwcAAAcAcABwBwAABwBwBwcAAAcAB3 AAcAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAcAAA AAAAAAdwAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAHd3BwAAd3AAcAAA cAAAAHdwAAB3cAAHAABwAAd3AAAHdwAAcAAHAHdwcAAAd3cHAHdwAHdwAAcAAAAAAAAAAAAAAHAA AAf//wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAcHBwcAd3dwBwBwcAd3 dwBwAABwcAAAcHBwcHAAAHAHBwAHAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAHcAAAAAAAAHAAAAAAAAAABwAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAAAAAAAAAAAA AAAAAABwAAcAAHcABwAHAHAABwAAAAcABwAHAAcABwAAcABwAHAAcABwAHAABwBwAHAABwAAdwBw AAcABwAHAAAAAAAAAAAAAABwAAAH//8AAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAAAAAA AAAAAAAHBwcHAHAAcAcAcHAHAAcAcAB3cHAAAHBwcHBwAABwBwcABwAAAAAAAAAAAAAAAAAAAAAA AAAABwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAAAAAAAABwAAAAAAAAAAB3AAAAAAAAAAAAAAAA AAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAHAAAHAHAAAABwAHAAAABwAAAAcAAAcAcAAHAHAAAA BwAABwBwAAcAcABwAAcAAAcAcABwAABwBwAAAAAAAAAAAAAAcAAAB///AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAABwcHBwAHBwAHBwBwAHBwAHAAAAB3d3BwcHBwd3dwcHAH AAcAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAA AAAAAAAAAHcAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAHAABwAABwBwAAAAdwBw AAAAcAAAAHAAAHAHAABwBwAAAAcAAAAAcAAHAHAAcAAHAAAHAHAAcAAAcAcAAAAAAAAAAAAAAHAA AAf//wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAdwAHcABwcABwcAcABw cABwAABwcAAAdwAHcHAAAHBwBwAHAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAABwAAAAAAAAAAAAAAAAAAAA AAAAAABwAAB3cAcAcAAAAHB3AAAAAHAAAABwAABwBwAAcAcAAAAHd3d3AHAABwBwAHAAAHdwBwBw AHAAAHAHAAAAAAAAAAAAAABwAAAH//8AAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAAAAAA AAAAAAAHcAB3AAcHAAdwAHAAcHAABwAHAHAAAHcAB3BwAAB3AAcABwAAAAAAAAAAAAAAAAAAAAAA AAAABwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAAAAAAdwAAAAAAAAAAAA AAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAAAAd3AHAAAABwBwAAAABwAAAAcAAAcAcAAHAHAAAA BwAABwBwAAcAcABwAAAAB3cAcABwAABwBwAAAAAAAAAAAAAAcAAAB///AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAABwAABwAAcAAHAABwAAcAAAB3cAB3d3BwAABwd3dwcAAH B3d3AAAAAAAAAAAAAAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAA AAAAAAAAAAAAB3AAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAHAABwAABwBwAAAAcABw AAAAcAAAAHAAAHAHAABwBwAAAAcAAAcAcAAHAHAAcAAHAAAHAHAAcAAAcAcAAAAAAAAAAAAAAHAA AAf//wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAABwAAAAAAAAAAAAAAAAAAAA AAAAAAB3AABwAAcABwAHAHAABwAAAAcABwAHAAcAB3AAcABwAHAAcABwAHcABwBwAHcAAHAABwBw AAcABwAHcAAAAAAAAAAAAABwAAAH//8AAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAABwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAAAAAAAAAHcAAAAAAAAA AAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAcHcAB3dwAAB3cABwAABwAAAAd3AAAHdwAAcHdwAAB3cA AAd3AABwd3AHd3BwdwAHd3AHd3AAd3AABwdwAAAAAAAAAAAAcAAAB///AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAA AAAAAAAAAAAAAAAAdwAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAHAA AAf//wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB3cAAAAAAA AAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAABwAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAABw AAAAAAAAAAAAAAAAAAAAAABwAAAH//8AAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAAAAAA AAAAAAcAAAcAd3AAAHAAAAcAAAcAcABwAHAABwAAB3dwBwAAcHAHAHBwAAAAAAAAAAAAAAAAAAAA AAAABwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAd3d3AAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAAAAAAAAAAAAB3AAAAAA AAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAAB///AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAHAAAABwAHAABwAAAHAAAHAHAAcABwAAcAAHAABwcAB3Bw BwBwcAAAAAAAAAAAAAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHd3d3cAAAAAAAAAAAAAAAAAAAAAAAAAcAAA AAAAAAAAAAAAAAAAAAAHcAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAA AAf//wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAcHAAAAAABwd3dwAAcHAA cHBwAHAAcAAHAAAAAAcHAHBwcHBwcHAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB3d3d3d3AA AAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAcAAAAAAABwAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAABwAAAH//8AAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAAAAAA AAAAAHBwAAAAAAcHAHAAAHBwAHBwcABwAHAABwAAAAdwBwBwcHBwcHB3dwAAAAAAAAAAAAAAAAAA AAAAB3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3 d3d3d3d3d3d3d3d3d3d3d3d3cAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAAAAAAAAAAAAAAAAdwAA AAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAAB///AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAcAAAAAAAAAAAAAAAAAAAcABwAAAAdwAHBwAABwBwcAcHAAcAB3d3cAAAdwAAcHAHBw cHBwcABwAAAAAAAAAAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHd3d3d3AAAAAAAAAAAAAAAAAAAAAAAAcAAA AAAAAAAAAAAAAAAAAAAAAAB3AAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAA AAf//wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAHAAcAAAAABwBwcAAAcAcH AHBwAHAAcAAHAABwAAAHBwBwdwAHcHAAcAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB3d3dwAAAA AAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAHcAAABwAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAB3dwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAA AAAAAAAAAAAAAAAAAAAAAABwAAAH//8AAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAAAAAA AAAAcAAAcAAHAAcAB3AABwAHBwAHcABwAHAABwAAcAAHB3AAcHcAB3BwAHAAAAAAAAAAAAAAAAAA AAAABwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAd3cAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAAAAAAAAAAAAAAAAAAAA cAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAABwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAABwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAAB///AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAcAAAAAAAAAAAAAAAAAAHAAAHAAAHdwAABwAAcAAHAAB3B3d3BwAAcAAAd3cAcAAHBw AABwd3cAAAAAAAAAAAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAA AAAAAAAAAAAAAAAAAAAAAAAAAAdwAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAA AAf//wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB3BwAAAAAAAAAAAAAAAAAAAA AAAHd3d3AAAHAAAHdwcAcAAAAAB3cAcAAAB3cAAAd3AABwAAcAAAAAAHAAAAd3AAAAAHB3cAAAB3 cAAHAAB3cAd3cAAAAAAAAABwAAAH//8AAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAABwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAHcAAAAAAAAAAAAAAAAAAAAAAABwAAAHAABwAAcAB3AHAAAAAHAAcHAAAHAAcABwAHAAcAAHAA AAAABwAABwAHAAAAB3AAcAAHAAcABwAAcABwAAcAAAAAAAAAcAAAB///AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAHcAAAAAAAAAAAAAAAAAAAAAAAcAAAAHAAcABwAABwBwAAAA cAAAAHAAcAAAAHAAAHAHAABwAAAAAAcAAHAAAHAAAAcAAAcAcAAAcAcAAHAAAAAHAAAAAAAAAHAA AAf//wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAdwAAAAAAAAAAAAAAAAAA AAAHAAAAAHAHAAcAAAcAcAAAAHAAAABwAHAAAABwAABwBwAAcAAAAAAHAABwAABwAAAHAAAHAHAA AHAHAABwAAAABwAAAAAAAABwAAAH//8AAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAABwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAABwAAAAAAAAAAAAAAAAAAAABwAAAABwBwAHAAAHAHAAAABwAAAAcABwAAAAcAAAcAcAAHAA AAAABwAAcAAAcAAABwAABwBwAABwBwAAcAAHd3AAAAAAAAAAcAAAB///AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAcAAAAAcAcAcHAAAAAHAABwAAd3AAAABwAAB3cAAAcABwAABwd3dwAAAHdwAAd3AAcA AHAAcABwAAcAB3cAB3d3AAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB3AAAAAAAAAAAAAAAAAAAAAAcAAAAAcAcABwAABwBwAAAA cAAAAHAAcAAAAHAAAHAHAABwAAAAAAcAAHAAAHAAAAcAAAcAcAAAcAcAAHAAcAAAAAAAAAAAAHAA AAf//wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAHAHAHBwAAAABwAAcABwAHAAAAcAAHAAcAAH AAcAAAcHAAAAAAcABwBwAHAHAAdwAHAAcABwAHAAcAcAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB3AAAAAAAAAAAAAAAAAAAA AAAHAAAAAHAHAAcAAAcAcAAAAHAAAAAHAHAAAABwAABwBwAAcAAAAAAHAAB3AAcAAAAHAAAHAHAA AHAHAABwAHAAAAAAAAAAAABwAAAH//8AAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAABwcHBwcAAA AABwAHAAcABwAAAHAAcAAAcABwAAd3dwBwAAAABwAAAHAAAHBwBwcABwAHAAcAcAAAcHAAAAAAAA AAAABwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB3d3d3d3d3d3d3d3cAAAAAAAAAAAAAAAAAAAAAAAAAAA AAB3cAAAAAAAAAAAAAAAAAAAAAAABwAAAABwBwAAcAB3AHAAAAAHAAcABwAHAAcABwAHAAdwAHAA AAAABwAAcHdwAAAAB3AAcAAHAAcAB3AAcABwAAcAAAAAAAAAcAAAB///AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAcAAAAAcHBwcHd3AAAAcABwAHAAcAAABwAHAAAHAAcAAHAAcAcAAAAAcAAABwAABwcA cHAAcABwBwAHAAAHBwAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAHAHAAAAAAAAAAAAAAAAAAAAAAAAcAAAAAcAcAAAd3BwBwAAAA AHdwAAcAAHdwAAB3cAAHB3cAAAAAcAcAAHAAAAAAAAcHdwAAAHdwAAcHd3dwB3dwAAAAAAAAAHAA AAf//wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAHBwcHBwAHAAAHAAcAB3dwAAAAcABwAABwAH AAAHBwAHAAAAAHAAAAcAAAcHBwBwAHAAd3dwBwAABwcAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHcABwAAAAAAAAAAAAAAAAAAAA AAAHAAAABwAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAcHAABwAABwAAAAAAAAAAAA AAAAAABwAAAAAAAAAAAAAABwAAAH//8AAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAB3AAdwcABw AABwcHAAcAAAAAAHAAcAAAcABwAABwcABwAAAABwAAAHAAAHBwcAcABwAHAABwcAAAcHAAAAAAAA AAAABwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAAAAAAAAAAAAAAAAAAAH cAAAcAAAAAAAAAAAAAAAAAAAAAAABwAAAHAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAA AAAAdwAABwAHAAAAAAAAAAAAAAAAAAAAcAAAAAAAAAAAAAAAcAAAB///AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAcAAAAAdwAHcHAAcAAABwdwAHAAcAAABwAAcABwAAcAAAcHAAcAAAAABwAHAHAAcAdw AHAAcABwAAcAcABwBwAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAA AAAAAAAAAAAAAAAAAAAAAAAHcAAAAHAAAAAAAAAAAAAAAAAAAAAAAAd3d3cAAAcAAAAAAABwAAAA AAAAAABwAAAAAAAAAAAAAAAAAAAAAAcAAAB3cAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAA AAf//wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAHAAAHB3dwAAAAcAcAAHdwAAB3d3AAd3AAd3 dwAAcAAHAAAAAAB3cAAHdwAHAABwd3dwd3dwAAd3AAcAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAcAAAAABwAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAABwAAAH//8AAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAABwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAAAAAAAAAAAAAAAAdwAA AAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAAB///AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAA AAAAAAAAAAAAAAAAAAAAdwAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAA AAf//wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAdwAAAAAAAABwAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAABwAAAH//8AAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAABwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAAAAAAAAAAAABwAAAAAA AAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAAB///AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAA AAAAAAAAAAAAAAAAB3AAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAA AAf//wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAB3AAAAAAAAAAAABwAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAABwAAAH//8AAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAABwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAAAAAAAAAHAAAAAAAAAA AAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAAB///AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAA AAAAAAAAAAAAAHcAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAA AAf//wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAHcAAAAAAAAAAAAAAABwAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAABwAAAH//8AAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAABwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAAAAAHcAAAAAAAAAAAAA AAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAAB///AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAA AAAAAAAAAAcAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAA AAf//wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAdwAAAAAAAAAAAAAAAAAABwAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAABwAAAH//8AAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAABwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAAdwAAAAAAAAAAAAAAAA AAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAAB///AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAA AAAAAAdwAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAA AAf//wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAHAAAAAAAABwAAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAABwAAAH//8AAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAABwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAAB3AAAAAAAAAAAAAAAAAAAA AAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAAB///AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAA AAB3AAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAA AAf//wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAHAAAAB3AAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAABwAAAH//8AAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAABwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAd3AAAAAAAAAAAABwAAAHAAAAAAAAAAAAAAAAAAAAAAAA AAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAAB///AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHd3AAAAAAAAAAcAAH cAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAA AAf//wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAHd3AAAAAAAHAHcAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAABwAAAH//8AAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAABwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHd3AAAAB3cAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAAB///AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHd3AAcAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAA AAf//wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAHcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAABwAAAH//8AAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAAAAAAAAAAAA AAAABwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAAB///AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAHAAAAAAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAA AAf//wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAABwAAAHAP8AAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcHdwAAcABwAAcA AAAABwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAABwAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAHcABwAHAAcAAHAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAA AAf//wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAABwBwAHAABwAAAAAHAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAABwAAAH//8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAB3d3d3d3d3d3d3d3 d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3 d3d3dwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAd3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3 d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3cAAAB///AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAHAAAHAHAAcAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAf//wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAABwBwAHAABwAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAH//8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAAcAcABwAAcA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAHcABwAHAAdwAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAf//wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwd3AABwAHB3cAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAH//8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB///AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAH//8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB///AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAf//wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAH//8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB///AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAABwAAAHdwAAAAAHB3cAAHAAcAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAf//wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAAcABwAAAAB3AAcABwAHAABwAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAH//8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAABwAABwAA AAcAAAcAcABwAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB///AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA cAAAAHAAd3cAAAAAcAAAd3AAAAAAB3cAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAABwAAcAAAcHd3AHAAAHAHAAcAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAf//wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAHAAAAcABwAAcAAAAHAABwAHAAAAAHAAcAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAHAAAHAAAABwAABwBwAHAABwAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAH//8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAABwAAcAAHAAAABwAHAAAHAA AAcAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAABwAABwAA AAcAAAcAcABwAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB///AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA cAAAcAAHAABwd3d3dwAAAABwAAAHAAAHB3dwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAABwAAcAAAcAAAAHAAAHAHAAcAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAf//wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAHAABwAAAAAAcHAAAHAAAAAAcAAABwAABwAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAHAAAHAAAAB3AAcABwAHcABwAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAH//8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB3d3dwAAAAAHAHAABwAAAAAHAA AABwAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAHAABwAABwAA AAcHdwAAcABwd3AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB///AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA cAAABwAAAABwAHAAcABwAAcAAAAAB3cAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAHBwAAcAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAf//wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAHAAAABwAAAAcAAHAHAAd3dwAAAAAHAAcAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHcAAAcABwAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAH//8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAcAAAAHAABwBwAHAAAAAA AAcAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAd3AAAA AAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB///AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA cAAAAHAAAABwAABwcAAHAAAAAAAHAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAHAAAAcAAAAAcAAAB3AABwAAAAAAAHAAcAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAH//8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB3d3dwAAAAAHAAAABwAAd3d3AA AAAHdwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB///AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAf//wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAd3cAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAH//8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAcAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB///AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAf//wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAB3d3dwAABwAAB3cHAHAAAABwAAAAcAB3dwAAAABwAAB3cAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAH//8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAABwAAcAAHAAdwBwAAAA cAAABwAHAABwAAAAcAAHAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB///AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAHAAAABwAHAAcAAAcAcAAAAHAAAHAABwAAcAAAAHAAcAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAf//wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAHAAAABwAAd3AABwd3AAAAd3AAB3cHAAAHdwAAd3cAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAABwBwAHAAAHAHAAAABwAABwAAcAAHB3d3d3AAAAAHAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAH//8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAHAABwAHAAdwAHAABwAHAAcA BwAAcABwBwAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAAAAcAcABwAABwBwAAAA cAAHAAAAAABwcAAAcAAAAABwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB///AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcA AAcAAHAAAHAHAAAHAHAAAHAHAAcABwAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAHAAAAAHAHAAcAAAcAcAAAAHd3d3AAAAAAcAcAAHAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAf//wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAHAAAHAABwAABwBwAABwBwAABwBwAHAAcAAAAAAABwAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAABwBwAHAAAHAHAAAABwAAAHAAAAAHAAcABwAHAABwAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAH//8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAcAAAcAAAcAcAAAcAcAAAcAcA BwAHAAAAAHd3AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAAAAcAcAAHAAdwBwAAAA cAAAAHAAAABwAAcAcAB3d3AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB///AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAd3 d3cAAHAAAHAHAAAHAHAAAHAHAAcABwAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAHAAAAAHAHAAAHdwcAcAAAAHAAAABwAAAAcAAHAHAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAf//wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAHAAAAcABwAABwBwAABwBwAABwBwAHAAcAAAAHAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAcAAAAAAAAAAAAAAABwAAAAcAAAAHAAAHBwAAcAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAH//8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAcABwAHAAdwAHAABwAHAAcA BwAAcABwBwAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAABwAAAAAAAAAAAAAAAA cAAABwAAAABwAAAHcAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB///AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcA AAAHAAB3cAAHB3cAAAB3cAB3dwcAAAd3AAB3dwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAHd3d3AAAHAAAAAAAAcAAAAHd3d3AAAAAAcAAAAHAAB3d3cAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAf//wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAHAAAABwAAAAAABwAAAAAAAAAABwAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAH/wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAHAAAAAAAAcAAAAAAAAAAAcA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB///AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAd3 d3cAAAAAAAAHAAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAf//wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAH//8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB///AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAf//wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAH//8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB///AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAf//wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAH//8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB///AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAB3d3AAAAd3dwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAf//wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAHAABwAABwAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAH//8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAAAHAHAAAABw AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB///AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAHAAAABwAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAf//wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAcAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAH//8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAAAHAAAAB3cA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB///AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAHAAAABwAAd3AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAf//wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAcABwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAH//8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAAAHAHAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB///AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAHAAAABwBwAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAf//wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAcABwAABwAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAH//8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAAAHAAB3d3AA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB///AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAf//wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAH//8= ------_=_NextPart_000_01BEAC10.F7AFCB60 Content-Type: text/plain; name="MP16I.TXT" Content-Disposition: attachment; filename="MP16I.TXT" Content-Location: ATT-2-E9FB5CE8EE17D311909100805F15BDC8-M P16I.TXT U.S. Robotics 16-port Modem Pool <131.5.2.173> 1 USR Octal Modem NAC B7980FNL 1UJ000 2.0.0 2.0.8 2 USR Octal Modem NAC B7980FNL 1UJ000 2.0.0 2.0.8 3 USR Modem Pool Management Card B658VP75 1EO 2.0 1.0.2 ------_=_NextPart_000_01BEAC10.F7AFCB60--
Subject: Re: (usr-tc) Re: your mail
From: Alessandro Alves <aalves@mpcnet.com.br>
Date: 1999-06-01 08:47:54
--=====================_82606281==_.ALT Content-Type: text/plain; charset="us-ascii" Use the following command: sh interface slot:x/mod:x Alessandro Alves U.S. Robotics/Network Consultant aalves@ntwxpress.com.br fone 55 11 214 4552 fax 55 11 258 7895 At 01:28 PM 5/31/99 -0300, you wrote: >On Wed, 26 May 1999 chaos@zebra.net wrote: > >|ok I need to figure out the harc command for current transmit speed >|I know I could get this from snmp so if someone knows the particular oid that >|may be helpful as well for a script im writing >|I have no quads so its all hiper hardware > > Here are some OIDs I use to monitor the connections: > >'mdmCsModulationType' => '.1.3.6.1.4.1.429.1.6.9.1.1.14' >'mdmCsFinalTxLinkRate' => '.1.3.6.1.4.1.429.1.6.9.1.1.12' >'mdmCsFinalRxLinkRate' => '.1.3.6.1.4.1.429.1.6.9.1.1.13' >'mdmCsErrorControlType' => '.1.3.6.1.4.1.429.1.6.9.1.1.16' >'mdmCsCompressionType' => '.1.3.6.1.4.1.429.1.6.9.1.1.17' >'mdmCsGainHitCount' => '.1.3.6.1.4.1.429.1.6.9.1.1.37' >'mdmCsCallDuration' => '.1.3.6.1.4.1.429.1.6.9.1.1.39' >'mdmCsQSNR' => '.1.3.6.1.4.1.429.1.6.9.1.1.61' >'mdmCsQRndTripDly' => '.1.3.6.1.4.1.429.1.6.9.1.1.64' >'mdmCsDigitalPadAttenuated' => '.1.3.6.1.4.1.429.1.6.9.1.1.87' >'mdmCsFallbackQty' => '.1.3.6.1.4.1.429.1.6.9.1.1.34' >'mdmCsBlerQty' => '.1.3.6.1.4.1.429.1.6.9.1.1.32' >'mdmCsCharsLost' => '.1.3.6.1.4.1.429.1.6.9.1.1.30' > > > >- Marcelo > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > --=====================_82606281==_.ALT Content-Type: text/html; charset="us-ascii" <html> Use the following command:<br> <br> sh interface slot:x/mod:x<br> <br> <br> Alessandro Alves<br> <font color="#0000FF"><b>U.S. Robotics/Network Consultant<br> aalves@ntwxpress.com.br<br> fone 55 11 214 4552<br> fax 55 11 258&nbsp; 7895<br> <br> <br> </font></b><font color="#000000">At 01:28 PM 5/31/99 -0300, you wrote:<br> &gt;On Wed, 26 May 1999 chaos@zebra.net wrote:<br> &gt;<br> &gt;|ok I need to figure out the harc command for current transmit speed <br> &gt;|I know I could get this from snmp so if someone knows the particular oid that<br> &gt;|may be helpful as well for a script im writing<br> &gt;|I have no quads so its all hiper hardware <br> &gt;<br> &gt;<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>Here are some OIDs I use to monitor the connections:<br> &gt;<br> &gt;'mdmCsModulationType'&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =&gt; '.1.3.6.1.4.1.429.1.6.9.1.1.14'<br> &gt;'mdmCsFinalTxLinkRate'&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =&gt; '.1.3.6.1.4.1.429.1.6.9.1.1.12'<br> &gt;'mdmCsFinalRxLinkRate'&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =&gt; '.1.3.6.1.4.1.429.1.6.9.1.1.13'<br> &gt;'mdmCsErrorControlType'&nbsp;&nbsp;&nbsp;&nbsp; =&gt; '.1.3.6.1.4.1.429.1.6.9.1.1.16'<br> &gt;'mdmCsCompressionType'&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =&gt; '.1.3.6.1.4.1.429.1.6.9.1.1.17'<br> &gt;'mdmCsGainHitCount'&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =&gt; '.1.3.6.1.4.1.429.1.6.9.1.1.37'<br> &gt;'mdmCsCallDuration'&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =&gt; '.1.3.6.1.4.1.429.1.6.9.1.1.39'<br> &gt;'mdmCsQSNR'&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =&gt; '.1.3.6.1.4.1.429.1.6.9.1.1.61'<br> &gt;'mdmCsQRndTripDly'&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =&gt; '.1.3.6.1.4.1.429.1.6.9.1.1.64'<br> &gt;'mdmCsDigitalPadAttenuated' =&gt; '.1.3.6.1.4.1.429.1.6.9.1.1.87'<br> &gt;'mdmCsFallbackQty'&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =&gt; '.1.3.6.1.4.1.429.1.6.9.1.1.34'<br> &gt;'mdmCsBlerQty'&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =&gt; '.1.3.6.1.4.1.429.1.6.9.1.1.32'<br> &gt;'mdmCsCharsLost'&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =&gt; '.1.3.6.1.4.1.429.1.6.9.1.1.30'<br> &gt;<br> &gt;<br> &gt;<br> &gt;- Marcelo<br> &gt;<br> &gt;<br> &gt;-<br> &gt; To unsubscribe to usr-tc, send an email to &quot;majordomo@xmission.com&quot;<br> &gt; with &quot;unsubscribe usr-tc&quot; in the body of the message.<br> &gt; For information on digests or retrieving files and old messages send<br> &gt; &quot;help&quot; to the same address.&nbsp; Do not use quotes in your message.<br> &gt; </font></html> --=====================_82606281==_.ALT--
Subject: Re: (usr-tc) Why won't HiperDSP Port 1 of 23 connect?
From: David C Hatch <david.c.hatch@chi.frb.org>
Date: 1999-06-01 09:35:49
smart move. when did you try that? is it possible we set anything up differently on the first channel, or that it is the d channel, rather than 24 somehow? Peter Olson 05/28/99 04:09 PM Please respond to usr-tc@lists.xmission.com To: usr-tc@lists.xmission.com cc: (bcc: David C Hatch/ITS/CHI/FRB07) Subject: (usr-tc) Why won't HiperDSP Port 1 of 23 connect? Hi, Question: Has anyone ever seen one channel of a HiperDSP ISDN/PRI go bad in hardware/software? Circumstances: 1. We upgraded to the 2.0.19 HiperDSP drivers from 1.2.59. No problems with previous provider so far as we know. 2. We have just performed a cutover of a backup/test system from one service provider to another to take advantage of much lower rates. We ran into some provisioning trouble, since MCI did not know about 3COM owning the USR TC, past that they get the service turned up, calls from a USR modem client would not connect. When we busied out the first channel, every other channel worked. Question2: Should I be going after the service provider or start looking for a hardware solution? We did not have another HiperDSP card to try out. Question3: Should we back off of the 2.0.19 drivers? Any help would be appreciated. Regards, --Peter Olson - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.
Subject: (usr-tc) List archive
From: Pete Ashdown <pashdown@xmission.com>
Date: 1999-06-01 10:47:16
John Schmerold said once upon a time: > >Where is this list archived? > >I accidently deleted several scripts ftp://ftp.xmission.com/pub/lists/usr-tc/archive
Subject: (usr-tc) 4 Sale
From: Jim Logan <jim@top.net>
Date: 1999-06-01 10:48:23
Accepting Offers if you don't like the price: 1- NetServer 486 20 Meg PRI Card $ 725 1- NMC Card 20 Meg, 8 Meg ROM $ 625 2- 45 Amp Power Supplies $ 140 Ea 1 - TC Chassis (Empty Chassis) $ 50 1- Cisco Cable - New Unopened, PT# 72-0791-01, CAB-V35MT $55 ******* Top Net InterNet Services ******** Omaha, Nebraska www.top.net Voice: (402) 339-5609
Subject: Re: (usr-tc) 4 Sale
From: access1 <access1@simplyweb.net>
Date: 1999-06-01 11:11:24
jim- is that a 45 amp or 70 amp chassis??? Jim Logan wrote: > Accepting Offers if you don't like the price: > > 1- NetServer 486 20 Meg PRI Card $ 725 > 1- NMC Card 20 Meg, 8 Meg ROM $ 625 > 2- 45 Amp Power Supplies $ 140 Ea > 1 - TC Chassis (Empty Chassis) $ 50 > 1- Cisco Cable - New Unopened, PT# 72-0791-01, CAB-V35MT $55 > > ******* Top Net InterNet Services ******** > Omaha, Nebraska www.top.net > Voice: (402) 339-5609 > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message.
Subject: (usr-tc) quick analog modem question
From: Jolliffe, Anu <ajolliffe@imagen.net>
Date: 1999-06-01 12:32:54
I have 10 Analog only modems in a TC rack connected to an NT machine using RRAS through Digiboards. Can I install a Netserver card, ditch the Digiboards and have the modems go through the Netserver card authenticated by a RADIUS server? Or, do I need to replace the Analog modems with A/D's before being able to use the Netserver? Thanks.
Subject: Re: (usr-tc) MAC's and their 56K global village modems
From: Horace Demmink <horace@pathwaynet.com>
Date: 1999-06-01 12:44:10
Does anyone know what can be done, short of turning off V.90, to get the 56K modems on the newer Blue G3's to work well with the Hipers. On Fri, 28 May 1999, Andy Berkvam wrote: > On Fri, 28 May 1999 pferraro@wna-linknet.com wrote: > > > We need a little guidance here.... THe newer Macs have this 56k modem > > in it; sometimes they connect and sometimes they don't. Need to know if > > there is ANYTHING that we can tell the user to change on the client end, > > that will make these connections work all the time? > > > The modem is Rockwell-based. We've had good luck in making sure that > the Macs have the latest firmware update from Apple which updates the > modems to the 2.200 Rockwell code. > > If the 56K modem is in a "beige" Mac, go to > <http://asu.info.apple.com/swupdates.nsf/artnum/n11206> to download the > latest firmware. > > If the modem came with a PowerBook G3 Series or iMac, get the latest > firmware from <http://asu.info.apple.com/swupdates.nsf/artnum/n11315>. > > > I remember reading something about turning off the comperssion on their > > end? Also, is there a place we can place a string to make them do only > > v.34? > > > If the Mac is using its built-in PPP software, it uses modem scripts to > change modem settings. The latest updates for the iMac include a script > that will set the modem to V.34-only. If you want to download this script > separately, go to <http://asu.info.apple.com/swupdates.nsf/artnum/n11128>. > > Otherwise you could use alternate PPP software like FreePPP > <http://www.rockstar.com/> which lets you directly enter init strings. > > Andy > > -- Horace Demmink PathWay Computing
Subject: Re: (usr-tc) NO Phone support?
From: Ricky Beam <jfbeam@beaker.interpath.net>
Date: 1999-06-01 13:14:31
On Fri, 28 May 1999, Jeff Mcadams wrote: >Hah...just try it! If you don't have a support contract, they'll >transfer you to logistics to buy a support contract...period. Or just hang up on you. And in one case, they opened a ticket and then closed a few minutes later "No support contract; do not open a new ticket." >Heh...now this is almost funny. 3Com tech support, for the most part, >has been almost useless for any but the most basic of questions. I Well, this isn't Cisco TAC. The 3Com support "toadies" aren't extensively trained on the hardware nor are they likely to be motivated to learn much of it. If they do become a knowledgable asset, then they moved further up the call chain. (Sad.) >can't even report a bug to them through normal channels because they >won't talk to me because I don't have a support contract. You'd think "That's not a bug; that's a stupid user." Without a support contract, why should they bother figuring out if there realy is a problem? </sarcasm> >that tech support would be interested in hearing about a bug in their >software whether the person reporting it has a support contract or not. >Instead, I had to get the information to Mike Wronski and Tatai Krishnan >via this list (who handled it quite well, a pleasant difference from >calling in to tech support). If you're part of an alpha/beta test group, then you can usually get people to listen with or without a support contract. I didn't have a contract for almost a year while working with several betas and the arc 4.2 alpha (which is now in beta.) However, I no longer work for an ISP (and they didn't give a hoot about their [six figure] investment in 3Com hardware. [They opted to replace it with [seven figures] of Cisco hardware we'd never touched. Eight months later, they still have not replaced the USR modem hardware. But, I digress.]) As I was told, a great many of the bugs in the database were reported by me. (I don't know if it's true, but I pointed out _alot_ of crap. Some of it got fixed quickly; some of it fell through the cracks.) >>As with any organization, you may not always get the most senior >>technician when you call, but the resources at your disposal at 3COM >>are immense. > >*If* you can get to them...that's the huge problem here...getting past Maybe it's time I shared my 3Com phone list :-) >the first person that answers the phone and wants access to log into >your box directly is an absolute nightmare...made even more frustrating >because, at least for people on this list by and large, we know more >than the first level folks do about this equipment! And 90% of us are doing things that make the engineers who programmed the stuff in the first place run away in horror. (We're not evil; we're just doing our job.) >Hah...I wish...I've point blank asked to be transferred to second level >tech support and been refused...maybe they're getting better with >this...but I haven't seen any evidence of it yet. That's when you call the thrid level tech directly :-) >However, these people, are typically the people that are willing to dig >in and really learn the equipment inside and out...and 3Com really does >a pitiful job of giving people like this support. I've found that 3Com >provides the best support for people that want their equipment just to >work, and don't care to know how to set it up to get it to work....this >dovetails very nicely with 3Com's first level tech support, who >invariably seems to want to log into your box themselves and do the work >themselves without telling you what they are doing. Well, now being one of those to "hand hold" people through things, it's alot faster to just do it than explain (character by character) how to do some things to people who just don't get it. (Yes, I spent an hour trying to get someone to run 'truss -o /tmp/trace -f -l {program}'...) >>Once a new product is established and stable 3COM usually responds very >>quickly to feature requests that make sense. > >OSPF on the NETServer card...'nuff said. I'd settle for a netserver code base that _WORKS_. (not this livingston crap shoe-spooned into the wrong hardware.) >>Anyone else would have to be at least a little behind the power curve >>on existing issues, new features, emerging technologies that will be >>supported, etc. > >Yeah...and 3Com's first and maybe second level tech support seems to be >too! :) Then again, how many times has 3Com built anything to any standard without "improving" on it? --Ricky
Subject: Re: (usr-tc) One More Radius Question
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1999-06-01 13:17:36
User Error Input from user is in error, causing termination of session. 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 Tue, 1 Jun 1999, Marcelo Souza wrote: > > What does "User-Error" means as a "Acct-Terminate-Cause" in Radius > log? > > > - Marcelo > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >
Subject: Re: (usr-tc) 4 Sale
From: Jim Logan <jim@top.net>
Date: 1999-06-01 13:27:51
This Chassis is the same Chassis that the dual 45 Amp Power Supplies are now sitting in. At 11:11 AM 6/1/1999 -0700, you wrote: >jim- >is that a 45 amp or 70 amp chassis??? > >Jim Logan wrote: > >> Accepting Offers if you don't like the price: >> >> 1- NetServer 486 20 Meg PRI Card $ 725 >> 1- NMC Card 20 Meg, 8 Meg ROM $ 625 >> 2- 45 Amp Power Supplies $ 140 Ea >> 1 - TC Chassis (Empty Chassis) $ 50 >> 1- Cisco Cable - New Unopened, PT# 72-0791-01, CAB-V35MT $55 >> >> ******* Top Net InterNet Services ******** >> Omaha, Nebraska www.top.net >> Voice: (402) 339-5609 >> >> >> - >> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" >> with "unsubscribe usr-tc" in the body of the message. >> For information on digests or retrieving files and old messages send >> "help" to the same address. Do not use quotes in your message. > > > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > > ******* Top Net InterNet Services ******** Omaha, Nebraska www.top.net Voice: (402) 339-5609
Subject: Re: (usr-tc) One More Radius Question
From: Stephen Amadei <amadei@dandy.net>
Date: 1999-06-01 14:15:42
On Tue, 1 Jun 1999, Marcelo Souza wrote: > > What does "User-Error" means as a "Acct-Terminate-Cause" in Radius > log? It means there was a problem setting up the PPP/slip connection. I've seen this happen when users try to use the same IP as my nameserver, gateway, yahoo, etc. I think it also happens if the userid or password is wrong. Unfortunately, many of the other "User Errors" (accidentally turning off the computer, tripping on the modem cord, using Windows 9X ;-) ), seem to come up with the euphanism "Lost Carrier"... ----Steve Stephen Amadei Director of MIS Dandy Connections, Inc. Atlantic City, NJ
Subject: (usr-tc) One More Radius Question
From: Marcelo Souza <mpsouza@centroin.com.br>
Date: 1999-06-01 14:50:01
What does "User-Error" means as a "Acct-Terminate-Cause" in Radius log? - Marcelo
Subject: Re: (usr-tc) quick analog modem question
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1999-06-01 15:24:48
On Tue, 1 Jun 1999, Jolliffe, Anu wrote: > I have 10 Analog only modems in a TC rack connected to an NT machine using > RRAS through Digiboards. Can I install a Netserver card, ditch the > Digiboards and have the modems go through the Netserver card authenticated > by a RADIUS server? Or, do I need to replace the Analog modems with A/D's > before being able to use the Netserver? > You need either digital or analog/digital modems to use a NETServer card. You cannot use the analog only modems. Once you get the analog/digital or digital modems then you can use PPTP to do the same that you are doing now. krish > Thanks. > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >
Subject: Re: (usr-tc) NO Phone support?
From: Kevin Benton <s1kevin@tims.net>
Date: 1999-06-01 15:48:04
Hey Jeff - this list is a good resource, but have you talked with your 3Com sales rep to find out who your NC is and maybe you could get some help there... 3Com support people are *not* supposed to be denying you 90 day warranty support. We have been using 90 day support now for quite some time (thanks to a continual inflow of chassis'). Our sales rep has done quite a bit to help change our attitudes as of late. Still not the best in the world, but a lot better... I just wish it was possible to get a warranty support contract number every time we register a new chassis. (Krish? :) :) :) Kevin Benton SOTA Technologies On Fri, 28 May 1999, Jeff Mcadams wrote: > Date: Fri, 28 May 1999 10:36:39 -0400 (EDT) > From: Jeff Mcadams <jeffm@iglou.com> > Reply-To: usr-tc@lists.xmission.com > To: usr-tc@lists.xmission.com > Subject: Re: (usr-tc) NO Phone support? > > Well...some agreement...some disagreement... > > Thus spake ISPCnsl001@aol.com > >Time to get on my soap box: Solunet does have some good people working > >for them, but tech support isn't really meant to be used for hand > >holding. You are authorized to call in to 3COM's when you are still > >under warranty for any legitimate problems. > > Hah...just try it! If you don't have a support contract, they'll > transfer you to logistics to buy a support contract...period. > > >After the warranty period is expired you should be beyond hand holding > >and ready to move on to tougher issues. > > I'll agree with this...the "should be" part...but unfortunately, real > life rears its ugly head. > > >The true value of 3COM's tech support comes into play when you need > >help beyond initial setup. > > Heh...now this is almost funny. 3Com tech support, for the most part, > has been almost useless for any but the most basic of questions. I > can't even report a bug to them through normal channels because they > won't talk to me because I don't have a support contract. You'd think > that tech support would be interested in hearing about a bug in their > software whether the person reporting it has a support contract or not. > Instead, I had to get the information to Mike Wronski and Tatai Krishnan > via this list (who handled it quite well, a pleasant difference from > calling in to tech support). > > >As with any organization, you may not always get the most senior > >technician when you call, but the resources at your disposal at 3COM > >are immense. > > *If* you can get to them...that's the huge problem here...getting past > the first person that answers the phone and wants access to log into > your box directly is an absolute nightmare...made even more frustrating > because, at least for people on this list by and large, we know more > than the first level folks do about this equipment! > > >I have been able to get answers to literally thousands of very high > >level off the wall questions over the years. All you have to do is > >ask. If the person you are talking to doesn't know the answer ask > >him/her to ask a team leader or a product specialist in the next level. > >It's that easy. > > Hah...I wish...I've point blank asked to be transferred to second level > tech support and been refused...maybe they're getting better with > this...but I haven't seen any evidence of it yet. > > >Some people don't need access to these resources and that's fine. If > >all you are doing with your equipment is a basic default setup then you > >probably don't need it either. However, more and more customers want > >their equipment to do a number of things that the default configuration > >doesn't provide or that, perhaps, a feature does not exist for. > > However, these people, are typically the people that are willing to dig > in and really learn the equipment inside and out...and 3Com really does > a pitiful job of giving people like this support. I've found that 3Com > provides the best support for people that want their equipment just to > work, and don't care to know how to set it up to get it to work....this > dovetails very nicely with 3Com's first level tech support, who > invariably seems to want to log into your box themselves and do the work > themselves without telling you what they are doing. > > >Once a new product is established and stable 3COM usually responds very > >quickly to feature requests that make sense. > > OSPF on the NETServer card...'nuff said. > > >Solunet, or anyone else for that matter, cannot compete with the kind > >of experience 3COM has, as a whole; talking to thousands of new and > >existing customers each month. > > But the problem is....3Com has the possibility, but they don't seem to > learn from it! > > >Anyone else would have to be at least a little behind the power curve > >on existing issues, new features, emerging technologies that will be > >supported, etc. > > Yeah...and 3Com's first and maybe second level tech support seems to be > too! :) > > I recently had a private email exchange with a 3Com tech support dude > that started in the totalservice newsgroup fora. I'll include the last > message of that below...this is the message where I expound on my > thoughts about 3Com's tech support. The origination of this thread was > someone in the newsgroup asking about how to do a software download to > the cards from a unix command line...the tech responded with information > about pcsdl and tcm, and that was it. I responded with more > information with a bit of an attitude (gee...I bet that surprises > regular readers of this list :), and he responded asking why I was so > down on 3Com. :) My response follows: > > ----------------------------------------------------------------------- > > >unless you want to right specific code on HPOV or similar gui to match > >the mibs of the nmc's send request for the sdl and nac files -- then > >tcm is the way to go -- thanks for the over clarification jeff -- > > Except for the fact that the guy was specifically asking about command > line, not GUI, :) and it can be done on the command line...not *quite* > as simply as he was thinking it was, but not too terribly more difficult > either. :) > > >you may have noticed that I also included the sdl version .... > > True...and that certainly is good information...though I can't remember > the last time I did an sdl to a quad...a lot of the people that I talk > to don't even have quad nic's to do sdl's with. We keep a few around > just for this reason, but have never had a reason to need to do it. > > >I do respect your opinions , and you are certainly a valuable asset to > >this forum -- I sometimes feel that you look for ways to disvalue > >anything that comes from 3com - why split hairs on the gui? > > I guess I do kind of look for ways to disvalue things from 3Com...maybe > a little. I think, mainly, that I'm frustrated with 3Com. Let me see > if I can explain where I'm coming from here. > > I see about 3 different levels of TC users. > > First, you have what I call "cluebies" :) (I'm gonna stereotype here > big time...be forewarned...these are generalizations) This is typically > gonna be a guy with one rack, running an ISP out of his basement. :) > He runs S&A on an NT box, has never seen Unix, and thinks running an ISP > is a turnkey thing. :) This type of person doesn't want to learn about > the equipment he uses...he wants to turn it on and have it just work. > Of course, you and I both know that this just isn't gonna happen. > > Second, you have the group of people that I think I would place myself > in. People that are curious, want to learn the inner workings of the > equipment and how to make use of it to its fullest. These types of > people are going to learn the intricate ins and outs of the TC equipment > with 3Com's help or not. :) They typically run Unix, and would cringe > to sit down at a computer with any software from MS on it. :) > > Third, you have a group of people that fall somewhere
Subject: (usr-tc) 3com NFAS Support
From: Mark Lemmert <cto@athenet.net>
Date: 1999-06-01 15:50:46
The last time I investigated NFAS support on the Total Control gear, the quad modems could support it but not multi-chassis and the DSPs couldn't support it at all. Can anybody tell me what NFAS support is currently there, specifically with the HiperDSP cards? If it is supported is it reliable? Thanks! Mark Lemmert AthEnet Data Exchange Chief Technical Officer 888-919-8700
Subject: Re: (usr-tc) NO Phone support?
From: Kevin Benton <s1kevin@tims.net>
Date: 1999-06-01 16:24:08
> On Fri, 28 May 1999, Jeff Mcadams wrote: > >Hah...just try it! If you don't have a support contract, they'll > >transfer you to logistics to buy a support contract...period. > > Or just hang up on you. And in one case, they opened a ticket and then > closed a few minutes later "No support contract; do not open a new ticket." That's when you call your 3Com sales rep and gripe about personally providing legally required warranty support... At that point, they'd probably send you to one of the NC's (which, by the way, have consistently proven to be level three quality to me). Try it... Been there, done that, worked great. Needless to say, I have my NC's pager number, email, etc. If I have a real stumper, or a bug report, I go directly to him. Do not pass go, do not collect $200,000 (inflation). I recently spent a couple of days in training at Rolling Meadows and gathered a bunch of previously unknown information on Total Control. The training was put on by the midwest sales team specifically for ISP's. It was extremely valuable and worth every bit of the $1,000 we spent on the free class (travel, hotel, time, etc). We've been using TCM, etc for three years and the class still taught us a bunch about stuff we'd never used in TCM before. > That's when you call the thrid level tech directly :-) Amen! :) Kevin Benton SOTA Technologies E-Mail: s1kevin@tims.net Web: http://users.sota-oh.com/~s1kevin/ Unsolicited advertisements processing fee: $50 subject to change without notice
Subject: Re: (usr-tc) quick analog modem question
From: Alessandro Alves <aalves@mpcnet.com.br>
Date: 1999-06-01 17:04:42
Hi, you can install the NetServer card ou Hiper Access Router Card and authenticate through ethernet to Radius Server, you only need replace to quad A/D if you use a digital phone line (E1/T1 line, 30 or 24 lines). In this case you will need a Dual E1/T1 card too. At 12:32 PM 6/1/99 -0700, you wrote: >I have 10 Analog only modems in a TC rack connected to an NT machine using >RRAS through Digiboards. Can I install a Netserver card, ditch the >Digiboards and have the modems go through the Netserver card authenticated >by a RADIUS server? Or, do I need to replace the Analog modems with A/D's >before being able to use the Netserver? > >Thanks. > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >
Subject: Re: (usr-tc) NO Phone support?
From: Ricky Beam <jfbeam@beaker.interpath.net>
Date: 1999-06-01 17:48:42
On Tue, 1 Jun 1999, Kevin Benton wrote: >> Or just hang up on you. And in one case, they opened a ticket and then >> closed a few minutes later "No support contract; do not open a new ticket." > >That's when you call your 3Com sales rep and gripe about personally >providing legally required warranty support... At that point, they'd Well, I was well beyond the 90 day warranty... And yes, the very next call was to that toady's manager, the manager's manager, and our sales rep. Bitch; Bitch loudly and to as many managers as you can find :-) --Ricky
Subject: Re: (usr-tc) One More Radius Question
From: Marcelo Souza <mpsouza@centroin.com.br>
Date: 1999-06-01 17:54:11
On Tue, 1 Jun 1999, Stephen Amadei wrote: |On Tue, 1 Jun 1999, Marcelo Souza wrote: |> |> What does "User-Error" means as a "Acct-Terminate-Cause" in Radius |> log? | |It means there was a problem setting up the PPP/slip connection. I've |seen this happen when users try to use the same IP as my nameserver, |gateway, yahoo, etc. I think it also happens if the userid or password is |wrong. Ok, but what should be when it happen after almost 1 hour of connection ? Acct-Session-Time = 3349 Acct-Terminate-Cause = User-Error |Unfortunately, many of the other "User Errors" (accidentally turning off |the computer, tripping on the modem cord, using Windows 9X ;-) ), |seem to come up with the euphanism "Lost Carrier"... BTW, comparing with the number of "User-Request", which is the percentage of "Lost-Carrier" do you have? How much can I consider normal? - Marcelo
Subject: Re: (usr-tc) 3com NFAS Support
From: Ricky Beam <jfbeam@beaker.interpath.net>
Date: 1999-06-01 17:55:26
On Tue, 1 Jun 1999, Mark Lemmert wrote: >The last time I investigated NFAS support on the Total Control gear, the quad >modems could support it but not multi-chassis and the DSPs couldn't support >it at all. > >Can anybody tell me what NFAS support is currently there, specifically with the >HiperDSP cards? If it is supported is it reliable? Thanks! To split hares <grin>, the quad's don't care about NFAS, the DUAL PRI does. NFAS is support on the Dual PRI card between the two spans. As far as I am aware, the DPRI cannot share a D channel across multiple cards??? NFAS is support (as of TCS3.5) on the DSP cards with the same chassis. There may be a limit on the number of cards per D channel, but I'm not aware of any (nor am I aware of anyone running 14 DSPs on a single D channel.) --Ricky Disclaimer: I don't like NFAS. I've only used it once for a few days to avoid having to argue with a Sprint (Carolina Telephone) tech. (This _was_ the _first_ PRI they'd ever provisioned -- yuk! In fact, they still think it's 23+1 + 24.)
Subject: Re: (usr-tc) Terminate Reasons...
From: Stephen Amadei <amadei@dandy.net>
Date: 1999-06-01 18:22:48
On Tue, 1 Jun 1999, Marcelo Souza wrote: > Ok, but what should be when it happen after almost 1 hour of > connection ? You got me there. I haven't seen that one. Perhaps a CHAP challenge? > |Unfortunately, many of the other "User Errors" (accidentally turning off > |the computer, tripping on the modem cord, using Windows 9X ;-) ), > |seem to come up with the euphanism "Lost Carrier"... > > BTW, comparing with the number of "User-Request", which is the > percentage of "Lost-Carrier" do you have? How much can I consider normal? My stats since upgrading to TCS 3.5: Terminate reasons for Total Control moo User-Request 578 Lost-Carrier 157 User-Error 48 Idle-Timeout 6 Admin-Reset 3 Terminate reasons for Total Control acy User-Request 300 Lost-Carrier 135 User-Error 7 Idle-Timeout 1 Admin-Reset 1 Terminate reasons for Total Control pvl User-Request 311 Lost-Carrier 87 User-Error 43 Idle-Timeout 0 Admin-Reset 2 MOO is a hiper chassis with all calls on DSPs... ACY and PVL are both older chassis with Quad cards, but upgraded to HiperARCs... as you can see, the older chassis seems to have more lost carriers... by nearly a factor of 2. I've been at a loss to explain it, but I will also note that the older chassis tend to have slightly higher connect speeds... 49-53.3K as opposed to 45-50K on the DSP cards. I plan on using one of the SNMPTRAP scripts posted here previously to determine if only one or two modems are responsible for this difference in terms. You'll also notice I have few Idle Timeouts... I don't understand this, but is this from stray traffic on my network, or have others had low Idle Terminates, too? Any tips for straining out this stray traffic? I don't use filters currently, and don't wish to censor anyone's connectivity... just reduce this traffic that may be keeping the connections open. Thanx in advance. The script that generated these: (this is an OS/2 script... Unix simular) @echo off echo Terminate reasons for Total Control %1 echo ---------------------------------------- echo User-Request cat c:\mptn\etc\radacct\%1\detail | grep "User-Request" | wc -l echo Lost-Carrier cat c:\mptn\etc\radacct\%1\detail | grep "Lost-Carrier" | wc -l echo User-Error cat c:\mptn\etc\radacct\%1\detail | grep "User-Error" | wc -l echo Idle-Timeout cat c:\mptn\etc\radacct\%1\detail | grep "Idle-Timeout" | wc -l echo Admin-Reset cat c:\mptn\etc\radacct\%1\detail | grep "Admin-Reset" | wc -l ----Steve Stephen Amadei Director of MIS Dandy Connections, Inc. Atlantic City, NJ
Subject: Re: (usr-tc) Terminate Reasons...
From: Marcelo Souza <mpsouza@centroin.com.br>
Date: 1999-06-01 20:26:55
On Tue, 1 Jun 1999, Stephen Amadei wrote: |On Tue, 1 Jun 1999, Marcelo Souza wrote: | |> Ok, but what should be when it happen after almost 1 hour of |> connection ? | |You got me there. I haven't seen that one. Perhaps a CHAP challenge? I don't use CHAP for those users, and the session time may vary from few minutes to an hour, maybe more. |> |Unfortunately, many of the other "User Errors" (accidentally turning off |> |the computer, tripping on the modem cord, using Windows 9X ;-) ), |> |seem to come up with the euphanism "Lost Carrier"... |> |> BTW, comparing with the number of "User-Request", which is the |> percentage of "Lost-Carrier" do you have? How much can I consider normal? | |My stats since upgrading to TCS 3.5: These numbers are very close from those I have here maybe a little higher, I have some thing between 18% to 23% of lost carrier, compared against the "user request". I guess these numbers high and I trying to undestand which are the real reasons. |MOO is a hiper chassis with all calls on DSPs... ACY and PVL are both |older chassis with Quad cards, but upgraded to HiperARCs... as you can |see, the older chassis seems to have more lost carriers... by nearly a |factor of 2. I've been at a loss to explain it, but I will also note that |the older chassis tend to have slightly higher connect speeds... 49-53.3K |as opposed to 45-50K on the DSP cards. | |I plan on using one of the SNMPTRAP scripts posted here previously to |determine if only one or two modems are responsible for this difference in |terms. I did a script to isolate the statiscs for each DSP but the numbers are close: Slot 1 : 20.4 % Slot 2 : 18.4 % Slot 3 : 22.4 % Slot 4 : 20.6 % Slot 5 : 22.1 % Slot 6 : 16.8 % If you want I can send the script to you (no jewel :-). |You'll also notice I have few Idle Timeouts... I don't understand this, |but is this from stray traffic on my network, or have others had low Idle |Terminates, too? Any tips for straining out this stray traffic? I don't |use filters currently, and don't wish to censor anyone's connectivity... |just reduce this traffic that may be keeping the connections open. My numbers for Idle are very few also, but I think ICQ is the main guilty. - Marcelo
Subject: (usr-tc) TCS 3.5, the password / ppp offloading bug
From: Aaron Nabil <nabil@spiritone.com>
Date: 1999-06-01 20:33:34
I just enabled PPP offloading on TCS 3.5, and there is no sign of the "last character corrupted" password bug. -- Aaron Nabil
Subject: (usr-tc) DSP hardware rev's
From: Rick <rickyz@mindspring.com>
Date: 1999-06-01 22:04:16
Anyone know the difference between DSP hardware revs 0.49.0, and 0.53.0? Thanks in advance, Rickyz
Subject: Re: (usr-tc) NO Phone support?
From: K Mitchell <mitch@keyconn.net>
Date: 1999-06-02 00:32:59
At 04:24 PM 6/1/99 -0400, you wrote: >I recently spent a couple of days in training at Rolling Meadows and >gathered a bunch of previously unknown information on Total Control. The >training was put on by the midwest sales team specifically for ISP's. It >was extremely valuable and worth every bit of the $1,000 we spent on the >free class (travel, hotel, time, etc). We've been using TCM, etc for >three years and the class still taught us a bunch about stuff we'd never >used in TCM before. Is there someplace on 3Com's site that has information on when/where these are held? I'd love to see one of these in the northeast somewhere. Kirk Mitchell-General Manager mitch@keyconn.net Keystone Connect http://www.keyconn.net Altoona, PA 814-941-5000 We Unlock the World
Subject: Re: (usr-tc) Terminate Reasons...
From: Kevin Benton <s1kevin@tims.net>
Date: 1999-06-02 10:13:17
On Tue, 1 Jun 1999, Stephen Amadei wrote: > My stats since upgrading to TCS 3.5: > > Terminate reasons for Total Control moo > ---------------------------------------- > User-Request > 578 > Lost-Carrier > 157 > User-Error > 48 > Idle-Timeout > 6 > Admin-Reset > 3 > > Terminate reasons for Total Control acy > ---------------------------------------- > User-Request > 300 > Lost-Carrier > 135 > User-Error > 7 > Idle-Timeout > 1 > Admin-Reset > 1 > > Terminate reasons for Total Control pvl > ---------------------------------------- > User-Request > 311 > Lost-Carrier > 87 > User-Error > 43 > Idle-Timeout > 0 > Admin-Reset > 2 Pre 3.5, we were running 4-12% lost carrier / User Error depending on location normally. We have a mix of t1/quads and dsp's. What would help you is to take a look at the disconnect reasons in the modems themselves. That should prove more helpful. On the quads, if it's enabled, you should be able to use AutoResponse to look at the disconnect reason in the modem itself. > You'll also notice I have few Idle Timeouts... I don't understand this, > but is this from stray traffic on my network, or have others had low Idle > Terminates, too? Any tips for straining out this stray traffic? I don't > use filters currently, and don't wish to censor anyone's connectivity... > just reduce this traffic that may be keeping the connections open. We do this by using a program which monitors idle time for a pattern (peaks at nine minutes five times in a row for example). Kevin Benton SOTA Technologies E-Mail: s1kevin@tims.net Web: http://users.sota-oh.com/~s1kevin/ Unsolicited advertisements processing fee: $50 subject to change without notice
Subject: (usr-tc) Netserver 16I for sale
From: Tony Loosle <tony@tcsourceone.com>
Date: 1999-06-02 11:04:23
This is a new unit we recently purchased. It has never been in use, but has been configured and powered up for about 3 weeks. It has never been registered, so you could still get the 90 support on it. It has v.90 code on it as well. Asking $3,000.00 tony 435-753-2756 - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message. in the middle of > the previous two. These are people that aren't inately curious about > the equipment, but realize they need to learn some of the details in > order to run it well. These people will use either NT or Unix, but > won't use either of them to their full potential. :) > > 3Com does a pretty good job of giving support for the first group of > people. When they call tech support, they're more than willing to let > the tech support person log into their box and do the work and not worry > about what they're doing. > > You do an OK job of supporting the second group. The programming manual > and stuff is out there that we can pour through to get the information > we need to learn what we want. It'd be *nice* to have some better > support avenues from 3Com, but we can make due with what's there. > > The last group is where I think 3Com really drops the ball. This is the > group that, if 3Com were to put a bit of effort into it, could be taught > enough about using the equipment that they could be self-supporting > (like the group that I'm in) in a bit of time. Short-term, it may be a > bit more expensive for 3Com to provide them this support...but long-term your > support costs for these people is going to be much lower. Once they > learn the ins and outs of the equipment, they'll be pretty much > self-supporting and won't tie up your tech support folks. > > I guess you could take this point and generalize it even further...3Com > seems to always look at what's the best answer to things in the > short-term. They never seem to look at the long(er)-term. To pick out > another couple of examples here. Continuing to charge for x2 enable > keys, for example, short-term, its a win because you get the revenue > from people buying the enable keys...long-term, you loose because you're > ticking off your customers even more and they're deciding to switch to > new vendors of equipment (Lucent commonly) because of this. Another > example, support contracts. 3Com's support contract rules are > insane...they seem designed to get the greatest revenue from the support > contracts, even if it means ticking off your customers, again, > short-term, 3Com gets more revenue, long-term you loose it because > people start refusing to get support contracts at all (we don't have one > because 3Com was gouging us on them IMHO) and start talking about > pirating the code (witness some of the discussion wrt TCS 3.5) to get > around not having access on the web site. The other long-term loss for > 3Com in these examples is the bad publicity that 3Com gets from this. > Your customers feel like they're getting screwed over, and they really > are, so they let people know about it. This is probably part of the > reason that 3Com's stock price is at about the same place it was over 3 > years ago, honestly. > > Anyway...I, honestly, don't have a great deal of respect for 3Com > corporately at the moment...there are certainly individuals that work > for 3Com that I have respect for...Mike Wronski and Tatai Krishnan are > definitely both very sharp techs that I deal with regularly on > usr-tc...Tom Goodman is our sales rep, and he's definitely on the ball. > But, overall, 3Com doesn't seem to be dealing with its customers very > well. Please don't take this as a personal insult...its certainly not > meant that way. You thanked me for my "over clarification", but my > thought is that your answer didn't go far enough. The guy was asking > about command line methods of doing modem upgrades, and, to be honest, > your answer didn't touch on that at all. > > Another thought just occured to me that's at least tangential to these > issues. There are a *ton* of tools out there written by third parties > to assist in managing TC racks. As an example...Mike Andrews (from > dcr.net...he's on the usr-tc list as well) has a whole list of perl > scripts that he's written that basically mimic various functions of > TCM...completely perl, and run on command lines. > http://www.dcr.net/~mandrews/usrtoys/mystuff.shtml It would be *really* > cool if 3Com could start really giving some support to people doing > stuff like this. Even just having a contrib software area on > totalservice would be great. Some of this stuff is *really* good. > [snip a bit that needs to remain private] > > Anyway...I've babbled long enough. :) To summarize, 3Com is good at > supporting "cluebies". I think they need to start better supporting the > people that are really willing and even eager to really dig into the TC > stuff and their their way around it really well. Long-term, this would > be a win for 3Com as it would lower support costs, improve 3Com's > image...particularly among the more knowledgeable people about this > type of equipment, and make the overall tone of 3Com's public tech > support fora (both the totalservice newsgroups/mailing lists, and > non-3Com run groups like usr-tc) much more positive. :) > -- > Jeff McAdams Email: jeffm@iglou.com > Head Network Administrator Voice: (502) 966-3848 > IgLou Internet Services (800) 436-4456 > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > E-Mail: s1kevin@tims.net Web: http://users.sota-oh.com/~s1kevin/ Unsolicited advertisements processing fee: $50 subject to change without notice
Subject: Re: (usr-tc) NO Phone support?
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1999-06-02 13:18:41
Thus spake Kevin Benton >Hey Jeff - this list is a good resource, but have you talked with your >3Com sales rep to find out who your NC is and maybe you could get some >help there... Yup...I've gotten some pretty good support through Tom and George...but again...that shouldn't be necessary, and that doesn't change the fact that their support contract rules are totally idiotic. >3Com support people are *not* supposed to be denying you 90 >day warranty support. Geez...I would never be able to tell what's under warranty and what wouldn't...I almost never deploy a chassis in the same config that I get it from 3Com...almost always end up swapping out some card or other. >We have been using 90 day support now for quite some >time (thanks to a continual inflow of chassis'). We don't get them quite that regularly... >Our sales rep has done >quite a bit to help change our attitudes as of late. Still not the best >in the world, but a lot better... I just wish it was possible to get a >warranty support contract number every time we register a new chassis. >(Krish? :) :) :) While this is valid...you can get the support you need through this...its really a cop-out for 3Com...yes, it gets the job done for customers, but its a matter of working around 3Com's idiocy. While I'm not above doing that if necessary to get what I need, I'm going to remember that 3Com's idiocy made me do that, and let people know about it. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456
Subject: (usr-tc) Re:NEED 2 MORE 000976-0 NETSERVER PRI SETS
From: Andrew:PC Global, Inc. <andrew@pcglobal.net>
Date: 1999-06-02 15:40:18
Hello- Need another (2) USR/3COM 000976-0 Netserver PRI card set. The set must include: (Numbers are on white stickers on the cards). Part# 69-0001003 Part#69-0001393 Part#67-000209 Cable Need to buy the card set only.. Not whole chassis with cards in it. Will pay $900 per set. All numbers must match. Must be working. Andrew Shlensky **************************** PC Global, Inc. (305) 667-2111 tel (305) 667-3636 fax (305) 216-8638 mobile URL: http://www.pcglobal.net E-MAIL: andrew@pcglobal.net ICQ: 21219089 Computer Service Parts SpEciaLiSts! ALSO:SALES of New/Used PCs,Laptops Communication & Networking,Monitors Printers, Hard Drives, Midrange/Mainframe. Hard to Get Parts. We buy and sell all types of GEAR- ****************************
Subject: (usr-tc) NOTICE - HiPerDSP T1/PRI Service Release 2.0.81 Posted to
From: William Brien <william_brien@mw.3com.com>
Date: 1999-06-02 16:33:37
(notice forwarded from 3Com TotalControl mailing list at totalcontrol@totalservice.nsd.usr.com - subscription information listed below) 3Com Customers, 3Com would like to announce the release of HiPerDSP T1/PRI Service Release 2.0.81 on the TotalService website at: http://totalservice.3com.com/ This release was built from HiPerDSP Release 2.0.19 (TCS 3.5) and fixes the MRs listed below: MR 2023 Issue - HiPer DSP does not report correct ANI/DNIS digits via HiPer ARC reverse telnet terminal. MR 2114 Issue - Under certain conditions a software reset of a modem did not always reset the modem. MR 2151 Issue - Rockwell clients fail to establish error control in some environments. MR 2169 Issue - All calls fail to connect on PRI INS 1500 switch type. MR 2197 Issue - An interface ID other than zero on a non-NFAS PRI span causes all calls to fail to connect. Most telephone companies do not provision non-NFAS spans with non-zero interface IDs. Download of this code requires a valid service contract. If you would like to purchase a service contract, please contact your local reseller of 3Com services for more information. To locate your local Value Added Reseller, as well as 3Com sales offices, please go to: http://www.3com.com/3sn/where2buy.html If there are any questions or concerns regarding this System Release, please contact 3Com Technical Support toll-free at 1-800-231-8770. If you are calling from an area not handled by this number, the TotalService website has contact information for other countries and regions. Please go to the TotalService website and click on 'Contacting Tech Support' for more information. Thank you, Will Brien CSO Customer Service Product Planning (formerly NPI) William_Brien@3com.com (3Com User Forum information available at http://totalservice.3com.com/cgi-bin/w3com/start?totalservice+forumlink)
Subject: Re: (usr-tc) (partial answer) Why won't HiperDSP Port 1 of 23 connect?
From: Peter Olson <peter.olson@chi.frb.org>
Date: 1999-06-02 16:48:08
Hello, We have done more testing and found the another HiperDSP running 1.2.59 firmware received calls without any trouble on channel 1. Since then, we backed the 2.0.19 firmware off the HiperDSP and reinstalled 1.2.59, and everything checks out. Is anyone else seeing problems with PRI service on 2.0.19? Thanks, --Peter
Subject: (usr-tc) More ARC x RADIUS
From: Marcelo Souza <mpsouza@centroin.com.br>
Date: 1999-06-02 17:14:58
How can I change this setting to ENABLE, using CLI: > Sh accounting settings (...) Prioritize First Server in a Server Group: DISABLED What happen (with this config) when the primary server go down and come back up, does the accounting packtes, go to primary server or keep going to 1st backup. - Marcelo
Subject: (usr-tc) 3Com 56K class action suit settlement
From: Brian Uechi <brianu@lava.net>
Date: 1999-06-02 19:43:44
http://www.internetnews.com/isp-news/article/0,1087,8_129531,00.html "3COM Corp. Tuesday agreed to settle a class action lawsuit over claims that it falsely advertised the performance of its 56K modems. In a May 11 order from a California Superior Court, 3Com has agreed to give a $15 rebate to anyone who purchased one of its X2 modems or before May 31. The company will also offer a $15 rebate to users who paid to upgrade an existing 3Com modem to X2 before February 28, 1998." Hmm, I wonder if this applies to total control racks. Note the rebate only applies when purchasing at least $100 of 3Com product so this isn't a check for $15/modem which would have been nice.
Subject: (usr-tc) Fallback
From: Marcelo Souza <mpsouza@centroin.com.br>
Date: 1999-06-02 20:23:35
How to be sure that the fallback is enabled in the DSP modems? From the console of DSP at modem prompt the ATI6 shows that it's ENABLE, but in TCM monitor of Call statistics, the "line fallback negociated" shows DISABLE. Change the S15.1 register dosen't change this situation. - Marcelo
Subject: Re: (usr-tc) List archive
From: slack <jhansen@xmission.com>
Date: 1999-06-02 22:49:58
On Wed, Jun 02, 1999 at 11:38:58PM -0500, John Schmerold wrote: > I tried to use this site. I'm using IE5. It requested a username & password. > > What should I use? > > At 11:47 AM 6/1/99 -0500, you wrote: > >John Schmerold said once upon a time: > >> > >>Where is this list archived? > >> > >>I accidently deleted several scripts > > > >ftp://ftp.xmission.com/pub/lists/usr-tc/archive > > Username: ftp Password: email address -- Jason Hansen jhansen@xmission.com
Subject: Re: (usr-tc) List archive
From: John Schmerold <john@katy.com>
Date: 1999-06-02 23:38:58
I tried to use this site. I'm using IE5. It requested a username & password. What should I use? At 11:47 AM 6/1/99 -0500, you wrote: >John Schmerold said once upon a time: >> >>Where is this list archived? >> >>I accidently deleted several scripts > >ftp://ftp.xmission.com/pub/lists/usr-tc/archive > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. John Schmerold Katy Computer Systems, Inc. 20 Meramec Station Rd Valley Park, MO 63088 314-316-9000 v 314-316-9200 f email: john@katy.com
Subject: RE: (usr-tc) Terminate Reasons...
From: Clarence Orleski <corlesk@compusmart.ab.ca>
Date: 1999-06-03 07:34:32
Hi. I would be most appreciative if I could get a copy of the script mentioned in this thread. Thanks in advance Clarence Orleski Manager, MIS CompuSmart Corlesk@compusmart.ab.ca <mailto:Corlesk@compusmart.ab.ca> -----Original Message----- From: Marcelo Souza [mailto:mpsouza@centroin.com.br] Sent: Tuesday, June 01, 1999 5:27 PM To: usr-tc@lists.xmission.com Subject: Re: (usr-tc) Terminate Reasons... On Tue, 1 Jun 1999, Stephen Amadei wrote: |On Tue, 1 Jun 1999, Marcelo Souza wrote: | |> Ok, but what should be when it happen after almost 1 hour of |> connection ? | |You got me there. I haven't seen that one. Perhaps a CHAP challenge? I don't use CHAP for those users, and the session time may vary from few minutes to an hour, maybe more. |> |Unfortunately, many of the other "User Errors" (accidentally turning off |> |the computer, tripping on the modem cord, using Windows 9X ;-) ), |> |seem to come up with the euphanism "Lost Carrier"... |> |> BTW, comparing with the number of "User-Request", which is the |> percentage of "Lost-Carrier" do you have? How much can I consider normal? | |My stats since upgrading to TCS 3.5: These numbers are very close from those I have here maybe a little higher, I have some thing between 18% to 23% of lost carrier, compared against the "user request". I guess these numbers high and I trying to undestand which are the real reasons. |MOO is a hiper chassis with all calls on DSPs... ACY and PVL are both |older chassis with Quad cards, but upgraded to HiperARCs... as you can |see, the older chassis seems to have more lost carriers... by nearly a |factor of 2. I've been at a loss to explain it, but I will also note that |the older chassis tend to have slightly higher connect speeds... 49-53.3K |as opposed to 45-50K on the DSP cards. | |I plan on using one of the SNMPTRAP scripts posted here previously to |determine if only one or two modems are responsible for this difference in |terms. I did a script to isolate the statiscs for each DSP but the numbers are close: Slot 1 : 20.4 % Slot 2 : 18.4 % Slot 3 : 22.4 % Slot 4 : 20.6 % Slot 5 : 22.1 % Slot 6 : 16.8 % If you want I can send the script to you (no jewel :-). |You'll also notice I have few Idle Timeouts... I don't understand this, |but is this from stray traffic on my network, or have others had low Idle |Terminates, too? Any tips for straining out this stray traffic? I don't |use filters currently, and don't wish to censor anyone's connectivity... |just reduce this traffic that may be keeping the connections open. My numbers for Idle are very few also, but I think ICQ is the main guilty. - Marcelo - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.
Subject: RE: (usr-tc) Maximum cards per chassis (WAS RE: Quad modem NIC's. ..take up power??)
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1999-06-03 13:29:42
On Thu, 3 Jun 1999, matthews wrote: > > Didn't Krish say that the ARC has been lab tested and been able to handle > 14 DSPs or am I losing my mind? If not, exactly how many DSPs can 1 ARC > handle? Hiper arc 4.1.x code supports 14 Hiper dsps - This configuration is only valid if you are using IP. If you are using IPX and IP only 7 DSP per hiper arc is supported. If you are using IPX only - again only 7 DSP per hiper arc is supported. > > On Thursday, May 27, 1999 1:52 PM, Florin_Neamtu@3com.com > [SMTP:Florin_Neamtu@3com.com] wrote: > > > > > > Backplane consumption: 7.8 W 26.6 BTUs > > > > > > > > > > POWER AND HiPer CARD SUPPORT CONSIDERATIONS > > > > The following table provides the maximum number of cards in both HiPer > > Access Router and NetServer configurations supported in associated > chassis. > > This table assumes T1 configurations, with each HiPer DSP card supporting > > 24 calls. > > |-------------------+--------------+------------------------> > > | | | | > > | | Double-Up | Maximum Number of | > > | Chassis | Supported? | HiPer DSP + HiPer ARC | > > | | | (1) | > > | | | | > > |-------------------+--------------+------------------------> > > >-----------------------| > > | | > > | Maximum Number of | > > | HiPer DSP + NetServer | > > | (2) | > > | | > > >-----------------------| > > |-------------------+--------------+------------------------> > > | | | | > > | 45Amp | Yes | 6 + 1 (144 calls) | > > | | | 6 HiPer DSP cards and | > > | | | 1 HiPer Access Router | > > | | | card | > > | | | | > > |-------------------+--------------+------------------------> > > >-----------------------| > > | | > > | 1 x (4 + 1) (96 | > > | calls) | > > | 1 set of 4 HiPer DSP | > > | cards with 1 | > > | NetServer | > > | | > > >-----------------------| > > |-------------------+--------------+------------------------> > > | | | | > > | 70Amp | Yes | 10 + 2 (240 calls) | > > | | | 10 HiPer DSP cards and | > > | | | 2 HiPer Access Router | > > | | | cards | > > | | | | > > |-------------------+--------------+------------------------> > > >-----------------------| > > | | > > | 2 x (4 + 1) (192 | > > | calls) | > > | 2 sets of 4 HiPer DSP | > > | cards with 1 | > > | NetServer | > > | | > > >-----------------------| > > |-------------------+--------------+------------------------> > > | | | | > > | 130Amp | Yes | 14 + 2 (336 calls) | > > | | | 14 HiPer DSP cards and | > > | | | 2 HiPer Access Router | > > | | | cards | > > | | | | > > |-------------------+--------------+------------------------> > > >-----------------------| > > | | > > | 3 x (4 + 1) (288 | > > | calls) | > > | 3 sets of 4 HiPer DSP | > > | cards with 1 | > > | NetServer | > > | | > > >-----------------------| > > > > > > > > Notes: > > (1) Figures shown in this column represent the maximum number of HiPer > DSP > > cards and HiPer Access Router cards which can be supported in the > > associated chassis. Thus, the entry > > > > During the first release of hiper arc, the hiper arc could handle only 7 DSP for IP ( 4.0.X) code. This information may be in that regards. Also the TCS 3.5 code supports DSA and ILB - thus having a fall-over hiper arc is suggested. Hope this helps krish > > > > ?6 + 1? refers to 6 HiPer DSP card > > sets plus 1 HiPer Access Router set (10/100M ethernet) supporting a > > corresponding 144 calls. > > (2) Figures shown in this column represent the maximum number of HiPer > DSP > > cards and NetServer cards which can be supported in the associated > > chassis. With the NetServer card upgraded to TCS3.0 (associated > NetServer > > card release 3.6.x) and supporting up to 96 calls, the NetServer card > is > > thus able to support 4 HiPer DSP cards, assuming T1 configurations (24 > > channels per HiPer DSP card set). Thus, the entry ?1 x (4 + 1)? refers > to > > 1 set (1 x) of 4 HiPer DSP cards plus 1 NetServer card (supporting 96 > > calls) for a system capability of 96 calls. > > > > When Do Customers Need to go to the 130Amp Supplies > > Customers will need to swap out their existing 70Amp PSU/PSI set(s) and > > install 130Amp PSU/PSI set(s) once they exceed 10 HiPer DSP cards in the > 10 > > HiPer DSP + 2 HiPer Access Router configuration or once they exceed the 2 > > sets of the 4 HiPer DSP + 1 NetServer card configuration. The 70Amp power > > supplies PSU/PSI sets can be exchanged for the 130Amp PSU/PSI sets. > > However, the 45Amp supplies cannot be upgraded to either 70Amp or 130Amp > > supplies. > > > > > > > > > > The information I have goes like this; > > > > Pwr supply Max calls hiper Arc /hdm max calls > > HDM/netserver > > > > 45Amp 6 HDM + 1 Harc = 144/180 calls 4 HDM + 1 > > Netserver =96/120 calls > > > > 70Amp 10 HDM + 2 Harc = 230/300 calls 8 HDM + 2 > > Netservers =192/240 calls > > > > 130Amp 14 HDM + 2 Harc = 336/420 calls 12 HDM + 3 > > Netservers = 288/360 calls > > > > Hope this helps > > Florin N > > > > > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >
Subject: RE: (usr-tc) Maximum cards per chassis (WAS RE: Quad modem NIC's.
From: Ricky Beam <jfbeam@beaker.interpath.net>
Date: 1999-06-03 14:24:32
On Thu, 3 Jun 1999, matthews wrote: > >Do you plan to be able to support the same numbers when 4.2.x comes out? > I'd expect those numbers to drop :-( The Pilgram is far from "efficient". --Ricky
Subject: RE: (usr-tc) Maximum cards per chassis (WAS RE: Quad modem NIC's. ..take up power??)
From: matthews <matthews@staff.brunnet.net>
Date: 1999-06-03 14:36:12
Didn't Krish say that the ARC has been lab tested and been able to handle 14 DSPs or am I losing my mind? If not, exactly how many DSPs can 1 ARC handle? On Thursday, May 27, 1999 1:52 PM, Florin_Neamtu@3com.com [SMTP:Florin_Neamtu@3com.com] wrote: > > > Backplane consumption: 7.8 W 26.6 BTUs > > > > > POWER AND HiPer CARD SUPPORT CONSIDERATIONS > > The following table provides the maximum number of cards in both HiPer > Access Router and NetServer configurations supported in associated chassis. > This table assumes T1 configurations, with each HiPer DSP card supporting > 24 calls. > |-------------------+--------------+------------------------> > | | | | > | | Double-Up | Maximum Number of | > | Chassis | Supported? | HiPer DSP + HiPer ARC | > | | | (1) | > | | | | > |-------------------+--------------+------------------------> > >-----------------------| > | | > | Maximum Number of | > | HiPer DSP + NetServer | > | (2) | > | | > >-----------------------| > |-------------------+--------------+------------------------> > | | | | > | 45Amp | Yes | 6 + 1 (144 calls) | > | | | 6 HiPer DSP cards and | > | | | 1 HiPer Access Router | > | | | card | > | | | | > |-------------------+--------------+------------------------> > >-----------------------| > | | > | 1 x (4 + 1) (96 | > | calls) | > | 1 set of 4 HiPer DSP | > | cards with 1 | > | NetServer | > | | > >-----------------------| > |-------------------+--------------+------------------------> > | | | | > | 70Amp | Yes | 10 + 2 (240 calls) | > | | | 10 HiPer DSP cards and | > | | | 2 HiPer Access Router | > | | | cards | > | | | | > |-------------------+--------------+------------------------> > >-----------------------| > | | > | 2 x (4 + 1) (192 | > | calls) | > | 2 sets of 4 HiPer DSP | > | cards with 1 | > | NetServer | > | | > >-----------------------| > |-------------------+--------------+------------------------> > | | | | > | 130Amp | Yes | 14 + 2 (336 calls) | > | | | 14 HiPer DSP cards and | > | | | 2 HiPer Access Router | > | | | cards | > | | | | > |-------------------+--------------+------------------------> > >-----------------------| > | | > | 3 x (4 + 1) (288 | > | calls) | > | 3 sets of 4 HiPer DSP | > | cards with 1 | > | NetServer | > | | > >-----------------------| > > > > Notes: > (1) Figures shown in this column represent the maximum number of HiPer DSP > cards and HiPer Access Router cards which can be supported in the > associated chassis. Thus, the entry > > > > ?6 + 1? refers to 6 HiPer DSP card > sets plus 1 HiPer Access Router set (10/100M ethernet) supporting a > corresponding 144 calls. > (2) Figures shown in this column represent the maximum number of HiPer DSP > cards and NetServer cards which can be supported in the associated > chassis. With the NetServer card upgraded to TCS3.0 (associated NetServer > card release 3.6.x) and supporting up to 96 calls, the NetServer card is > thus able to support 4 HiPer DSP cards, assuming T1 configurations (24 > channels per HiPer DSP card set). Thus, the entry ?1 x (4 + 1)? refers to > 1 set (1 x) of 4 HiPer DSP cards plus 1 NetServer card (supporting 96 > calls) for a system capability of 96 calls. > > When Do Customers Need to go to the 130Amp Supplies > Customers will need to swap out their existing 70Amp PSU/PSI set(s) and > install 130Amp PSU/PSI set(s) once they exceed 10 HiPer DSP cards in the 10 > HiPer DSP + 2 HiPer Access Router configuration or once they exceed the 2 > sets of the 4 HiPer DSP + 1 NetServer card configuration. The 70Amp power > supplies PSU/PSI sets can be exchanged for the 130Amp PSU/PSI sets. > However, the 45Amp supplies cannot be upgraded to either 70Amp or 130Amp > supplies. > > > > > The information I have goes like this; > > Pwr supply Max calls hiper Arc /hdm max calls > HDM/netserver > > 45Amp 6 HDM + 1 Harc = 144/180 calls 4 HDM + 1 > Netserver =96/120 calls > > 70Amp 10 HDM + 2 Harc = 230/300 calls 8 HDM + 2 > Netservers =192/240 calls > > 130Amp 14 HDM + 2 Harc = 336/420 calls 12 HDM + 3 > Netservers = 288/360 calls > > Hope this helps > Florin N > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message.
Subject: RE: (usr-tc) Maximum cards per chassis (WAS RE: Quad modem NIC's. ..take up power??)
From: matthews <matthews@staff.brunnet.net>
Date: 1999-06-03 15:07:46
Do you plan to be able to support the same numbers when 4.2.x comes out? On Thursday, June 03, 1999 3:30 PM, Tatai SV Krishnan [SMTP:tkrishna@bubba.ae.usr.com] wrote: > On Thu, 3 Jun 1999, matthews wrote: > > > > > Didn't Krish say that the ARC has been lab tested and been able to handle > > 14 DSPs or am I losing my mind? If not, exactly how many DSPs can 1 ARC > > handle? > > Hiper arc 4.1.x code supports 14 Hiper dsps - This configuration is only > valid if you are using IP. If you are using IPX and IP only 7 DSP per > hiper arc is supported. If you are using IPX only - again only 7 DSP per > hiper arc is supported. > > > > > > On Thursday, May 27, 1999 1:52 PM, Florin_Neamtu@3com.com > > [SMTP:Florin_Neamtu@3com.com] wrote: > > > > > > > > > Backplane consumption: 7.8 W 26.6 BTUs > > > > > > > > > > > > > > > POWER AND HiPer CARD SUPPORT CONSIDERATIONS > > > > > > The following table provides the maximum number of cards in both HiPer > > > Access Router and NetServer configurations supported in associated > > chassis. > > > This table assumes T1 configurations, with each HiPer DSP card supporting > > > 24 calls. > > > |-------------------+--------------+------------------------> > > > | | | | > > > | | Double-Up | Maximum Number of | > > > | Chassis | Supported? | HiPer DSP + HiPer ARC | > > > | | | (1) | > > > | | | | > > > |-------------------+--------------+------------------------> > > > >-----------------------| > > > | | > > > | Maximum Number of | > > > | HiPer DSP + NetServer | > > > | (2) | > > > | | > > > >-----------------------| > > > |-------------------+--------------+------------------------> > > > | | | | > > > | 45Amp | Yes | 6 + 1 (144 calls) | > > > | | | 6 HiPer DSP cards and | > > > | | | 1 HiPer Access Router | > > > | | | card | > > > | | | | > > > |-------------------+--------------+------------------------> > > > >-----------------------| > > > | | > > > | 1 x (4 + 1) (96 | > > > | calls) | > > > | 1 set of 4 HiPer DSP | > > > | cards with 1 | > > > | NetServer | > > > | | > > > >-----------------------| > > > |-------------------+--------------+------------------------> > > > | | | | > > > | 70Amp | Yes | 10 + 2 (240 calls) | > > > | | | 10 HiPer DSP cards and | > > > | | | 2 HiPer Access Router | > > > | | | cards | > > > | | | | > > > |-------------------+--------------+------------------------> > > > >-----------------------| > > > | | > > > | 2 x (4 + 1) (192 | > > > | calls) | > > > | 2 sets of 4 HiPer DSP | > > > | cards with 1 | > > > | NetServer | > > > | | > > > >-----------------------| > > > |-------------------+--------------+------------------------> > > > | | | | > > > | 130Amp | Yes | 14 + 2 (336 calls) | > > > | | | 14 HiPer DSP cards and | > > > | | | 2 HiPer Access Router | > > > | | | cards | > > > | | | | > > > |-------------------+--------------+------------------------> > > > >-----------------------| > > > | | > > > | 3 x (4 + 1) (288 | > > > | calls) | > > > | 3 sets of 4 HiPer DSP | > > > | cards with 1 | > > > | NetServer | > > > | | > > > >-----------------------| > > > > > > > > > > > > Notes: > > > (1) Figures shown in this column represent the maximum number of HiPer > > DSP > > > cards and HiPer Access Router cards which can be supported in the > > > associated chassis. Thus, the entry > > > > > > > > During the first release of hiper arc, the hiper arc could handle only 7 > DSP for IP ( 4.0.X) code. This information may be in that regards. > > Also the TCS 3.5 code supports DSA and ILB - thus having a fall-over > hiper arc is suggested. > > > Hope this helps > > krish > > > > > > > > ?6 + 1? refers to 6 HiPer DSP card > > > sets plus 1 HiPer Access Router set (10/100M ethernet) supporting a > > > corresponding 144 calls. > > > (2) Figures shown in this column represent the maximum number of HiPer > > DSP > > > cards and NetServer cards which can be supported in the associated > > > chassis. With the NetServer card upgraded to TCS3.0 (associated > > NetServer > > > card release 3.6.x) and supporting up to 96 calls, the NetServer card > > is > > > thus able to support 4 HiPer DSP cards, assuming T1 configurations (24 > > > channels per HiPer DSP card set). Thus, the entry ?1 x (4 + 1)? refers > > to > > > 1 set (1 x) of 4 HiPer DSP cards plus 1 NetServer card (supporting 96 > > > calls) for a system capability of 96 calls. > > > > > > When Do Customers Need to go to the 130Amp Supplies > > > Customers will need to swap out their existing 70Amp PSU/PSI set(s) and > > > install 130Amp PSU/PSI set(s) once they exceed 10 HiPer DSP cards in the > > 10 > > > HiPer DSP + 2 HiPer Access Router configuration or once they exceed the 2 > > > sets of the 4 HiPer DSP + 1 NetServer card configuration. The 70Amp power > > > supplies PSU/PSI sets can be exchanged for the 130Amp PSU/PSI sets. > > > However, the 45Amp supplies cannot be upgraded to either 70Amp or 130Amp > > > supplies. > > > > > > > > > > > > > > > The information I have goes like this; > > > > > > Pwr supply Max calls hiper Arc /hdm max calls > > > HDM/netserver > > > > > > 45Amp 6 HDM + 1 Harc = 144/180 calls 4 HDM + 1 > > > Netserver =96/120 calls > > > > > > 70Amp 10 HDM + 2 Harc = 230/300 calls 8 HDM + 2 > > > Netservers =192/240 calls > > > > > > 130Amp 14 HDM + 2 Harc = 336/420 calls 12 HDM + 3 > > > Netservers = 288/360 calls > > > > > > Hope this helps > > > Florin N > > > > > > > > > > > > > > > - > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > with "unsubscribe usr-tc" in the body of the message. > > > For information on digests or retrieving files and old messages send > > > "help" to the same address. Do not use quotes in your message. > > > > > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message.
Subject: RE: (usr-tc) Maximum cards per chassis (WAS RE: Quad modem NIC's. ..take up power??)
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1999-06-03 15:13:33
On Thu, 3 Jun 1999, matthews wrote: > > Do you plan to be able to support the same numbers when 4.2.x comes out? As far as I know yes, krish > > On Thursday, June 03, 1999 3:30 PM, Tatai SV Krishnan [SMTP:tkrishna@bubba.ae.usr.com] wrote: > > On Thu, 3 Jun 1999, matthews wrote: > > > > > > > > Didn't Krish say that the ARC has been lab tested and been able to handle > > > 14 DSPs or am I losing my mind? If not, exactly how many DSPs can 1 ARC > > > handle? > > > > Hiper arc 4.1.x code supports 14 Hiper dsps - This configuration is only > > valid if you are using IP. If you are using IPX and IP only 7 DSP per > > hiper arc is supported. If you are using IPX only - again only 7 DSP per > > hiper arc is supported. > > > > > > > > > > On Thursday, May 27, 1999 1:52 PM, Florin_Neamtu@3com.com > > > [SMTP:Florin_Neamtu@3com.com] wrote: > > > > > > > > > > > > Backplane consumption: 7.8 W 26.6 BTUs > > > > > > > > > > > > > > > > > > > > POWER AND HiPer CARD SUPPORT CONSIDERATIONS > > > > > > > > The following table provides the maximum number of cards in both HiPer > > > > Access Router and NetServer configurations supported in associated > > > chassis. > > > > This table assumes T1 configurations, with each HiPer DSP card supporting > > > > 24 calls. > > > > |-------------------+--------------+------------------------> > > > > | | | | > > > > | | Double-Up | Maximum Number of | > > > > | Chassis | Supported? | HiPer DSP + HiPer ARC | > > > > | | | (1) | > > > > | | | | > > > > |-------------------+--------------+------------------------> > > > > >-----------------------| > > > > | | > > > > | Maximum Number of | > > > > | HiPer DSP + NetServer | > > > > | (2) | > > > > | | > > > > >-----------------------| > > > > |-------------------+--------------+------------------------> > > > > | | | | > > > > | 45Amp | Yes | 6 + 1 (144 calls) | > > > > | | | 6 HiPer DSP cards and | > > > > | | | 1 HiPer Access Router | > > > > | | | card | > > > > | | | | > > > > |-------------------+--------------+------------------------> > > > > >-----------------------| > > > > | | > > > > | 1 x (4 + 1) (96 | > > > > | calls) | > > > > | 1 set of 4 HiPer DSP | > > > > | cards with 1 | > > > > | NetServer | > > > > | | > > > > >-----------------------| > > > > |-------------------+--------------+------------------------> > > > > | | | | > > > > | 70Amp | Yes | 10 + 2 (240 calls) | > > > > | | | 10 HiPer DSP cards and | > > > > | | | 2 HiPer Access Router | > > > > | | | cards | > > > > | | | | > > > > |-------------------+--------------+------------------------> > > > > >-----------------------| > > > > | | > > > > | 2 x (4 + 1) (192 | > > > > | calls) | > > > > | 2 sets of 4 HiPer DSP | > > > > | cards with 1 | > > > > | NetServer | > > > > | | > > > > >-----------------------| > > > > |-------------------+--------------+------------------------> > > > > | | | | > > > > | 130Amp | Yes | 14 + 2 (336 calls) | > > > > | | | 14 HiPer DSP cards and | > > > > | | | 2 HiPer Access Router | > > > > | | | cards | > > > > | | | | > > > > |-------------------+--------------+------------------------> > > > > >-----------------------| > > > > | | > > > > | 3 x (4 + 1) (288 | > > > > | calls) | > > > > | 3 sets of 4 HiPer DSP | > > > > | cards with 1 | > > > > | NetServer | > > > > | | > > > > >-----------------------| > > > > > > > > > > > > > > > > Notes: > > > > (1) Figures shown in this column represent the maximum number of HiPer > > > DSP > > > > cards and HiPer Access Router cards which can be supported in the > > > > associated chassis. Thus, the entry > > > > > > > > > > > > During the first release of hiper arc, the hiper arc could handle only 7 > > DSP for IP ( 4.0.X) code. This information may be in that regards. > > > > Also the TCS 3.5 code supports DSA and ILB - thus having a fall-over > > hiper arc is suggested. > > > > > > Hope this helps > > > > krish > > > > > > > > > > > > ?6 + 1? refers to 6 HiPer DSP card > > > > sets plus 1 HiPer Access Router set (10/100M ethernet) supporting a > > > > corresponding 144 calls. > > > > (2) Figures shown in this column represent the maximum number of HiPer > > > DSP > > > > cards and NetServer cards which can be supported in the associated > > > > chassis. With the NetServer card upgraded to TCS3.0 (associated > > > NetServer > > > > card release 3.6.x) and supporting up to 96 calls, the NetServer card > > > is > > > > thus able to support 4 HiPer DSP cards, assuming T1 configurations (24 > > > > channels per HiPer DSP card set). Thus, the entry ?1 x (4 + 1)? refers > > > to > > > > 1 set (1 x) of 4 HiPer DSP cards plus 1 NetServer card (supporting 96 > > > > calls) for a system capability of 96 calls. > > > > > > > > When Do Customers Need to go to the 130Amp Supplies > > > > Customers will need to swap out their existing 70Amp PSU/PSI set(s) and > > > > install 130Amp PSU/PSI set(s) once they exceed 10 HiPer DSP cards in the > > > 10 > > > > HiPer DSP + 2 HiPer Access Router configuration or once they exceed the 2 > > > > sets of the 4 HiPer DSP + 1 NetServer card configuration. The 70Amp power > > > > supplies PSU/PSI sets can be exchanged for the 130Amp PSU/PSI sets. > > > > However, the 45Amp supplies cannot be upgraded to either 70Amp or 130Amp > > > > supplies. > > > > > > > > > > > > > > > > > > > > The information I have goes like this; > > > > > > > > Pwr supply Max calls hiper Arc /hdm max calls > > > > HDM/netserver > > > > > > > > 45Amp 6 HDM + 1 Harc = 144/180 calls 4 HDM + 1 > > > > Netserver =96/120 calls > > > > > > > > 70Amp 10 HDM + 2 Harc = 230/300 calls 8 HDM + 2 > > > > Netservers =192/240 calls > > > > > > > > 130Amp 14 HDM + 2 Harc = 336/420 calls 12 HDM + 3 > > > > Netservers = 288/360 calls > > > > > > > > Hope this helps > > > > Florin N > > > > > > > > > > > > > > > > > > > > - > > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > > with "unsubscribe usr-tc" in the body of the message. > > > > For information on digests or retrieving files and old messages send > > > > "help" to the same address. Do not use quotes in your message. > > > > > > > > > > > > > > > - > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > with "unsubscribe usr-tc" in the body of the message. > > > For information on digests or retrieving files and old messages send > > > "help" to the same address. Do not use quotes in your message. > > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >
Subject: (usr-tc) FS: GDC DSU's
From: Andrew:PC Global, Inc. <andrew@pcglobal.net>
Date: 1999-06-03 15:15:39
For Sale: General Datacom Qty. (12) 552A-1 Chassis including the following Qty. (4) 500G UXR Cards Qty. (1)DPS-9 Power Supply Qty. (1)DSM 06 Chassis Will part out the chassis for power supplys or cards. What are they worth to you? Email me in private if interested.. Warmest Regards, Andrew Shlensky **************************** PC Global, Inc. (305) 667-2111 tel (305) 667-3636 fax (305) 216-8638 mobile URL: http://www.pcglobal.net E-MAIL: andrew@pcglobal.net ICQ: 21219089 Computer Service Parts SpEciaLiSts! ALSO:SALES of New/Used PCs,Laptops Communication & Networking,Monitors Printers, Hard Drives, Midrange/Mainframe. Hard to Get Parts. We buy and sell all types of GEAR- ****************************
Subject: (usr-tc) TCM error
From: Brian <signal@shreve.net>
Date: 1999-06-03 16:20:21
In opening a chasiss with an older code rev than the rest of ours, I get: Unable to open device descriptor file whenever I try to click on an hdm and goto "Configure->program settings" Is this from not having the older nmc code installed? The rest of our chassis are all hipernmc, this one isn't and possibly has older nmc code. Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)
Subject: (usr-tc) 6 to 1 -> DSP : ARC
From: Paul Farber <farber@admin.f-tech.net>
Date: 1999-06-04 02:45:18
I remember reading a post a while back that at around 7 DSP's the arc didn't couldn't handle all the incoming call setup's.... thats sounds a bit fishy but that what someone reported. I'm on the 6th DSP now and I have the 2nd ARC to put in but I don't know if I want/need to. BTW.. anyone have a general outline of the best way to setup the card ownership and IP pools? Spilt it 50-50? Thanks. Paul D. Farber II Farber Technology Ph. 570-628-5303 Fax 570-628-5545 farber@admin.f-tech.net
Subject: Re: (usr-tc) NO Phone support?
From: John Scrivner <john@hair.scrivner.com>
Date: 1999-06-04 05:10:03
On a 1 to 10 scale I give Lucent a 10 (tech support). I give 3Com a weak 3 (tech support). I have both Lucent and 3Com concentrators. I will say that the 3Com modems work better though. Sincerely, John Scrivner ---------- Original Message ---------------------------------- Reply-To: usr-tc@lists.xmission.com >hello all, I recently let my service contract with 3Com lapse, since they neither improved the code or added any features I needed, I figured that I shouldn't buy what I don't need. Called today about an idle modem problem and once the tech asked if I had a contract #, I said no. He then transferred me to logistics to replace the card. No diagnosis, no questions. Why is it I can get phone support for a $100 Sporster, but my $75,000 worth of TC chassis get jack? Anyone else have this experience? Looking at populating the next POP with ASCEND or Lucent.... what's thier "real world" tech support like? Paul D. Farber II Farber Technology Ph. 570-628-5303 Fax 570-628-5545 farber@admin.f-tech.net - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.
Subject: RE: (usr-tc) Terminate Reasons...
From: Marcelo Souza <mpsouza@centroin.com.br>
Date: 1999-06-04 11:47:35
Here is the script that Clarence and Jason asked for: - Marcelo #!/usr/bin/perl5 # -*-perl-*- # Isolates the statistics of dropped calls for each DSP # # $nas_ip = IP Address of the ARC (needed if the log is the same for # more then one NAS. # # $file = The detail file # # This script consider the detail file generated by Livingston Radius, # so the nunber after -A in grep can be different for other versions. # # $file = "/var/log/radacct/detail"; $nas_ip = "200.200.200.200"; open(FILE,"cat $file | grep -A 13 -e $nas_ip | grep -A 12 -e 'Stop' | grep -e 'NAS-Port =' -e 'Acct-Term'|"); while(<FILE>) { ($arg,$val)=split(/\=/); if ($arg =~ "NAS-Port") { $board = int ($val / 256) + 1 ; } elsif ($arg =~ "inate-Ca") { $cause = $val ; chop ($cause); if ( $cause =~ "Lost" ) { $bad[$board]++; } else { $good[$board]++; } } } close(FILE); for $i (1..6) { $estat[$i] = $bad[$i]*100 / $good[$i] ; printf ("Slot %1d : %2.2f \%\n", $i , $estat[$i] ); }
Subject: Re: (usr-tc) HyperDSP E1 hardware failure on Boot
From: David Bachta <david_bachta@mw.3com.com>
Date: 1999-06-04 12:18:34
Brett, Yes, the card should be returned for repair. This is a memory test failure. Regards, David "Brett Murphy" <me@murf.net> on 06/03/99 11:01:17 PM Please respond to usr-tc@lists.xmission.com Sent by: "Brett Murphy" <me@murf.net> cc: (David Bachta/MW/US/3Com) Hi All, I am getting this error on boot up of a HyperDSP, does it need to go back to it's maker? !!----------> SDL2 for the PPC403 <------------!! __ Enter Download Trigger __ Flash Image Has Valid CRC, Loading Image.... Diagnostic Power-Up Failure Manufacturing Info -> 1AAA13M0 Mode/Env -> 1/0 Fault Code -> 0-8-25-1 Expected Data -> f0191420 Received Data -> f0191c20 Text Message -> Address Equals Data Test Failure Info Message -> Second read failed. Hard error indicated. All the best, Brett Murphy Technical Manager, Alphalink (Australia) PTY LTD ph: +61 3 9486-8844 fax: +61 3 9486-6822 email: me@murf.net The contents of this email message may not be quoted, copied, reproduced or published in part or in whole, without the written authorization of Brett Murphy, Director, Alphalink (Australia) Pty Ltd.
Subject: Re: (usr-tc) 6 to 1 -> DSP : ARC
From: Brett Murphy <me@murf.net>
Date: 1999-06-04 13:58:33
I am running 12 HyperDSP E1 cars on one HyperARC but I dont have Multilink PPP dialins. >I remember reading a post a while back that at around 7 DSP's the arc >didn't couldn't handle all the incoming call setup's.... thats sounds a >bit fishy but that what someone reported. > >I'm on the 6th DSP now and I have the 2nd ARC to put in but I don't know >if I want/need to. > >BTW.. anyone have a general outline of the best way to setup the card >ownership and IP pools? Spilt it 50-50? > >Thanks. > >Paul D. Farber II >Farber Technology >Ph. 570-628-5303 >Fax 570-628-5545 >farber@admin.f-tech.net > All the best, Brett Murphy Technical Manager, Alphalink (Australia) PTY LTD ph: +61 3 9486-8844 fax: +61 3 9486-6822 email: me@murf.net The contents of this email message may not be quoted, copied, reproduced or published in part or in whole, without the written authorization of Brett Murphy, Director, Alphalink (Australia) Pty Ltd.
Subject: (usr-tc) HyperDSP E1 hardware failure on Boot
From: Brett Murphy <me@murf.net>
Date: 1999-06-04 14:01:17
This is a multi-part message in MIME format. ------=_NextPart_000_004F_01BEAE92.B734C660 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi All, I am getting this error on boot up of a HyperDSP, does it need = to go back to it's maker? !!----------> SDL2 for the PPC403 <------------!! __ Enter Download Trigger __ Flash Image Has Valid CRC, Loading Image.... Diagnostic Power-Up Failure Manufacturing Info -> 1AAA13M0 Mode/Env -> 1/0 Fault Code -> 0-8-25-1 Expected Data -> f0191420 Received Data -> f0191c20 Text Message -> Address Equals Data Test Failure Info Message -> Second read failed. Hard error indicated. All the best, Brett Murphy Technical Manager, Alphalink (Australia) PTY LTD ph: +61 3 9486-8844 fax: +61 3 9486-6822 email: me@murf.net The contents of this email message may not be quoted, copied, reproduced or published in part or in whole, without the written authorization of Brett Murphy, Director, Alphalink (Australia) Pty Ltd. ------=_NextPart_000_004F_01BEAE92.B734C660 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN"> <HTML> <HEAD> <META content=3Dtext/html;charset=3Diso-8859-1 = http-equiv=3DContent-Type> <META content=3D'"MSHTML 4.72.3616.1301"' name=3DGENERATOR> </HEAD> <BODY bgColor=3D#ffffff> <DIV><FONT color=3D#000000 size=3D2>Hi All, I am getting this error on = boot up of a=20 HyperDSP, does it need to go back to it's maker?</FONT></DIV> <DIV><FONT color=3D#000000 size=3D2></FONT>&nbsp;</DIV> <DIV><FONT size=3D2>!!----------&gt; SDL2 for the PPC403=20 &lt;------------!!</FONT></DIV> <DIV><FONT size=3D2></FONT>&nbsp;</DIV> <DIV><FONT size=3D2>__ Enter Download Trigger __</FONT></DIV> <DIV><FONT size=3D2></FONT>&nbsp;</DIV> <DIV><FONT size=3D2><BR>&nbsp;Flash Image Has Valid CRC, Loading=20 Image....</FONT></DIV> <DIV><FONT size=3D2></FONT>&nbsp;</DIV> <DIV><FONT size=3D2>&nbsp;Diagnostic Power-Up Failure</FONT></DIV> <DIV><FONT size=3D2></FONT>&nbsp;</DIV> <DIV><FONT size=3D2>&nbsp;Manufacturing Info -&gt;=20 1AAA13M0<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; = Mode/Env -&gt; 1/0<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; = Fault=20 Code -&gt; 0-8-25-1<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Expected Data = -&gt;=20 f0191420<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Received Data -&gt;=20 f0191c20<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Text Message -&gt; = Address=20 Equals Data Test Failure<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Info = Message=20 -&gt; Second read failed.&nbsp; Hard error indicated.</FONT></DIV> <DIV><FONT size=3D2></FONT>&nbsp;</DIV> <DIV><FONT size=3D2></FONT>&nbsp;</DIV> <DIV><FONT color=3D#000000 size=3D2><BR>All the best,<BR>Brett = Murphy<BR>Technical=20 Manager, Alphalink (Australia) PTY LTD<BR>ph: +61 3 9486-8844&nbsp; fax: = +61 3=20 9486-6822<BR>email: <A = href=3D"mailto:me@murf.net">me@murf.net</A></FONT></DIV> <DIV><FONT color=3D#000000 size=3D2></FONT>&nbsp;</DIV> <DIV><FONT color=3D#000000 size=3D2>The contents of this email message = may not be=20 quoted,<BR>copied, reproduced or published in part or in = whole,<BR>without the=20 written authorization of Brett Murphy,<BR>Director, Alphalink = (Australia) Pty=20 Ltd.</FONT></DIV></BODY></HTML> ------=_NextPart_000_004F_01BEAE92.B734C660--
Subject: RE: (usr-tc) Terminate Reasons...
From: Stephen Amadei <amadei@dandy.net>
Date: 1999-06-04 19:01:24
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. ---2016540031-970929037-928537284=:2135 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 4 Jun 1999, Marcelo Souza wrote: > > Here is the script that Clarence and Jason asked for: Marcelo, great script. I hope you don't mind, but I have made some add-ons and IMHO improved the failure percentage to reflect more accurate rates. ( Two bads and four goods would equal 50% in your code 2*100/4... whereas it should be 33%... 2*100/(2+4) ). I added per modem failure rates and some more output. I've included a copy of the script with this email (be careful, some of the lines are quite long and like to wordwrap...). I also modified it to work with Cistron's latest RADIUS with USR TC Vender Specific Attributes. 1.3.4.beta18 or something... Other disclaimers... this script runs in OS/2 but should also work under Linux and whatever with very slight changes... (and we all tinker with our scripts... right? ;-) ) Basically you call it like: bad /path/to/detail ip.of.your.usr [card] Using the 'card' option turns off the per modem processing. Again, thanks, and I hope my changes help others. I gotta go swap some lame Quads... ;-) ----Steve Stephen Amadei Director of MIS Dandy Connections, Inc. Atlantic City, NJ ---2016540031-970929037-928537284=:2135 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="bad.pl" Content-Transfer-Encoding: BASE64 Content-ID: <Pine.LNX.4.10.9906041901240.2135@procyon.dandy.net> Content-Description: Content-Disposition: attachment; filename="bad.pl" IyEvdXNyL2Jpbi9wZXJsNQ0KIyAtKi1wZXJsLSotDQojIElzb2xhdGVzIHRo ZSBzdGF0aXN0aWNzIG9mIGRyb3BwZWQgY2FsbHMgZm9yIGVhY2ggRFNQDQoj DQojCSRuYXNfaXAgPSBJUCBBZGRyZXNzIG9mIHRoZSBBUkMgKG5lZWRlZCBp ZiB0aGUgbG9nIGlzIHRoZSBzYW1lIGZvcg0KIwkJbW9yZSB0aGVuIG9uZSBO QVMuDQojDQojCSRmaWxlID0gVGhlIGRldGFpbCBmaWxlIA0KIw0KIwlUaGlz IHNjcmlwdCBjb25zaWRlciB0aGUgZGV0YWlsIGZpbGUgZ2VuZXJhdGVkIGJ5 IExpdmluZ3N0b24gUmFkaXVzLA0KIwlzbyB0aGUgbnVuYmVyIGFmdGVyIC1B IGluIGdyZXAgY2FuIGJlIGRpZmZlcmVudCBmb3Igb3RoZXIgdmVyc2lvbnMu DQojDQojCQ0KDQoNCiMkZmlsZSA9ICJjOi9tcHRuL2V0Yy9yYWRhY2N0L3B2 bC9kZXRhaWwiOw0KJGZpbGUgPSAkQVJHVlswXTsNCiMkbmFzX2lwID0gIjIw OS4xMDEuMTQwLjk2IjsNCiRuYXNfaXAgPSAkQVJHVlsxXTsNCg0Kb3BlbihG SUxFLCJjYXQgJGZpbGUgfCBncmVwIC1BMjMgLWUgJG5hc19pcCB8IGdyZXAg LUEyMiAtZSBcIlN0b3BcIiB8IA0KZ3JlcCAtZSBcIk5BUy1Qb3J0LUlkXCIg LWUgXCJBY2N0LVRlcm1cInwiKTsNCndoaWxlKDxGSUxFPikgew0KDQogICAg KCRhcmcsJHZhbCk9c3BsaXQoL1w9Lyk7DQogICAgaWYgKCRhcmcgPX4gIk5B Uy1Qb3J0Iikgew0KCSRib2FyZCA9IGludCAoJHZhbCAvIDI1NikgKyAxIDsN CiAgICAgICAgJG1vZGVtID0gJHZhbCAtICgoJGJvYXJkLTEpKjI1Nik7DQog ICAgICAgIGlmICgkQVJHVlsyXSkgeyAkbW9kZW0gPSAxOyB9DQoJfQ0KICAg IGVsc2lmICgkYXJnID1+ICJpbmF0ZS1DYSIpIHsNCgkkY2F1c2UgPSAkdmFs IDsNCgljaG9wICgkY2F1c2UpOw0KCQlpZiAoICRjYXVzZSA9fiAiTG9zdCIg KSB7CQ0KCQkJJGJhZFskYm9hcmRdWyRtb2RlbV0rKzsNCgkJCX0NCgkJZWxz ZSB7DQoJCQkkZ29vZFskYm9hcmRdWyRtb2RlbV0rKzsNCgkJfQ0KCX0NCn0N CmNsb3NlKEZJTEUpOw0KDQpmb3IgJGkgKDAuLjE4KSB7DQogICAgZm9yICRq ICgwLi4yNSkgew0KCWlmICgkZ29vZFskaV1bJGpdICE9IDApIHsgDQogICAg CSAgJGVzdGF0WyRpXVskal0gPSAkYmFkWyRpXVskal0qMTAwIC8gKCRnb29k WyRpXVskal0rJGJhZFskaV1bJGpdKTsgDQoJICBpZiAoICRBUkdWWzJdID1+ ICJjYXJkIikgew0KICAJICAgIGlmICggJGVzdGF0WyRpXVskal0gPiA5Ljk5 OSkgew0KICAJICAgICAgcHJpbnRmICgic2xvdDolMmQ6ICUyLjJmXCUgQ2Fs bHM6ICUyZCBCYWQ6ICUyZCBcbiIsICRpLCAkZXN0YXRbJGldWyRqXSwgKCRn b29kWyRpXVskal0rJGJhZFskaV1bJGpdKSwgJGJhZFskaV1bJGpdICk7DQoJ ICAgICAgfQ0KCSAgICBlbHNlIHsNCgkgICAgICBwcmludGYgKCJzbG90OiUy ZDogICUyLjJmXCUgQ2FsbHM6ICUyZCBCYWQ6ICUyZCBcbiIsICRpLCAkZXN0 YXRbJGldWyRqXSwgKCRnb29kWyRpXVskal0rJGJhZFskaV1bJGpdKSwgJGJh ZFskaV1bJGpdICk7DQoJICAgICAgfQ0KICAgICAgICAgICAgfQ0KICAgICAg ICAgIGVsc2Ugew0KICAJICAgIGlmICggJGVzdGF0WyRpXVskal0gPiA5Ljk5 OSkgew0KICAJICAgICAgcHJpbnRmICgic2xvdDolMmQvbW9kOiUyZDogJTIu MmZcJSBDYWxsczogJTJkIEJhZDogJTJkIFxuIiwgJGksICRqLCAkZXN0YXRb JGldWyRqXSwgKCRnb29kWyRpXVskal0rJGJhZFskaV1bJGpdKSwgJGJhZFsk aV1bJGpdICk7DQoJICAgICAgfQ0KCSAgICBlbHNlIHsNCgkgICAgICBwcmlu dGYgKCJzbG90OiUyZC9tb2Q6JTJkOiAgJTIuMmZcJSBDYWxsczogJTJkIEJh ZDogJTJkIFxuIiwgJGksICRqLCAkZXN0YXRbJGldWyRqXSwgKCRnb29kWyRp XVskal0rJGJhZFskaV1bJGpdKSwgJGJhZFskaV1bJGpdICk7DQoJICAgICAg fQ0KIAkgICAgfQ0KICAgICAgICB9DQogICAgfQ0KfQ0K ---2016540031-970929037-928537284=:2135--
Subject: Re: (usr-tc) NAT and VPN
From: Ricky Beam <jfbeam@beaker.interpath.net>
Date: 1999-06-04 19:22:55
On Sat, 5 Jun 1999, Paul Farber wrote: >Will running proxy software (NAT) "break" a VPN connection? > >For example, I will have a customer with 128Kbps ISDN with a 3Com office >connect ISDN router running NAT, DHCP and DNS. Will I be able to set up a >VPN "through" the T/A or will I need to set the router up to route a >subnet and hand out actual ip address. "Not necessarily." You will not be able to create a VPN connect from outside the NATed network, but you should be able to create one just fine from inside. In other words, the connection has to originate from within the "hidden" netowrk. _AND_ the VPN cannot be constructed based on what the "hidden" node's IP address is -- that's not really it's IP address at the other end of the link. --Ricky
Subject: Re: (usr-tc) NAT and VPN
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1999-06-04 20:09:53
Thus spake Ricky Beam >On Sat, 5 Jun 1999, Paul Farber wrote: >>Will running proxy software (NAT) "break" a VPN connection? >>For example, I will have a customer with 128Kbps ISDN with a 3Com office >>connect ISDN router running NAT, DHCP and DNS. Will I be able to set up a >>VPN "through" the T/A or will I need to set the router up to route a >>subnet and hand out actual ip address. >"Not necessarily." You will not be able to create a VPN connect from outside >the NATed network, but you should be able to create one just fine from inside. Unless you can figure out the ports that the VPN stuff uses and create a static port mapping on the NAT/PAT box to forward it to the internal host...This *should* all work, unless the VPN stuff uses the IP addresses of the endpoints in part of the security scheme (I've heard of a few that do this). >In other words, the connection has to originate from within the "hidden" >netowrk. _AND_ the VPN cannot be constructed based on what the "hidden" >node's IP address is -- that's not really it's IP address at the other >end of the link. Ah...you basically just covered what I said above...ok -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456
Subject: RE: (usr-tc) Terminate Reasons...
From: Marcelo Souza <mpsouza@centroin.com.br>
Date: 1999-06-04 20:49:46
On Fri, 4 Jun 1999, Stephen Amadei wrote: |On Fri, 4 Jun 1999, Marcelo Souza wrote: | |> |> Here is the script that Clarence and Jason asked for: | |Marcelo, great script. I hope you don't mind, but I have made some |add-ons and IMHO improved the failure percentage to reflect more accurate |rates. ( Two bads and four goods would equal 50% in your code 2*100/4... |whereas it should be 33%... 2*100/(2+4) ). You are right, I was comparing with the goods not with the total. It's best this way. And my script was tied to my six DSPs. |I added per modem failure rates and some more output. I've included a |copy of the script with this email (be careful, some of the lines are |quite long and like to wordwrap...). I also modified it to |work with Cistron's latest RADIUS with USR TC Vender Specific Attributes. |1.3.4.beta18 or something... | |Other disclaimers... this script runs in OS/2 but should also work under |Linux and whatever with very slight changes... (and we all tinker with our |scripts... right? ;-) ) Since I have E1s here, I also should change the loop at print session to 30. But it's good. :-) - Marcelo |Basically you call it like: | |bad /path/to/detail ip.of.your.usr [card] | |Using the 'card' option turns off the per modem processing. | |Again, thanks, and I hope my changes help others. | |I gotta go swap some lame Quads... ;-) | | ----Steve |Stephen Amadei |Director of MIS |Dandy Connections, Inc. |Atlantic City, NJ
Subject: (usr-tc) NAT and VPN
From: Paul Farber <farber@admin.f-tech.net>
Date: 1999-06-05 05:26:29
Hey all... Will running proxy software (NAT) "break" a VPN connection? For example, I will have a customer with 128Kbps ISDN with a 3Com office connect ISDN router running NAT, DHCP and DNS. Will I be able to set up a VPN "through" the T/A or will I need to set the router up to route a subnet and hand out actual ip address. Paul D. Farber II Farber Technology Ph. 570-628-5303 Fax 570-628-5545 farber@admin.f-tech.net
Subject: Re: (usr-tc) HyperDSP E1 hardware failure on Boot
From: Jason Kelton <cascade@keltec.com.au>
Date: 1999-06-06 16:37:10
This is a multi-part message in MIME format. ------=_NextPart_000_0014_01BEB03A.D2A6EFA0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Brett, Before returning it, try reseating the daughterboard.. I've seen an = error like this before, and it was because the pins weren't seated = properly on the DSP. Regards, Jason Kelton Technical Consultant KelTEC Industries Pty. Ltd. ----- Original Message -----=20 From: Brett Murphy=20 To: usr-tc@lists.xmission.com=20 Sent: Friday, June 04, 1999 2:01 PM Subject: (usr-tc) HyperDSP E1 hardware failure on Boot Hi All, I am getting this error on boot up of a HyperDSP, does it need = to go back to it's maker? =20 !!----------> SDL2 for the PPC403 <------------!! =20 __ Enter Download Trigger __ =20 Flash Image Has Valid CRC, Loading Image.... =20 Diagnostic Power-Up Failure =20 Manufacturing Info -> 1AAA13M0 Mode/Env -> 1/0 Fault Code -> 0-8-25-1 Expected Data -> f0191420 Received Data -> f0191c20 Text Message -> Address Equals Data Test Failure Info Message -> Second read failed. Hard error indicated. =20 =20 All the best, Brett Murphy Technical Manager, Alphalink (Australia) PTY LTD ph: +61 3 9486-8844 fax: +61 3 9486-6822 email: me@murf.net =20 The contents of this email message may not be quoted, copied, reproduced or published in part or in whole, without the written authorization of Brett Murphy, Director, Alphalink (Australia) Pty Ltd. ------=_NextPart_000_0014_01BEB03A.D2A6EFA0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META content=3D"text/html; charset=3Diso-8859-1" = http-equiv=3DContent-Type> <META content=3D"MSHTML 5.00.2614.3401" name=3DGENERATOR> <STYLE></STYLE> </HEAD> <BODY bgColor=3D#ffffff> <DIV><FONT size=3D2>Brett,</FONT></DIV> <DIV>&nbsp;</DIV> <DIV><FONT size=3D2>Before returning it, try reseating the = daughterboard.. I've=20 seen an error like this before, and it was because the pins weren't = seated=20 properly on the DSP.</FONT></DIV> <DIV>&nbsp;</DIV> <DIV><FONT size=3D2>Regards,</FONT></DIV> <DIV>&nbsp;</DIV> <DIV><FONT size=3D2>Jason Kelton</FONT></DIV> <DIV><FONT size=3D2>Technical Consultant</FONT></DIV> <DIV><FONT size=3D2>KelTEC Industries Pty. Ltd.</FONT></DIV> <BLOCKQUOTE=20 style=3D"BORDER-LEFT: #000000 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: = 0px; PADDING-LEFT: 5px; PADDING-RIGHT: 0px"> <DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV> <DIV=20 style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: = black"><B>From:</B>=20 <A href=3D"mailto:me@murf.net" title=3Dme@murf.net>Brett Murphy</A> = </DIV> <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A=20 href=3D"mailto:usr-tc@lists.xmission.com"=20 title=3Dusr-tc@lists.xmission.com>usr-tc@lists.xmission.com</A> </DIV> <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Friday, June 04, 1999 = 2:01 PM</DIV> <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> (usr-tc) HyperDSP E1 = hardware=20 failure on Boot</DIV> <DIV><BR></DIV> <DIV><FONT color=3D#000000 size=3D2>Hi All, I am getting this error on = boot up of=20 a HyperDSP, does it need to go back to it's maker?</FONT></DIV> <DIV><FONT color=3D#000000 size=3D2></FONT>&nbsp;</DIV> <DIV><FONT size=3D2>!!----------&gt; SDL2 for the PPC403=20 &lt;------------!!</FONT></DIV> <DIV><FONT size=3D2></FONT>&nbsp;</DIV> <DIV><FONT size=3D2>__ Enter Download Trigger __</FONT></DIV> <DIV><FONT size=3D2></FONT>&nbsp;</DIV> <DIV><FONT size=3D2><BR>&nbsp;Flash Image Has Valid CRC, Loading=20 Image....</FONT></DIV> <DIV><FONT size=3D2></FONT>&nbsp;</DIV> <DIV><FONT size=3D2>&nbsp;Diagnostic Power-Up Failure</FONT></DIV> <DIV><FONT size=3D2></FONT>&nbsp;</DIV> <DIV><FONT size=3D2>&nbsp;Manufacturing Info -&gt;=20 = 1AAA13M0<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; = Mode/Env -&gt; 1/0<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; = Fault=20 Code -&gt; 0-8-25-1<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Expected Data = -&gt;=20 f0191420<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Received Data -&gt;=20 f0191c20<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Text Message -&gt; = Address=20 Equals Data Test Failure<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Info = Message=20 -&gt; Second read failed.&nbsp; Hard error indicated.</FONT></DIV> <DIV><FONT size=3D2></FONT>&nbsp;</DIV> <DIV><FONT size=3D2></FONT>&nbsp;</DIV> <DIV><FONT color=3D#000000 size=3D2><BR>All the best,<BR>Brett = Murphy<BR>Technical=20 Manager, Alphalink (Australia) PTY LTD<BR>ph: +61 3 9486-8844&nbsp; = fax: +61 3=20 9486-6822<BR>email: <A = href=3D"mailto:me@murf.net">me@murf.net</A></FONT></DIV> <DIV><FONT color=3D#000000 size=3D2></FONT>&nbsp;</DIV> <DIV><FONT color=3D#000000 size=3D2>The contents of this email message = may not be=20 quoted,<BR>copied, reproduced or published in part or in = whole,<BR>without the=20 written authorization of Brett Murphy,<BR>Director, Alphalink = (Australia) Pty=20 Ltd.</FONT></DIV></BLOCKQUOTE></BODY></HTML> ------=_NextPart_000_0014_01BEB03A.D2A6EFA0--
Subject: (usr-tc) OID IS?
From: Marshall Morgan <marshall@netdoor.com>
Date: 1999-06-06 20:25:10
Under (HiperARC v4.1.59-6): hiper1-arc1> sh accounting counter Accounting Counters Start Time: 23-MAY-1999 10:10:35 ACCOUNTING COUNTERS Number Of Local Users: 2 Number of Active Users: 101 What is the OID (all numbers please) for (Number of Active Users:) I know I could scrounge for it but it would really make my day if someone could beam it to me off the top of their head. Thank you, Marshall Morgan Internet Doorway, Inc (aka NETDOOR) http://www.netdoor.com
Subject: Re: (usr-tc) OID IS?
From: Ricky Beam <jfbeam@beaker.interpath.net>
Date: 1999-06-06 22:20:56
On Sun, 6 Jun 1999, Marshall Morgan wrote: [snip] >ACCOUNTING COUNTERS >Number Of Local Users: 2 >Number of Active Users: 101 > >What is the OID (all numbers please) for (Number of Active Users:) Ah HAH! usrUserManActiveUsers DESCRIPTION "The number of active users" -- .1.3.6.1.4.1.429.4.2.1.10 -- enterprise.usr.common.usrUserMan.usrUserManGroup.usrUserManActiveUsers --Ricky
Subject: Re: (usr-tc) OID IS?
From: Ricky Beam <jfbeam@beaker.interpath.net>
Date: 1999-06-06 22:20:56
On Sun, 6 Jun 1999, Marshall Morgan wrote: [snip] >ACCOUNTING COUNTERS >Number Of Local Users: 2 >Number of Active Users: 101 > >What is the OID (all numbers please) for (Number of Active Users:) Ah HAH! usrUserManActiveUsers DESCRIPTION "The number of active users" -- .1.3.6.1.4.1.429.4.2.1.10 -- enterprise.usr.common.usrUserMan.usrUserManGroup.usrUserManActiveUsers --Ricky
Subject: Re: (usr-tc) OID IS?
From: Mike Andrews <mandrews@termfrost.org>
Date: 1999-06-07 13:10:29
On Sun, 6 Jun 1999, Ricky Beam wrote: > On Sun, 6 Jun 1999, Marshall Morgan wrote: > [snip] > >ACCOUNTING COUNTERS > >Number Of Local Users: 2 > >Number of Active Users: 101 > > > >What is the OID (all numbers please) for (Number of Active Users:) > > Ah HAH! > > usrUserManActiveUsers DESCRIPTION "The number of active users" > -- .1.3.6.1.4.1.429.4.2.1.10 > -- enterprise.usr.common.usrUserMan.usrUserManGroup.usrUserManActiveUsers Hmmm... Does that count multilink users as one or two? Mike Andrews (icq 6602506) -- VP & Sysadmin, Digital Crescent, Frankfort KY mandrews@dcr.net -=- http://www.termfrost.org --=-=-- "A computer without a Microsoft operating system is like a dog without a brick tied to its head."
Subject: Re: (usr-tc) OID IS?
From: Ricky Beam <jfbeam@beaker.interpath.net>
Date: 1999-06-07 13:21:05
On Mon, 7 Jun 1999, Mike Andrews wrote: >> usrUserManActiveUsers DESCRIPTION "The number of active users" > >Hmmm... Does that count multilink users as one or two? As I see it, there are two possible definitions of "active users"... There's only one way to tell. --Ricky
Subject: RE: (usr-tc) OID IS?
From: Marshall Morgan <marshall@netdoor.com>
Date: 1999-06-07 14:46:11
> > Hmmm... Does that count multilink users as one or two? > Two. Marshall Morgan Internet Doorway, Inc. (aka NETDOOR)
Subject: (usr-tc) 3Com Web Search
From: Jim Logan <jim@top.net>
Date: 1999-06-07 15:46:06
Anyone got URL's bookmarked for 3Com info on USR TC Netserver and/or USR TC NMC info? All my searches come up with more stuff related to Hyper related info rather than the older equipment. Thanks! ******* Top Net InterNet Services ******** Omaha, Nebraska www.top.net Voice: (402) 339-5609
Subject: Re: (usr-tc) 3Com Web Search
From: David Cartwright <david_cartwright@mw.3com.com>
Date: 1999-06-07 16:04:18
Looking for support information?? Check out the Total Control technical support web site at http://totalservice.3com.com. Then select the "ISP Home Page" link. You'll find documentation, release notes, configuration procedures and more on NMC and NETServer. Dave Jim Logan <jim@top.net> on 06/07/99 03:46:06 PM Please respond to usr-tc@lists.xmission.com Sent by: Jim Logan <jim@top.net> cc: (David Cartwright/MW/US/3Com) Anyone got URL's bookmarked for 3Com info on USR TC Netserver and/or USR TC NMC info? All my searches come up with more stuff related to Hyper related info rather than the older equipment. Thanks! ******* Top Net InterNet Services ******** Omaha, Nebraska www.top.net Voice: (402) 339-5609 - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.
Subject: Re: (usr-tc) 3Com Web Search
From: todd_keister@3com.com
Date: 1999-06-07 16:32:49
Even better, you might try the 3KB Knowledge Base. We are trying to get everyone to use this resource before calling tech support. If you don't find the answer you're looking for, please let us know when you call tech support, and we will add it to our database. For those of you who are "Power Users" please help us to create solutions. If you are interested, please send me a private email, I will forward you information about how you could help us. Todd ;-} todd_keister@mw.3com.com PS: Jim: if you enter NETServer and CLI you will get an extensive listing of the NETServer Command Line Interface command set. It is a handy reference that we all use daily. :-} http://knowledgebase.3com.com/ "David Cartwright" <David_Cartwright@mw.3com.com> on 06/07/99 04:04:18 PM Please respond to usr-tc@lists.xmission.com Sent by: "David Cartwright" <David_Cartwright@mw.3com.com> cc: (Todd Keister/MW/US/3Com) Looking for support information?? Check out the Total Control technical support web site at http://totalservice.3com.com. Then select the "ISP Home Page" link. You'll find documentation, release notes, configuration procedures and more on NMC and NETServer. Dave Jim Logan <jim@top.net> on 06/07/99 03:46:06 PM Please respond to usr-tc@lists.xmission.com Sent by: Jim Logan <jim@top.net> cc: (David Cartwright/MW/US/3Com) Anyone got URL's bookmarked for 3Com info on USR TC Netserver and/or USR TC NMC info? All my searches come up with more stuff related to Hyper related info rather than the older equipment. Thanks! ******* Top Net InterNet Services ******** Omaha, Nebraska www.top.net Voice: (402) 339-5609 - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message. - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.
Subject: (usr-tc) Telnet Performance
From: Jim Johnson <jim@perigee.net>
Date: 1999-06-08 08:02:43
Does anyone out there have a tip or suggestion which would improve the performance of telnet when dialing in and accessing servers on the local network? I guess the performance is spotty because telnet connections use a lot of very small packets, but I would think there is some way to overcome this by prioritizing the data on port 23 or something. Thanks in advance, JJ
Subject: Re: (usr-tc) Telnet Performance
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1999-06-08 08:20:13
Thus spake Jim Johnson >Does anyone out there have a tip or suggestion which would improve the >performance of telnet when dialing in and accessing servers on the >local network? >I guess the performance is spotty because telnet connections use a lot >of very small packets, but I would think there is some way to overcome >this by prioritizing the data on port 23 or something. Make sure both ends of the connection have the Nagle algorithm implemented...this should be on by default, but might wanna double-check. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456
Subject: Re: (usr-tc) Telnet Performance
From: Brian <signal@shreve.net>
Date: 1999-06-08 08:49:06
On Tue, 8 Jun 1999, Jim Johnson wrote: > > > Does anyone out there have a tip or suggestion which would improve the > performance of telnet when dialing in and accessing servers on the local > network? > > I guess the performance is spotty because telnet connections use a lot > of very small packets, but I would think there is some way to overcome > this by prioritizing the data on port 23 or something. Hmm, well yeah, you could prioritize data on 23 in the cisco, but I doubt any performance problems you are seeing is from th router. Lowering MTU usually makes telnet very snappy. Doing an "ls -al" on a low MTU telnet session is like night and day vs. high MTU. But playing with MTU's can be blackmagic :) Brian > > Thanks in advance, > > JJ > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)
Subject: (usr-tc) (3Com - TotalControl): How do you monitor your network?
From: David Cartwright <david_cartwright@mw.3com.com>
Date: 1999-06-08 09:41:37
Dear 3Com Total Control users, How do you monitor your network? Would you be interested in a software product that manages SNMP alarms? Help us better meet your needs in this area by taking a few moments to complete the survey located at http://tsoweb.nsd.usr.com/survey/index.cfm. Thanks in advance for your valuable feedback and input. 3Com Customer Support To Subscribe/Unsubscribe to/from the 3Com Carrier User-Forums - http://totalservice.3com.com/forums/ To access the 3Com Knowledgebase - http://knowledgebase.3com.com To access 3Com Carrier documentation - http://totalservice.3com.com/documents/ To view 3Com Carrier Service Offerings - http://totalservice.3com.com/services/
Subject: (usr-tc) Format of Bulk Access on DualPRI Card
From: Ralph Helfenberger <r.helfenberger@comlight.ch>
Date: 1999-06-08 10:57:16
Hi all I should understand the Bulk format of the DS0 access on the DualPRI card for the TotalControl. From the documentation it is not clear to me, what the meaning of all bytes is. Has anybody more information about this? This is how it looks like: 1a01ffff0201ffff0201ffff0201ffff0201ffff0504060105040a030201ffff0201 and so on Best regards Ralph -- ========================================================================== R. Helfenberger Internet r.helfenberger@comlight.ch Comlight AG Tel +41 31 740 40 40 Tennisweg 21 Fax +41 31 740 40 90 3178 Boesingen Switzerland www.comlight.ch ==========================================================================
Subject: (usr-tc) 14 DSP with two HiperARC: Experience with Fallback
From: Ralph Helfenberger <r.helfenberger@comlight.ch>
Date: 1999-06-08 11:11:08
Hi One of the feautures of the HiPer technology is the possibility to have redundancy. As far as I understood it is possible to have two HiPer ARC in a chassis. If one HiPer ARC fails the other takes over the whole traffic. For me there are some question marks with this functionality: - Has anybody tested this feature? - What is the criteria for a HiPer ARC to be "failed". Who makes the decision about switching the HiPer DSP from the failed HiPer ARC to the functional HiPer ARC? Hope to hear your experiences. Ralph -- ========================================================================== R. Helfenberger Internet r.helfenberger@comlight.ch Comlight AG Tel +41 31 740 40 40 Tennisweg 21 Fax +41 31 740 40 90 3178 Boesingen Switzerland www.comlight.ch ==========================================================================
Subject: (usr-tc) WildWire modem
From: Brian <signal@shreve.net>
Date: 1999-06-08 13:29:16
Has anyone seen any problems with a new modem Compaq is using called "WildWire"? Tech support has been telling me this modem has been giving them alot of problems, namely reporting the computer you are dialing is not answering. Brian Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)
Subject: RE: (usr-tc) WildWire modem
From: Brian <signal@shreve.net>
Date: 1999-06-08 15:23:25
Thanks we will try that. On Tue, 8 Jun 1999, Robb Bryn wrote: > We've found the Wildwires to be absolutely worthless. In order to get them > to connect to our system you have force a pause after dialing (we put 5 ,'s > after the number). The modem apparently tries to connect immediately after > dialing the number without waiting for the other modem to pick up. We're > running DSP's on PRI with pickup before the first ring. I couldn't imagine > what it would be like trying to get it to connect on standard phone lines > with variable ring counts. > > The wildwires that do connect get poor performance (usually in the 19.2 to > 28.8 range on a line that normally connect 46-52k). I've never seen one > connect with v.90. > > Robb Bryn > Cape Fear.Net > > > > -----Original Message----- > > From: owner-usr-tc@lists.xmission.com > > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Brian > > Sent: Tuesday, June 08, 1999 2:29 PM > > To: USRobotics TC Mailing List > > Subject: (usr-tc) WildWire modem > > > > > > > > Has anyone seen any problems with a new modem Compaq is using called > > "WildWire"? Tech support has been telling me this modem has > > been giving > > them alot of problems, namely reporting the computer you are > > dialing is > > not answering. > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)
Subject: RE: (usr-tc) WildWire modem
From: Robb Bryn <rbryn@cape-fear.net>
Date: 1999-06-08 15:30:38
We've found the Wildwires to be absolutely worthless. In order to get them to connect to our system you have force a pause after dialing (we put 5 ,'s after the number). The modem apparently tries to connect immediately after dialing the number without waiting for the other modem to pick up. We're running DSP's on PRI with pickup before the first ring. I couldn't imagine what it would be like trying to get it to connect on standard phone lines with variable ring counts. The wildwires that do connect get poor performance (usually in the 19.2 to 28.8 range on a line that normally connect 46-52k). I've never seen one connect with v.90. Robb Bryn Cape Fear.Net > -----Original Message----- > From: owner-usr-tc@lists.xmission.com > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Brian > Sent: Tuesday, June 08, 1999 2:29 PM > To: USRobotics TC Mailing List > Subject: (usr-tc) WildWire modem > > > > Has anyone seen any problems with a new modem Compaq is using called > "WildWire"? Tech support has been telling me this modem has > been giving > them alot of problems, namely reporting the computer you are > dialing is > not answering. >
Subject: (usr-tc) radius server
From: zip-usrtc@ran.zipcon.net
Date: 1999-06-09 09:13:53
I recently had a short downtime on the primary auth and acct server. The TC then started using the backup server as expected. However, once the primary server was back up, the TC never switched back to it. It continues to use the backup server. Is there a simple setting I'm missing? Thanks, Dan
Subject: (usr-tc) No carrier and Disconnects
From: Steve Johnson <linuxnut@sonic.net>
Date: 1999-06-09 09:40:38
I'm running DSP's and PRI, My customers are complaining that sometimes when they call in they get dead air, no ringing, no carrier tones. Anyone experience this before? Anyone know the solution? PacBell tells me it is on my end. My other problem is that my users get disconnected allot. I get complaints that they can not stay on-line for more then a few minutes at a time. This doesn't happen to all of them just a small group of people, modems ranging from USR Sportster 33.6's to no-name 56K's I've been unable to pin point it down to just one brand of modem. But I did think it was odd the the Sportster 33.6's had the same problem, this makes me think its not a V.90 issue. Any help on these issues will be greatly appreciated. Thanks. -Steve -- ---------------------------------------------------------------------------- Steve Johnson Sonic Sys Admin (707)522-1001 (33.6kbps) (707)522-1000 (Voice) e-mail linuxnut at sonic.net http://www.sonic.net ---------------------------------------------------------------------------- "Knowing others is wisdom, knowing your self is Enlightenment." -- Lao-Tzu
Subject: Re: (usr-tc) No carrier and Disconnects
From: Brice Ligget <ligget@twoalpha.net>
Date: 1999-06-09 11:02:13
I've had some vague reports of this as well but I can't find a reason for it. It even happened to me once. I was at a customers site, successful login, disconnect maybe 15 seconds later. Reconnected, no problems. Played with it for about half an hour, it never happened again. I don't know what to think. Never had the dead air problem however. At 09:40 AM 6/9/99 -0700, you wrote: > > >My other problem is that my users get disconnected allot. I get complaints >that they can not stay on-line for more then a few minutes at a time. This >doesn't happen to all of them just a small group of people, modems ranging >from USR Sportster 33.6's to no-name 56K's I've been unable to pin point it >down to just one brand of modem. But I did think it was odd the the >Sportster 33.6's had the same problem, this makes me think its not a V.90 >issue. > > >Any help on these issues will be greatly appreciated. Thanks. > > >-Steve > > > >-- > ---------------------------------------------------------------------------- > Steve Johnson Sonic Sys Admin > (707)522-1001 (33.6kbps) (707)522-1000 (Voice) > e-mail linuxnut at sonic.net http://www.sonic.net > ---------------------------------------------------------------------------- > "Knowing others is wisdom, knowing your self is Enlightenment." > -- Lao-Tzu > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. -- Brice Ligget ligget@twoalpha.net If television was the main reason for the violence in schools, and the massacres, it wouldn't happen once or twice a year. If TV had that kind of impact it would happen every five minutes," Pungente told the New York Daily News.
Subject: Re: (usr-tc) radius server
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1999-06-09 12:20:35
Thus spake zip-usrtc@ran.zipcon.net >I recently had a short downtime on the primary auth and acct server. >The TC then started using the backup server as expected. However, >once the primary server was back up, the TC never switched back to it. >It continues to use the backup server. Is there a simple setting I'm >missing? Thanks, Dan Yup, set radius authentication_algorithm fall_through. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456
Subject: RE: (usr-tc) WildWire modem
From: Paul M. Oster <devious@minot.com>
Date: 1999-06-09 12:47:01
I'll add a Me too, its a v.90/G.Lite modem, and I've personally ridden through a call to compaq's tech support with one of my users... worthless, the only thing I've seen that is worse than the Rockwell HCF. Why cant these manufacturers get a clue and pick something that works for once, an $9.99 win modem will NOT make your customers happy. On the bright side, the HCF modems dont connect above 28.8 to portmasters either (so I've been told by my counterpart at the telco :) Paul M. Oster <devious@minot.com> http://www.minot.com/ Magic Internet Services (701) 838-1265 Minots FIRST Internet Connection
Subject: Re: (usr-tc) radius server
From: todd_keister@3com.com
Date: 1999-06-09 16:44:16
Dan: The radius server will not automatically switch back once the primary comes back up. The Radius servers support fail-over, which means that if the server goes down, it will fail over to the next defined server. In this case, just stop the Radius service on your secondary server, and your TC should fail-over back to the primary. Hope this helps. Todd ;-} zip-usrtc@ran.zipcon.net on 06/09/99 11:13:53 AM Please respond to usr-tc@lists.xmission.com Sent by: zip-usrtc@ran.zipcon.net cc: (Todd Keister/MW/US/3Com) I recently had a short downtime on the primary auth and acct server. The TC then started using the backup server as expected. However, once the primary server was back up, the TC never switched back to it. It continues to use the backup server. Is there a simple setting I'm missing? Thanks, Dan - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.
Subject: Re: (usr-tc) radius server
From: Marcelo Souza <mpsouza@centroin.com.br>
Date: 1999-06-09 16:58:54
On Wed, 9 Jun 1999, Jeff Mcadams wrote: |Thus spake zip-usrtc@ran.zipcon.net |>I recently had a short downtime on the primary auth and acct server. |>The TC then started using the backup server as expected. However, |>once the primary server was back up, the TC never switched back to it. |>It continues to use the backup server. Is there a simple setting I'm |>missing? Thanks, Dan | |Yup, set radius authentication_algorithm fall_through. I had the same problem here, and the TC was already set to fall_through. You must use the: enabLE prioRITISE_FIRST_ACCOUNTING_SERVER_IN_A_GROUP To have the service back to the first server. - Marcelo
Subject: Re: (usr-tc) 800 Service on TC
From: Dan Hollis <goemon@sasami.anime.net>
Date: 1999-06-09 16:59:22
On Wed, 9 Jun 1999, Greg Coffey wrote: > service. Is there a way to segregate/track calls coming in via the 800 > calls v. local calls? Have any of you done this before? Thats what DNIS is for. -Dan
Subject: (usr-tc) 800 Service on TC
From: Greg Coffey <greg@coffey.com>
Date: 1999-06-09 17:32:20
We are interested in offering toll free service to our customers that are traveling. Ideally, I would like to get an 800 number and aim it at one of our bigger pops (TC hubs). All they would have to do is change the phone number to dial in. We would charge them so much per minute for the service. Is there a way to segregate/track calls coming in via the 800 calls v. local calls? Have any of you done this before? Thanks, Greg Coffey, CoffeyNet Voice 307-234-5443 307-234-5446 Fax ==================================================================== 142 S. Center St. 3Com v.90 56k $20 in Casper & Douglas Casper, WY 82601 Local Internet for Rawlins, Wheatland, Lusk, http://WWW.COFFEY.COM Chugwater, Pinedale, & Lander, WY
Subject: (usr-tc) FS: USR Hyper ARC w/ NMC upgrade
From: Steve Rivera <sales@wrca.net>
Date: 1999-06-09 17:46:49
Available now. Looking for offers. 1- USR HiPer ARC card set with NMC ram upgrade, new in box. Also Available: 5- Netserver 8I $1600 4- Netserver 8 v34 $750 2- 2059 Bundles $3000 1- 1866 Bundle $4000 All goods guaranteed to work :) Steve Rivera - sales@wrca.net - 732-833-2111 http://www.wrca.net WTB: Cisco 2514, NP-1FE, (8) IBM 8235-5575 v34 Features
Subject: Re: (usr-tc) radius server
From: todd_keister@3com.com
Date: 1999-06-09 17:49:02
Dyslexia IS a terrible thing..... It is actually the Hiper ARC that will fail over to the secondary Radius Server, and not a Radius Server that fails over. But you still need only to stop the secondary server for the Hiper ARC to fail over..... bimfr Todd ;-} Todd_Keister@3com.com on 06/09/99 04:44:16 PM Please respond to usr-tc@lists.xmission.com Sent by: Todd_Keister@3com.com cc: (Todd Keister/MW/US/3Com) Dan: The radius server will not automatically switch back once the primary comes back up. The Radius servers support fail-over, which means that if the server goes down, it will fail over to the next defined server. In this case, just stop the Radius service on your secondary server, and your TC should fail-over back to the primary. Hope this helps. Todd ;-} zip-usrtc@ran.zipcon.net on 06/09/99 11:13:53 AM Please respond to usr-tc@lists.xmission.com Sent by: zip-usrtc@ran.zipcon.net cc: (Todd Keister/MW/US/3Com) I recently had a short downtime on the primary auth and acct server. The TC then started using the backup server as expected. However, once the primary server was back up, the TC never switched back to it. It continues to use the backup server. Is there a simple setting I'm missing? Thanks, Dan - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message. - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.
Subject: Re: (usr-tc) radius server
From: John Martin <jmartin@delrio.com>
Date: 1999-06-09 19:20:30
From the Knowledgebase (I've just gone through the same problem) From the command line interface (CLI) Type "set authentication secondary_server 0.0.0.0" Type "save all" By now, the primary server will be the active server. Type "show authentication settings" to verify Type "set authentication secondary_server 2xx.xxx.xxx.xx" Type "set authentication secondary_secret XXXXXX" Type "save all" And you are done. At 08:47 PM 6/9/99 -0300, you wrote: >On Wed, 9 Jun 1999 Todd_Keister@3com.com wrote: > >| It is actually the Hiper ARC that will fail over to the secondary Radius >|Server, and not a Radius Server that fails over. But you still need only to >|stop the secondary server for the Hiper ARC to fail over..... > > Todd, I'm sure that if you set (in the ARC): > > enabLE prioRITISE_FIRST_ACCOUNTING_SERVER_IN_A_GROUP > > The accounting will go back to the primary server when it came up >again. You don't need to stop the backup server. > > >- Marcelo > >| >| >| Dan: >| >| >| The radius server will not automatically switch back once the primary >comes >|back up. The Radius servers support fail-over, which means that if the server >|goes down, it will fail over to the next defined server. In this case, just >|stop the Radius service on your secondary server, and your TC should fail-over >|back to the primary. >| >| Hope this helps. >| >| Todd ;-} >| >| >| >| >| >| >|zip-usrtc@ran.zipcon.net on 06/09/99 11:13:53 AM >| >|Please respond to usr-tc@lists.xmission.com >| >|Sent by: zip-usrtc@ran.zipcon.net >| >| >|To: usr-tc@lists.xmission.com >|cc: (Todd Keister/MW/US/3Com) >|Subject: (usr-tc) radius server >| >| >| >| >| >|I recently had a short downtime on the primary auth and acct server. >|The TC then started using the backup server as expected. However, >|once the primary server was back up, the TC never switched back to it. >|It continues to use the backup server. Is there a simple setting I'm >|missing? Thanks, Dan >| >|- >| To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" >| with "unsubscribe usr-tc" in the body of the message. >| For information on digests or retrieving files and old messages send >| "help" to the same address. Do not use quotes in your message. >| >| >| >| >| >| >|- >| To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" >| with "unsubscribe usr-tc" in the body of the message. >| For information on digests or retrieving files and old messages send >| "help" to the same address. Do not use quotes in your message. >| >| >| >| >| >| >|- >| To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" >| with "unsubscribe usr-tc" in the body of the message. >| For information on digests or retrieving files and old messages send >| "help" to the same address. Do not use quotes in your message. >| > >- Marcelo > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message.
Subject: Re: (usr-tc) 800 Service on TC
From: Ricky Beam <jfbeam@beaker.interpath.net>
Date: 1999-06-09 19:57:12
On Wed, 9 Jun 1999, Greg Coffey wrote: >We are interested in offering toll free service to our customers that are >traveling. Ideally, I would like to get an 800 number and aim it at one of >our bigger pops (TC hubs). All they would have to do is change the phone >number to dial in. We would charge them so much per minute for the >service. Is there a way to segregate/track calls coming in via the 800 >calls v. local calls? Have any of you done this before? Yes and yes. Using a PRI, the RADIUS system will need to log DNIS. Your billing software (script, goat, whatever) will need to pay attention to the DNIS information. --Ricky
Subject: Re: (usr-tc) radius server
From: Marcelo Souza <mpsouza@centroin.com.br>
Date: 1999-06-09 20:47:57
On Wed, 9 Jun 1999 Todd_Keister@3com.com wrote: | It is actually the Hiper ARC that will fail over to the secondary Radius |Server, and not a Radius Server that fails over. But you still need only to |stop the secondary server for the Hiper ARC to fail over..... Todd, I'm sure that if you set (in the ARC): enabLE prioRITISE_FIRST_ACCOUNTING_SERVER_IN_A_GROUP The accounting will go back to the primary server when it came up again. You don't need to stop the backup server. - Marcelo | | | Dan: | | | The radius server will not automatically switch back once the primary comes |back up. The Radius servers support fail-over, which means that if the server |goes down, it will fail over to the next defined server. In this case, just |stop the Radius service on your secondary server, and your TC should fail-over |back to the primary. | | Hope this helps. | | Todd ;-} | | | | | | |zip-usrtc@ran.zipcon.net on 06/09/99 11:13:53 AM | |Please respond to usr-tc@lists.xmission.com | |Sent by: zip-usrtc@ran.zipcon.net | | |To: usr-tc@lists.xmission.com |cc: (Todd Keister/MW/US/3Com) |Subject: (usr-tc) radius server | | | | | |I recently had a short downtime on the primary auth and acct server. |The TC then started using the backup server as expected. However, |once the primary server was back up, the TC never switched back to it. |It continues to use the backup server. Is there a simple setting I'm |missing? Thanks, Dan | |- | To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" | with "unsubscribe usr-tc" in the body of the message. | For information on digests or retrieving files and old messages send | "help" to the same address. Do not use quotes in your message. | | | | | | |- | To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" | with "unsubscribe usr-tc" in the body of the message. | For information on digests or retrieving files and old messages send | "help" to the same address. Do not use quotes in your message. | | | | | | |- | To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" | with "unsubscribe usr-tc" in the body of the message. | For information on digests or retrieving files and old messages send | "help" to the same address. Do not use quotes in your message. | - Marcelo
Subject: Re: (usr-tc) radius server
From: Marcelo Souza <mpsouza@centroin.com.br>
Date: 1999-06-09 21:50:41
You mean that every time your first server go down then up, you are going to do this procedure? I have already tested this, the default is to not give the priority to the first server. You only need to change the default. - Marcelo On Wed, 9 Jun 1999, John Martin wrote: |>From the Knowledgebase (I've just gone through the same problem) | |>From the command line interface (CLI) | Type "set authentication secondary_server 0.0.0.0" | Type "save all" By now, the primary server will be the active server. Type |"show authentication settings" to verify | Type "set authentication secondary_server 2xx.xxx.xxx.xx" | Type "set authentication secondary_secret XXXXXX" | Type "save all" | |And you are done. | |At 08:47 PM 6/9/99 -0300, you wrote: |>On Wed, 9 Jun 1999 Todd_Keister@3com.com wrote: |> |>| It is actually the Hiper ARC that will fail over to the secondary Radius |>|Server, and not a Radius Server that fails over. But you still need only to |>|stop the secondary server for the Hiper ARC to fail over..... |> |> Todd, I'm sure that if you set (in the ARC): |> |> enabLE prioRITISE_FIRST_ACCOUNTING_SERVER_IN_A_GROUP |> |> The accounting will go back to the primary server when it came up |>again. You don't need to stop the backup server. |> |> |>- Marcelo |> |>| |>| |>| Dan: |>| |>| |>| The radius server will not automatically switch back once the primary |>comes |>|back up. The Radius servers support fail-over, which means that if the |server |>|goes down, it will fail over to the next defined server. In this case, just |>|stop the Radius service on your secondary server, and your TC should |fail-over |>|back to the primary. |>| |>| Hope this helps. |>| |>| Todd ;-} |>| |>| |>| |>| |>| |>| |>|zip-usrtc@ran.zipcon.net on 06/09/99 11:13:53 AM |>| |>|Please respond to usr-tc@lists.xmission.com |>| |>|Sent by: zip-usrtc@ran.zipcon.net |>| |>| |>|To: usr-tc@lists.xmission.com |>|cc: (Todd Keister/MW/US/3Com) |>|Subject: (usr-tc) radius server |>| |>| |>| |>| |>| |>|I recently had a short downtime on the primary auth and acct server. |>|The TC then started using the backup server as expected. However, |>|once the primary server was back up, the TC never switched back to it. |>|It continues to use the backup server. Is there a simple setting I'm |>|missing? Thanks, Dan |>| |>|- |>| To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" |>| with "unsubscribe usr-tc" in the body of the message. |>| For information on digests or retrieving files and old messages send |>| "help" to the same address. Do not use quotes in your message. |>| |>| |>| |>| |>| |>| |>|- |>| To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" |>| with "unsubscribe usr-tc" in the body of the message. |>| For information on digests or retrieving files and old messages send |>| "help" to the same address. Do not use quotes in your message. |>| |>| |>| |>| |>| |>| |>|- |>| To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" |>| with "unsubscribe usr-tc" in the body of the message. |>| For information on digests or retrieving files and old messages send |>| "help" to the same address. Do not use quotes in your message. |>| |> |>- Marcelo |> |> |>- |> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" |> with "unsubscribe usr-tc" in the body of the message. |> For information on digests or retrieving files and old messages send |> "help" to the same address. Do not use quotes in your message. | | | |- | To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" | with "unsubscribe usr-tc" in the body of the message. | For information on digests or retrieving files and old messages send | "help" to the same address. Do not use quotes in your message. | - Marcelo
Subject: RE: (usr-tc) radius server (SOLUTION)
From: Mike Wronski <mike@coredump.ae.usr.com>
Date: 1999-06-10 09:53:28
|-----Original Message----- |From: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Marcelo Souza |Sent: Wednesday, June 09, 1999 7:51 PM |To: usr-tc@lists.xmission.com |Subject: Re: (usr-tc) radius server | | | | You mean that every time your first server go down then up, you |are going to do this procedure? | I have already tested this, the default is to not give the |priority to the first server. You only need to change the default. | |- Marcelo | To make accounting return to primary after using "Primary-First Backup" you do the following (ONCE). Configure a primary accounting server & Secret Configure a primary first backup (NOT SECONDARY) & secret. "enable prioRITISE_FIRST_ACCOUNTING_SERVER_IN_A_GROUP" With the above accepting will act like authentication with algo set to "FALL-THROUGH". The 3KB solution below is deprecated ($5 word) and only applies to HARC code that did not have the prioritize_first.. command (pre 4.1.59-6). |On Wed, 9 Jun 1999, John Martin wrote: | ||>From the Knowledgebase (I've just gone through the same problem) || ||>From the command line interface (CLI) || Type "set authentication secondary_server 0.0.0.0" || Type "save all" By now, the primary server will be the active |server. Type ||"show authentication settings" to verify || Type "set authentication secondary_server 2xx.xxx.xxx.xx" || Type "set authentication secondary_secret XXXXXX" || Type "save all" || ||And you are done.
Subject: Re: (usr-tc) X2 key for NMC?
From: Clayton Zekelman <clayton@mnsi.net>
Date: 1999-06-10 09:59:15
It gone from their website? Thats no good. I've still got half a dozen activation keys left to go on undeployed chassis that we've paid for. I think 3COM has some explaining to do here. At 11:18 PM 6/10/99 +1000, you wrote: > >Can anyone tell me what I need to sacrafice in order to obtain an X2 key >for an NMC? > >3COM tell me they can't generate them. The generation page has >disappeared from their web site... Paying sh*tloads for a support >contract doesn't help either (we already have the support). > >------------------------------------------------------------------------ >Bob Purdon, Ground Floor, Marine Board Building >Technical Manager (Tas/Vic), 1 Franklin Wharf, Tas 7000 >Southern Internet Services. +61 (3) 6234 7444 > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > --- Clayton Zekelman Managed Network Systems Inc. (MNSi) 875 Ouellette Avenue Windsor, Ontario N9A 4J6 tel. 519-985-8410 fax. 519-258-3009
Subject: RE: (usr-tc) (USR-TC) 800 SERVICE ON T
From: Jason Cropper <jason@clearsail.net>
Date: 1999-06-10 10:28:30
Would you be so kind as to publish an entry from your RADIUS user list which allows for this type of service to the customer? Jason > -----Original Message----- > From: owner-usr-tc@lists.xmission.com > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Jeff Binkley > Sent: Thursday, June 10, 1999 11:05 > To: USR-TC@lists.xmission.com > Subject: (usr-tc) (USR-TC) 800 SERVICE ON T > > > > > > > U>We are interested in offering toll free service to our customers that > U>are traveling. Ideally, I would like to get an 800 number and aim it > U>at one of our bigger pops (TC hubs). All they would have to do is > U>change the phone number to dial in. We would charge them so much per > U>minute for the service. Is there a way to segregate/track calls > U>coming in via the 800 calls v. local calls? Have any of you done this > U>before? > > > Yep. We had telco assign another phone number to our PRIs and we have > the 800 number mapped to it. We also use this to keep folks from > dialing in on 800 service who aren't set up for it. We use DNIS > screening in RADIUS to enabled them once they've signed up and filled > out our forms for 800 service. > > > > Jeff Binkley > ASA Network Computing > > CMPQwk 1.42 9999 > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >
Subject: Re: (usr-tc) X2 key for NMC?
From: Ricky Beam <jfbeam@bluetopia.net>
Date: 1999-06-10 10:52:17
On Thu, 10 Jun 1999, Bob Purdon (Lists) wrote: >Can anyone tell me what I need to sacrafice in order to obtain an X2 key >for an NMC? > >3COM tell me they can't generate them. The generation page has >disappeared from their web site... Paying sh*tloads for a support >contract doesn't help either (we already have the support). If you paid for an X2 upgrade, then they are required by law to give you an enable code (or your money back) -- Talk to LaChina McDonald (X2 Administrator) @ 847-342-6340 --Ricky PS: That number is two years old; YMMV.
Subject: (usr-tc) (USR-TC) 800 SERVICE ON T
From: Jeff Binkley <jeff.binkley@asacomp.com>
Date: 1999-06-10 11:05:00
U>We are interested in offering toll free service to our customers that U>are traveling. Ideally, I would like to get an 800 number and aim it U>at one of our bigger pops (TC hubs). All they would have to do is U>change the phone number to dial in. We would charge them so much per U>minute for the service. Is there a way to segregate/track calls U>coming in via the 800 calls v. local calls? Have any of you done this U>before? Yep. We had telco assign another phone number to our PRIs and we have the 800 number mapped to it. We also use this to keep folks from dialing in on 800 service who aren't set up for it. We use DNIS screening in RADIUS to enabled them once they've signed up and filled out our forms for 800 service. Jeff Binkley ASA Network Computing CMPQwk 1.42 9999
Subject: RE: (usr-tc) (USR-TC) 800
From: Jeff Binkley <jeff.binkley@asacomp.com>
Date: 1999-06-10 12:50:00
Sure I can but what are you looking for ? It's pretty straight forward. I use the 3Com S/A RADIUS server and we have DNIS tracking enabled. The for customers who have just local service we allow them to connect with that number in RADIUS. If they have both local and 800 service, we enter both numbers seperated by a colon in RADIUS. Here's a typical entry: Local only: +4754000 Local and 800: +4754000:+4751234 We have our 800 provider map our 800 number to the 475-1234 phone number and we don't publish that local numebr anywhere. Jeff Binkley ASA Network Computing u>Would you be so kind as to publish an entry from your RADIUS user list u>which allows for this type of service to the customer? u>Jason u>> -----Original Message----- u>> From: owner-usr-tc@lists.xmission.com u>> [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Jeff Binkley u>> Sent: Thursday, June 10, 1999 11:05 u>> To: USR-TC@lists.xmission.com u>> Subject: (usr-tc) (USR-TC) 800 SERVICE ON T u>> u>> u>> u>> u>> u>> u>> U>We are interested in offering toll free service to our customers u>> U>that are traveling. Ideally, I would like to get an 800 number u>> U>and aim it at one of our bigger pops (TC hubs). All they would u>> U>have to do is change the phone number to dial in. We would charge u>> U>them so much per minute for the service. Is there a way to u>> U>segregate/track calls coming in via the 800 calls v. local calls? u>> U>Have any of you done this before? u>> u>> u>> Yep. We had telco assign another phone number to our PRIs and we u>> have the 800 number mapped to it. We also use this to keep folks u>> from dialing in on 800 service who aren't set up for it. We use u>> DNIS screening in RADIUS to enabled them once they've signed up and u>> filled out our forms for 800 service. u>> u>> u>> u>> Jeff Binkley u>> ASA Network Computing u>> u>> CMPQwk 1.42 9999 u>> u>> - u>> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" u>> with "unsubscribe usr-tc" in the body of the message. u>> For information on digests or retrieving files and old messages u>> send "help" to the same address. Do not use quotes in your u>message. > u>- u> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" u> with "unsubscribe usr-tc" in the body of the message. u> For information on digests or retrieving files and old messages send u> "help" to the same address. Do not use quotes in your message. u> CMPQwk 1.42 9999
Subject: (usr-tc) NEED TO BUY (1) 000976-0
From: Andrew:PC Global, Inc. <andrew@pcglobal.net>
Date: 1999-06-10 16:10:45
Hello- Need to buy (1) USR Total Control Netserver Card part # 000976-0 Includes these 3 parts: 69-0001003 69-0001393 67-000209 All parts must have these numbers on the white sticker. CANNOT use equivalents. If you have any of these card sets, please send private e-mail. Thank you all for your time. Andrew Shlensky **************************** PC Global, Inc. (305) 667-2111 tel (305) 667-3636 fax (305) 216-8638 mobile URL: http://www.pcglobal.net E-MAIL: andrew@pcglobal.net ICQ: 21219089 Computer Service Parts SpEciaLiSts! ALSO:SALES of New/Used PCs,Laptops Communication & Networking,Monitors Printers, Hard Drives, Midrange/Mainframe. Hard to Get Parts. We buy and sell all types of GEAR- ****************************
Subject: (usr-tc) X2 key for NMC?
From: Bob Purdon (Lists) <lists@aussie.nu>
Date: 1999-06-10 23:18:22
Can anyone tell me what I need to sacrafice in order to obtain an X2 key for an NMC? 3COM tell me they can't generate them. The generation page has disappeared from their web site... Paying sh*tloads for a support contract doesn't help either (we already have the support). Bob Purdon, Ground Floor, Marine Board Building Technical Manager (Tas/Vic), 1 Franklin Wharf, Tas 7000 Southern Internet Services. +61 (3) 6234 7444
Subject: (usr-tc) Radius Config Question
From: Paul M. Oster <devious@minot.com>
Date: 1999-06-11 10:34:32
How are the rest of you doing static/dedicated accounts in radius.... I'm doing this USERNAME Password = "PASSWORD" Session-Timeout = 0, Idle-Timeout = 0, Service-Type = Framed, Framed-Protocol = PPP, Framed-IP-Address = 192.168.200.234, Framed-IP-Netmask = 255.255.255.255, Framed-Routing = Broadcast, Simultaneous-Use = 1, Framed-Compression = Van-Jacobson-TCP-IP and would like to be able to take the passwords out of that file, and have it use my /etc/passwd like my non-static accounts do... any suggestions on how to do that... And even better, does anyone have some good radius references? The only docs I can find came with my radius server and are lacking... and there is not a book out there that I know of... tia Paul p.s. Username, password and IP-Address are changed for example purposes.
Subject: RE: (usr-tc) Radius Config Question
From: Jason Cropper <jason@clearsail.net>
Date: 1999-06-11 10:53:44
We do static IP assignment in the modem bank itself through it's built in user interface. Here is our default user entry in our "users" file for Merit RADIUS: DEFAULT Authentication-Type = Unix-PW Service-Type = Framed, Simultaneous-Use = 1, Port-Limit = 1, Session-Timeout = 14400, Idle-Timeout = 900, Filter-Id = filter, <-- (we filter the www) Framed-Protocol = PPP, Framed-IP-Netmask = 255.255.255.0, Framed-Routing = None, Framed-MTU = 1500, Framed-Compression = Van-Jacobson-TCP-IP If you check you docs you'll find this: # Unix-PW - Indicates the local UNIX /etc/passwd file is to be used. # Realm - Use "authfile" to map user specified realm (<id>@<realm>) # to server. If no realm is specified, authentication fails. # AFS-Krb - For AFS Kerberos authentication at the default Kerberos realm. # MIT-Krb - For MIT Kerberos authentication at the default Kerberos realm. # RADIUS - Request is to be relayed to another RADIUS server # (name specified as DEFAULT_RADIUS_SERVER at compile time). # TACACS - Make extended (and encrypted) request to TACACS server # (name specified as DEFAULT_TACACS_SERVER at compile time). # None - This entry is not to be used for authentication. # KCHAP - Kerberos CHAP database lookup to be done in this machine. # MNET - Strange and archaic Merit authentiation. > -----Original Message----- > From: owner-usr-tc@lists.xmission.com > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Paul M. Oster > Sent: Friday, June 11, 1999 10:35 > To: usr-tc@lists.xmission.com > Subject: (usr-tc) Radius Config Question > > > > How are the rest of you doing static/dedicated accounts in > radius.... > > I'm doing this > > USERNAME Password = "PASSWORD" > Session-Timeout = 0, > Idle-Timeout = 0, > Service-Type = Framed, > Framed-Protocol = PPP, > Framed-IP-Address = 192.168.200.234, > Framed-IP-Netmask = 255.255.255.255, > Framed-Routing = Broadcast, > Simultaneous-Use = 1, > Framed-Compression = Van-Jacobson-TCP-IP > > and would like to be able to take the passwords out of that > file, and have it use my /etc/passwd like my non-static accounts > do... any suggestions on how to do that... > > And even better, does anyone have some good radius references? The only > docs I can find came with my radius server and are lacking... and there is > not a book out there that I know of... tia > > > Paul > > p.s. Username, password and IP-Address are changed for example purposes. > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >
Subject: Re: (usr-tc) X2 key for NMC?
From: David Cartwright <david_cartwright@mw.3com.com>
Date: 1999-06-11 11:20:05
Actually, the x2 key generator is still on the 3Com web site. - From the 3Com Home Page, select "Service and Support Home" - Then "56K Central" - There's a link at the bottom of the 56K Central Home Page For information on Total Control, NETServer and Modem Pool products, please see the Remote Access web site at http://www.3com.com/56kremote/ - Go to this site - Once there, if you scroll down the page, look for the sentence that starts with Step 3: Enable the 56kbps/x2 feature key. Dave Clayton Zekelman <clayton@MNSi.Net> on 06/10/99 08:59:15 AM Please respond to usr-tc@lists.xmission.com Sent by: Clayton Zekelman <clayton@MNSi.Net> cc: (David Cartwright/MW/US/3Com) It gone from their website? Thats no good. I've still got half a dozen activation keys left to go on undeployed chassis that we've paid for. I think 3COM has some explaining to do here. At 11:18 PM 6/10/99 +1000, you wrote: > >Can anyone tell me what I need to sacrafice in order to obtain an X2 key >for an NMC? > >3COM tell me they can't generate them. The generation page has >disappeared from their web site... Paying sh*tloads for a support >contract doesn't help either (we already have the support). > >------------------------------------------------------------------------ >Bob Purdon, Ground Floor, Marine Board Building >Technical Manager (Tas/Vic), 1 Franklin Wharf, Tas 7000 >Southern Internet Services. +61 (3) 6234 7444 > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > --- Clayton Zekelman Managed Network Systems Inc. (MNSi) 875 Ouellette Avenue Windsor, Ontario N9A 4J6 tel. 519-985-8410 fax. 519-258-3009 - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.
Subject: (usr-tc) TCS 3.5
From: Mike Andrews <mandrews@termfrost.org>
Date: 1999-06-11 12:00:31
I'm thinking of taking the plunge and going up to TCS 3.5. So far I've upgraded the management cards (because it fixes the annoying off-by-one DSP parameter problem in my Radius accounting logs), and a handful of Quads, but nothing else. I'm worried about the DSP code because I saw a few people here mention that they had more problems with cheap v.90 modems (Rockwell HCF and such) with 2.0.19 than they did with 1.2.43. What about 2.0.81? What about the new Quad code? I'm more interested in v.90 stability and bug fixes than I am about the new NFAS and DOVBS features. Mike Andrews (MA12) -=-=- VP & Sysadmin, Digital Crescent, Frankfort KY mandrews@dcr.net -=- mandrews@termfrost.org -=- http://www.termfrost.org "If Yoda so strong in Force is, why words in right order he cannot put?"
Subject: Re: (usr-tc) TCS 3.5
From: pferraro@wna-linknet.com
Date: 1999-06-11 12:03:43
I'd like to know how to get the new code.... Seems we've been LOCKED OUT!!! THe only unlocked file is the 4.1.59-6 HiperArc code? ============================================================================== Phillip Ferraro WorldNet Access, Inc pferraro@wna-linknet.com Onslow County's PREMIER InterNet Service Voice (910) 346-0835 824 Gumbranch Square, Suite R3 FAX (910) 455-1933 Jacksonville, Nc 28540-6269 ============================================================================== On Fri, 11 Jun 1999, Mike Andrews wrote: > I'm thinking of taking the plunge and going up to TCS 3.5. > > So far I've upgraded the management cards (because it fixes the annoying > off-by-one DSP parameter problem in my Radius accounting logs), and a > handful of Quads, but nothing else. > > I'm worried about the DSP code because I saw a few people here mention > that they had more problems with cheap v.90 modems (Rockwell HCF and such) > with 2.0.19 than they did with 1.2.43. What about 2.0.81? What about the > new Quad code? > > I'm more interested in v.90 stability and bug fixes than I am about the > new NFAS and DOVBS features. > > > Mike Andrews (MA12) -=-=- VP & Sysadmin, Digital Crescent, Frankfort KY > mandrews@dcr.net -=- mandrews@termfrost.org -=- http://www.termfrost.org > "If Yoda so strong in Force is, why words in right order he cannot put?" > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >
Subject: Re: (usr-tc) TCS 3.5
From: Brian <signal@shreve.net>
Date: 1999-06-11 12:25:05
On Fri, 11 Jun 1999 pferraro@wna-linknet.com wrote: > > I'd like to know how to get the new code.... Seems we've been > LOCKED OUT!!! THe only unlocked file is the 4.1.59-6 HiperArc code? Do you have a current valid support contract for software updates? > > ============================================================================== > Phillip Ferraro WorldNet Access, Inc > pferraro@wna-linknet.com Onslow County's PREMIER InterNet Service > Voice (910) 346-0835 824 Gumbranch Square, Suite R3 > FAX (910) 455-1933 Jacksonville, Nc 28540-6269 > ============================================================================== > > On Fri, 11 Jun 1999, Mike Andrews wrote: > > > I'm thinking of taking the plunge and going up to TCS 3.5. > > > > So far I've upgraded the management cards (because it fixes the annoying > > off-by-one DSP parameter problem in my Radius accounting logs), and a > > handful of Quads, but nothing else. > > > > I'm worried about the DSP code because I saw a few people here mention > > that they had more problems with cheap v.90 modems (Rockwell HCF and such) > > with 2.0.19 than they did with 1.2.43. What about 2.0.81? What about the > > new Quad code? > > > > I'm more interested in v.90 stability and bug fixes than I am about the > > new NFAS and DOVBS features. > > > > > > Mike Andrews (MA12) -=-=- VP & Sysadmin, Digital Crescent, Frankfort KY > > mandrews@dcr.net -=- mandrews@termfrost.org -=- http://www.termfrost.org > > "If Yoda so strong in Force is, why words in right order he cannot put?" > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)
Subject: RE: (usr-tc) Radius Config Question
From: Paul M. Oster <devious@minot.com>
Date: 1999-06-11 13:09:26
> DEFAULT Authentication-Type = Unix-PW > Service-Type = Framed, > Simultaneous-Use = 1, > Port-Limit = 1, > Session-Timeout = 14400, > Idle-Timeout = 900, > Filter-Id = filter, <-- (we filter the www) > Framed-Protocol = PPP, > Framed-IP-Netmask = 255.255.255.0, > Framed-Routing = None, > Framed-MTU = 1500, > Framed-Compression = Van-Jacobson-TCP-IP This is very similar to my default entry... (functionally equivalent, with the exception of the Filter-ID) and that works great, however if you try something like USERNAME Authentication-Type = Unix-PW , my radius croaks with an error... if I do USERNAME Password = "blah", then the radius server is happy. And assigning static IP's in the chassis is a management nightmare, almost impossible to keep everything in sync. Paul
Subject: (usr-tc) NOTICE - HiPerDSP T1/PRI Service Release 1.2.37 (posting complete)
From: William Brien <william_brien@mw.3com.com>
Date: 1999-06-11 13:54:23
(notice forwarded from 3Com TotalControl mailing list at totalcontrol@totalservice.nsd.usr.com - subscription information listed below) 3Com Customers, 3Com would like to announce the release of HiPerDSP T1/PRI Service Release 1.2.37 on the TotalService website at: http://totalservice.3com.com/ This release was built from HiPerDSP Release 1.2.43 (TCS 3.3) and fixes the MRs listed below: MR 1869 Disabling PPP off-loading with a HiPer ARC causes synchronous ISDN calls to fail. MR 2088 The HiPer DSP sends two result code responses when only one AT command was issued. MR 2114 Under certain conditions a software reset of a mdoem did not always reset the modem. MR 2151 Rockwell clients fail to establish error control in some environments. This code does not require a service contract to download, and will be free for download until the end of July, 1999. If there are any questions or concerns regarding this Service Release, please contact 3Com Technical Support toll-free at 1-800-231-8770. If you are calling from an area not handled by this number, the TotalService website has contact information for other countries and regions. Please go to the TotalService website and click on 'Contacting Tech Support' for more information. Thank you, Will Brien CSO Customer Service Product Planning William_Brien@3com.com (3Com User Forum information available at http://totalservice.3com.com/cgi-bin/w3com/start?totalservice+forumlink)
Subject: Re: (usr-tc) 14 DSP with two HiperARC: Experience with Fallback
From: Ricky Beam <jfbeam@bluetopia.net>
Date: 1999-06-11 14:03:31
On Tue, 8 Jun 1999, Ralph Helfenberger wrote: >- Has anybody tested this feature? Yes, with varying degrees of success. At last report, it was not a "stable" thing by any standard and everyone was urged to not use it. >- What is the criteria for a HiPer ARC to be "failed". Who makes the >decision about switching the > HiPer DSP from the failed HiPer ARC to the functional HiPer ARC? The NMC desided what's working and what isn't. The ARC's control of DSP cards is via chassis awareness. It's not the kind of fail-over you might be expecting -- i.e. it's not a hot spare. If one ARC dies, everything connected to it goes with it. The other ARC will then take over the DSP's previous owned by the failed ARC and begin answering calls for it. When it works, it works great. The last time I played with any of this (now six months ago) it was very easy to confuse the NMC to the point nobody was controlling anything -- but I was using alpha code and a 486 based NMC; using a hiperNMC might help. I never said anything to 3Com about it because it wasn't supposed to work... (and I had more important things to make them fix ;-)) --Ricky
Subject: Re: (usr-tc) X2 key for NMC?
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1999-06-11 14:08:11
Thus spake Ricky Beam >On Thu, 10 Jun 1999, Bob Purdon (Lists) wrote: >>Can anyone tell me what I need to sacrafice in order to obtain an X2 key >>for an NMC? >> >>3COM tell me they can't generate them. The generation page has >>disappeared from their web site... Paying sh*tloads for a support >>contract doesn't help either (we already have the support). >If you paid for an X2 upgrade, then they are required by law to give you an >enable code (or your money back) -- Talk to LaChina McDonald (X2 Administrator) >@ 847-342-6340 >PS: That number is two years old; YMMV. Heh...and thus my comment here, that LaChina, to my knowledge, is no longer with 3Com. There is someone else that is taking care of the x2 enable keys now...unfortunately, I don't have name and number at hand. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456
Subject: Re: (usr-tc) X2 key for NMC?
From: mmm3@cornell.edu
Date: 1999-06-11 14:15:19
On Fri, 11 Jun 1999, Jeff Mcadams wrote: > Thus spake Ricky Beam > >On Thu, 10 Jun 1999, Bob Purdon (Lists) wrote: > >>Can anyone tell me what I need to sacrafice in order to obtain an X2 key > >>for an NMC? > >> > >>3COM tell me they can't generate them. The generation page has > >>disappeared from their web site... Paying sh*tloads for a support > >>contract doesn't help either (we already have the support). > > >If you paid for an X2 upgrade, then they are required by law to give you an > >enable code (or your money back) -- Talk to LaChina McDonald (X2 Administrator) > >@ 847-342-6340 > > >PS: That number is two years old; YMMV. > > Heh...and thus my comment here, that LaChina, to my knowledge, is no > longer with 3Com. There is someone else that is taking care of the x2 > enable keys now...unfortunately, I don't have name and number at hand. Terra Fox, 847-222-2860, is in charge of the x2 keys Web site. hth.
Subject: Re: (usr-tc) NOTICE - HiPerDSP T1/PRI Service Release 1.2.37 (posting complete)
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1999-06-11 15:21:59
Thus spake William Brien >3Com would like to announce the release of HiPerDSP T1/PRI Service >Release 1.2.37 on the TotalService website at: This, in my opinion, is majorly good news from 3Com...not that there's a new service release that fixes issues (although that is good too), but that this shows that 3Com is actually a bit ahead of something I was about to start suggesting to them. :) It has been my experience (until just at this moment with this announcement) that once 3Com moves to the next release of software, they all but abandon the previous release. Its extremely encouraging to see 3Com continuing to work on and issue releases for the 1.2.x tree when they've already been working on and are issuing releases to the 2.0.x tree. This shows (IMO) that 3Com isn't trying to push people onto brand new, unproven code as much as I had feared. :) Consider this a (all too rare from me probably) kudo for doing the right thing for your customers. :) -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456
Subject: (usr-tc) Windows 3.1/MacTCP Nightmare
From: Scott Bailey <scott@epix.net>
Date: 1999-06-11 19:08:09
2 Weeks ago our Tech. Support queue suddenly, overnight, became saturated with Windows 3.1 and Mac (MacTCP) customers having trouble. The MacTCP customers were getting "Broken Pipe" errors. The windows 3.1 customers could only load a half a page in their browser. After trying a few sites on either system, the computer would lock up completely, and would have to be rebooted. None of the settings on the client side (believe me we tried everything) made any difference. Oddly they could get E-mail from our POP Server, and could also access any Web Servers within our domain, but nothing outside. All our Network and Systems Personnel insist that NOTHING has changed. After a week of Hell we found that upgrading the MAC's to Open Transport fixed their problem. Our windows 3.1 customers are using a Netscape Dial-Up Edition that we supply, It uses the Shiva Remote for a Dialer. We found that the Shiva Remote that comes with IE 4.0 works, but it will not run on all of our customers computers. Also the newer Communicator dialer (also a newer Shiva) works, but will not run on all older 3.1 machines. On the server side we have tried configuring radius with VJ compression on and off and by making the MTU smaller and larger. NOTHING!!! We have aprox. 15 POP's and use a combination of Hiper ARCs and DSP's at these exchanges. It does not matter which modems they are dialing in to. Aprox. 6 weeks ago we replaced all our 3COM routers with Cisco routers, however, this took place at least 2 weeks before any of this happened. Our backbone is supplied by Sprintlink and UUnet, they insist NOTHING has changed. If I dial in to a modem (standard External modem) connected to a linux box on our network, everything works. Telling the customer to upgrade to Windows 95/98, or trying to get them to download alternate programs has just resulted in lost customers. Has anyone seen anything similar to this? Does it seem like a 3COM issue? Any Ideas? What changed? Thanks for any input. Scott Bailey Epix Internet Services
Subject: (usr-tc) 14 DSP with two HiperARC: Experience with Fallback
From: Ralph Helfenberger <r.helfenberger@comlight.ch>
Date: 1999-06-11 20:00:58
Hi One of the feautures of the HiPer technology is the possibility to have redundancy. As far as I understood it is possible to have two HiPer ARC in a chassis. If one HiPer ARC fails the other takes over the whole traffic. For me there are some question marks with this functionality: - Has anybody tested this feature? - What is the criteria for a HiPer ARC to be "failed". Who makes the decision about switching the HiPer DSP from the failed HiPer ARC to the functional HiPer ARC? Hope to hear your experiences. Ralph -- ========================================================================== R. Helfenberger Internet r.helfenberger@comlight.ch Comlight AG Tel +41 31 740 40 40 Tennisweg 21 Fax +41 31 740 40 90 3178 Boesingen Switzerland www.comlight.ch ==========================================================================
Subject: (usr-tc) Format of Bulk Access on DualPRI Card
From: Ralph Helfenberger <r.helfenberger@comlight.ch>
Date: 1999-06-11 20:01:38
Hi all I should understand the Bulk format of the DS0 access on the DualPRI card for the TotalControl. From the documentation it is not clear to me, what the meaning of all bytes is. Has anybody more information about this? This is how it looks like: 1a01ffff0201ffff0201ffff0201ffff0201ffff0504060105040a030201ffff0201 and so on Best regards Ralph -- ========================================================================== R. Helfenberger Internet r.helfenberger@comlight.ch Comlight AG Tel +41 31 740 40 40 Tennisweg 21 Fax +41 31 740 40 90 3178 Boesingen Switzerland www.comlight.ch ==========================================================================
Subject: Re: (usr-tc) TCS 3.5
From: Fred Williams <fredwilliams@gtnet.gov.uk>
Date: 1999-06-11 23:04:14
Me too! Is this yet another 3Com improvement? Date sent: Fri, 11 Jun 1999 12:03:43 -0400 (EDT) Send reply to: usr-tc@lists.xmission.com > > I'd like to know how to get the new code.... Seems we've been > LOCKED OUT!!! THe only unlocked file is the 4.1.59-6 HiperArc code? > > ============================================================================== > Phillip Ferraro WorldNet Access, Inc > pferraro@wna-linknet.com Onslow County's PREMIER InterNet Service > Voice (910) 346-0835 824 Gumbranch Square, Suite R3 > FAX (910) 455-1933 Jacksonville, Nc 28540-6269 > ============================================================================== > > On Fri, 11 Jun 1999, Mike Andrews wrote: <><><><><><><><><><><><><><><><><><> Fred Williams, Hingham, Norfolk, UK fredwilliams@gtnet.gov.uk +44 (1953) 850541 Volvo Fruitcase <><><><><><><><><><><><><><><><><><>
Subject: (usr-tc) Inserting NMC resetts HiPer DSP cards
From: Andrew Aken <ajaken@globaleyes.net>
Date: 1999-06-14 02:58:17
We're currently running with the following code: 1 NMC: 6.1.17 1 HiPer ARC: 4.1.59 7 HiPer DSP: 2.0.19 All DSP's are connected to T1's. The NMC was no longer responding to SNMP requests or pings. When I removed the card and re-inserted it, it started responding again. However, each DSP card would drop all of its connections in order. Removing the NMC stopped the cycle. However, re-inserting it again started the cycle over again. We have another chassis with the same software configuration with a single DSP which does not have this problem. BTW, we just registered this chassis via the totalservice website 1 month ago and within a few days, we had access to the appropriate software upgrades. Now we're locked out of the latest upgrades for the DSP's. -- ======================================================= =========== Andrew Aken - President ========= ====== GlobalEyes Communications, Inc. ====== =Southern Illinois' Fastest Connection to the Internet= ========== http://www.GlobalEyes.net ======== =======================================================
Subject: Re: (usr-tc) 14 DSP with two HiperARC: Experience with Fallback
From: Shawn Harris <chaos@zebra.net>
Date: 1999-06-14 08:20:15
On Tue, 08 Jun 1999, you wrote: we have 8 chassis with 14 dsp's per chassis we have tried this but to no avail it seems there is fail over in that when traffic on one arc gets to much the traffic load is shared but one arc cannot handle 14 dsps that is what the people at 3com told us > Hi > One of the feautures of the HiPer technology is the possibility to have > redundancy. As far as I understood > it is possible to have two HiPer ARC in a chassis. If one HiPer ARC > fails the other takes over the whole > traffic. For me there are some question marks with this functionality: > - Has anybody tested this feature? > - What is the criteria for a HiPer ARC to be "failed". Who makes the > decision about switching the > HiPer DSP from the failed HiPer ARC to the functional HiPer ARC? > > > Hope to hear your experiences. > > Ralph > > > > -- > ========================================================================== > > R. Helfenberger Internet r.helfenberger@comlight.ch > Comlight AG Tel +41 31 740 40 40 > Tennisweg 21 Fax +41 31 740 40 90 > 3178 Boesingen > Switzerland www.comlight.ch > ========================================================================== > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message.
Subject: (usr-tc) Help - Setting IP routes with Radius
From: John Verreault <verreaul@aei.ca>
Date: 1999-06-14 09:36:23
I have the following statement in my radius user file. The HiperArc will not build a route for 210.221.46.32/28 unless I manually create a route on the HiperARC. WHY??? What am I doing wrong. I am using livingston radius v2.1b6 Thanks John USERXYZ Password="xxxx" User-Service-Type = Framed-User, Framed-Protocol = PPP, Framed-Address = 210.221.44.17, Framed-Netmask = 255.255.255.0, Framed-Routing = Broadcast-Listen, Framed-Route="210.221.46.32/28 210.221.44.17 1" Framed-MTU = 1500, Port-Limit = 1
Subject: RE: (usr-tc) 14 DSP with two HiperARC: Experience with Fallback
From: Renato A. Auricchio <rauricchio@m13.com.br>
Date: 1999-06-14 11:51:58
------ =_NextPart_000_01BEB65C.4F3D0C80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have some customer that are using only one Hiper Arc with 14 dsp's = and they are working fine, but I needed updated the firmwares as below: Hiper Arc - 4.1.59-6 DSP's - 2.0.19. Here in Brasil we use E1 instead of T1. It's = the reason the firmware version is diferent. I don't know the latest =20 version for T1 DSP's. =20 NMC-4 MB - 6.0.19 NMC-16MB - 6.1.17 Hiper NMC - 6.2.17 Renato A. Auricchio -----Original Message----- Sent: Segunda-feira, 14 de Junho de 1999 10:20 On Tue, 08 Jun 1999, you wrote: we have 8 chassis with 14 dsp's per chassis we have tried this but to no = avail it seems there is fail over in that when traffic on one arc gets to much = the traffic load is shared but one arc cannot handle 14 dsps that is what = the people at 3com told us > Hi > One of the feautures of the HiPer technology is the possibility to have > redundancy. As far as I understood > it is = possible to have two HiPer ARC in a chassis. If one HiPer ARC > fails the other = takes over the whole > traffic. For me there are some question marks with this functionality: > - Has anybody tested this feature? > - What is the criteria for a HiPer ARC to be "failed". Who makes the > decision about switching the > HiPer DSP from the failed HiPer ARC to the functional HiPer ARC? >=20 >=20 > Hope to hear your experiences. >=20 > Ralph >=20 >=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=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=3D=3D=3D=3D >=20 > R. Helfenberger Internet r.helfenberger@comlight.ch > Comlight AG Tel +41 31 740 40 40 > Tennisweg 21 Fax +41 31 740 40 90 > 3178 Boesingen > Switzerland www.comlight.ch > = =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=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=3D=3D=3D=3D >=20 > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message. ------ =_NextPart_000_01BEB65C.4F3D0C80 Content-Type: application/ms-tnef Content-Transfer-Encoding: base64 eJ8+IjsOAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEEkAYA0AEAAAEAAAAQAAAAAwAAMAIAAAAL AA8OAAAAAAIB/w8BAAAAUQAAAAAAAACBKx+kvqMQGZ1uAN0BD1QCAAAAAHVzci10Y0BsaXN0cy54 bWlzc2lvbi5jb20AU01UUAB1c3ItdGNAbGlzdHMueG1pc3Npb24uY29tAAAAAB4AAjABAAAABQAA AFNNVFAAAAAAHgADMAEAAAAaAAAAdXNyLXRjQGxpc3RzLnhtaXNzaW9uLmNvbQAAAAMAFQwBAAAA AwD+DwYAAAAeAAEwAQAAABwAAAAndXNyLXRjQGxpc3RzLnhtaXNzaW9uLmNvbScAAgELMAEAAAAf AAAAU01UUDpVU1ItVENATElTVFMuWE1JU1NJT04uQ09NAAADAAA5AAAAAAsAQDoBAAAAHgD2XwEA AAAaAAAAdXNyLXRjQGxpc3RzLnhtaXNzaW9uLmNvbQAAAAIB918BAAAAUQAAAAAAAACBKx+kvqMQ GZ1uAN0BD1QCAAAAAHVzci10Y0BsaXN0cy54bWlzc2lvbi5jb20AU01UUAB1c3ItdGNAbGlzdHMu eG1pc3Npb24uY29tAAAAAAMA/V8BAAAAAwD/XwAAAAACAfYPAQAAAAQAAAAAAAAC+WgBBIABAEAA AABSRTogKHVzci10YykgMTQgRFNQIHdpdGggdHdvIEhpcGVyQVJDOiBFeHBlcmllbmNlIHdpdGgg RmFsbGJhY2sA3hQBBYADAA4AAADPBwYADgALADMAOgABAGMBASCAAwAOAAAAzwcGAA4ACwAdACQA AQA3AQEJgAEAIQAAAEY1NzQ4MkU1NEIyMkQzMTE5ODlDMDA2MDk3Njc2QUVDAAwHAQOQBgDYCQAA IQAAAAsAAgABAAAACwAjAAAAAAADACYAAAAAAAsAKQAAAAAAAwAuAAAAAAADADYAAAAAAEAAOQBA SJ9zdba+AR4AcAABAAAAQAAAAFJFOiAodXNyLXRjKSAxNCBEU1Agd2l0aCB0d28gSGlwZXJBUkM6 IEV4cGVyaWVuY2Ugd2l0aCBGYWxsYmFjawACAXEAAQAAABYAAAABvrZ1c47lgnT3IksR05icAGCX Z2rsAAAeAB4MAQAAAAUAAABTTVRQAAAAAB4AHwwBAAAAFgAAAHJhdXJpY2NoaW9AbTEzLmNvbS5i cgAAAAMABhBnOMaWAwAHEBEHAAAeAAgQAQAAAGUAAABJSEFWRVNPTUVDVVNUT01FUlRIQVRBUkVV U0lOR09OTFlPTkVISVBFUkFSQ1dJVEgxNERTUFNBTkRUSEVZQVJFV09SS0lOR0ZJTkUsQlVUSU5F RURFRFVQREFURURUSEVGSVJNAAAAAAIBCRABAAAAkQYAAI0GAAAiDAAATFpGdc+U8QUDAAoAcmNw ZzEyNRYyAPgLYG4OEDA0Np0B9yACpAPjAgBjaArA4HNldDAgBxMCgwBQoRB2cHJxMhF2fQqA2QjI IDsJbw4wNQKACoFsdWMAUAsDYwBBDwQzIjMLpiBJIBEAdmUMIHMDcBgwY3VzdPsYYQXAdBEABUAK wBgwGLDJC4BnIAIgbHkaERgwzkgFIBkBBxBjIAPwGTAAIDE0ICBkc3DWJwQgAHBkGSFlGlAZgip3 BbBrGeJmC4BlLPggYnUFQBfgGoAJgAmAeRmwcGQZUB6RHIEdgXKcbXcZgRwhBCBiZQkAfHc6CqIK hAqAGrgiBS0AIDQuMS41OS3iNiC0RFNQHBEj2SKAyDIuMCKwOS4aoASQYxgwC4AgQnIgIAMRdzMZ ohgwRTElcRjAZWFhHGBvZiBUIsAX0HS/HBEfQglwICACIB87IBgg/REgaSiBBAAb0AaQJUECMJcn kRvQAiAnBUBrbiCA/x8zC2AfABjAG8AgtCPaLW3vKYYCEAXAJ3AgI4MlECICISC0Tk1DLRuxTUKZ IkQgNiTDMBgxNjDp+SLAMTchGjBxIjUxYSSw2zNmILpSCfAZUG8RcCUQ+kEIcWMQ8CnANV81qQsw 8GxpMzYBQBaQAUASwPJvHwBjdBIEMnAicDsiek8FEGcLgAdABdAHkHP4YWdlOyMgtjo0OgELE2U6 NmkyYDQ0AUA5gDEcODABQAzQPsNiIEZXA2EgoAySYhFgUxEAd/0DoEgKwAUQBCEgxD/wBmAjAjBA WGVndRxQYS07KlAfkGEd0BuhAQAgSn1DQGg2wEQxJPBFABuQMGY6DAFBxlRvQFcYsHJwLXRjQDmA GMAvoHhWbQQBKcEuBaBtQbh1HGJqOmFAVzZwOiAo3UbUKRuSI4EbRHQdEBqkyEFSQ0oQRXga0QiQ LG5jHPEbYkYHQGxi/QDQazzPPdo5hA8GC6cgw5pPA6BUClAd0DA4RFL7ROMd0HkIYBtAOjIgpSYh /xgDUgAQ8UfRBCAbVhvkGtL7VGdT1XQIgRxiKgEd8jax+ytgGXB2C3AJUCDDG2AYQN0J4G0n4yVS BCBmWHEaEPcpgSVyGTN3HJAokSXAASD/DeAaERpjCsAbMDxQR3BX4v5tFgBLYRyQILRblgkAJxG9 KgFzEQEekR3yXEZjAHDvK2AFQBEAHFBsRNFVQyfi3xlRVLIZQl2XGtBvC1BcYe0FQDNIMVfhbB6h EMAsdP4+GqFk0VFwGDAnQR9DJwDfHgAIcAeRZZUasFAZAgWQ9mgrYAkAZxpQBABdxR9R9HBvR9Fi AxAbYBpQNrHfGANk4AlxQ0JM0Hk28VoC/wXAICEX4ENBKZEY0ARwZNH/WQEqAWjkYQEY0CC0VrRL k/dnMkwRJXJhVFYnkSdQGnR/brZk4FoiJ+Q6QFmhGSBh/mtmcimBaEhbQAbwagJblX0lEEYFsRhx WZQZghhTcf8KUBjAKcIAwB0wVMVXYiC0/mZDQDpwKcEHQGlhShBk4NcigEFAHCJ5BuBkaYEsEbdX NmYBZkI/ILR4wldhxf8fQgUBHwAHIS7jb2BumDax2SBQICJaIgmAIiUQe6D/XSFyU12XZOAFgQQA KcIBoP8IYFkRG1E3YRnxf5kiAWcU/0ryA1IfNH5zfUwfQ3fnboj7eveGvkhjMG1iF/AnAAXAu1LB BcBlTHcvoIa+UgdAvHBohr+L/TymZOA9jg+/jx+QL5E/kZOKHyUSbCpQum4gUHI8UAXALW1JAjBn BJERQBvAci4ckJP4QPNIMTmAZ2gqoBDwewYIUNuXRBFwRy1vIgFUIGAbwNQrNCagMyagNz7gIpB/ myJ7BppAYHAEACYgGgAy1yagnN9NUXiafjmbh5rQ8jdSAEJvB5AZ4Qnwewb6UxtRegSQDwEcYKHv G8D+d6MgSCKXXpGfpZ+mr6e/35JPezSCB0Yga7FzSQAE8v9+ITaxRtQd0BEwHFEDkVlQ61oyNrEi AMBqBbAq8ARg2kBHqiKCBxtTIqsKRtT+Ilq0GDB5c2WVB4E8MooH/3SDC4Au8QDAdjMogSowPFDf R2EaEAXACXBXAnYdVGEAvxwkZBKyZV8BrIGCByKWUb5wsRCE9TwwGHEnEGQf4f0vokRYAgVAJlJ1 8DpBBCD/JYGJA7JsILQ8tarPq9+s7/+t/yxlr5+wr7G/ssazb7R//7WPtp+3pbg/uU+6X7tvCoAF E4EAzxAAAAADABAQAAAAAAMAERABAAAAAwCAEP////9AAAcwwKTMU3K2vgFAAAgwwKTMU3K2vgEL AAGACCAGAAAAAADAAAAAAAAARgAAAAADhQAAAAAAAAMAA4AIIAYAAAAAAMAAAAAAAABGAAAAABCF AAAAAAAAAwAGgAggBgAAAAAAwAAAAAAAAEYAAAAAUoUAALcNAAAeACaACCAGAAAAAADAAAAAAAAA RgAAAABUhQAAAQAAAAQAAAA4LjAAAwAngAggBgAAAAAAwAAAAAAAAEYAAAAAAYUAAAAAAAALADCA CCAGAAAAAADAAAAAAAAARgAAAAAOhQAAAAAAAAMAMYAIIAYAAAAAAMAAAAAAAABGAAAAABGFAAAA AAAAAwAzgAggBgAAAAAAwAAAAAAAAEYAAAAAGIUAAAAAAAAeAEKACCAGAAAAAADAAAAAAAAARgAA AAA2hQAAAQAAAAEAAAAAAAAAHgBDgAggBgAAAAAAwAAAAAAAAEYAAAAAN4UAAAEAAAABAAAAAAAA AB4ARIAIIAYAAAAAAMAAAAAAAABGAAAAADiFAAABAAAAAQAAAAAAAAAeAD0AAQAAAAUAAABSRTog AAAAAAMADTT9NwAAmcI= ------ =_NextPart_000_01BEB65C.4F3D0C80--
Subject: (usr-tc) FS: NEWBRIDGE 3600 Chassis
From: Andrew:PC Global, Inc. <andrew@pcglobal.net>
Date: 1999-06-14 12:25:08
FOR SALE: Have in stock (10) Newbridge 3600 chassis for sale they include T-1 card,dual 1.5444mbs T-1 card, control card, Dnic They are complete are guaranteed working. With Warmest Regards, Andrew Shlensky **************************** PC Global, Inc. (305) 667-2111 tel (305) 667-3636 fax (305) 216-8638 mobile URL: http://www.pcglobal.net E-MAIL: andrew@pcglobal.net ICQ: 21219089 Computer Service Parts SpEciaLiSts! ALSO:SALES of New/Used PCs,Laptops Communication & Networking,Monitors Printers, Hard Drives, Midrange/Mainframe. Hard to Get Parts. We buy and sell all types of GEAR- ****************************
Subject: Re: (usr-tc) NOTICE - HiPerDSP T1/PRI Service Release 1.2.37 (posting complete)
From: Pete Ashdown <pashdown@xmission.com>
Date: 1999-06-14 12:45:16
Jeff Mcadams said once upon a time: >Its extremely encouraging to see 3Com continuing to work on and issue >releases for the 1.2.x tree when they've already been working on and are >issuing releases to the 2.0.x tree. This shows (IMO) that 3Com isn't >trying to push people onto brand new, unproven code as much as I had >feared. :) The only question I have now is what would be better to use? 2.0.81, or 1.2.37?
Subject: (usr-tc) TC Rack IP Assignments
From: Jolliffe, Anu <ajolliffe@imagen.net>
Date: 1999-06-14 13:46:57
I have a TC Dual Pri rack with 12 A/D Quads installed. I have the netserver configured to hand out ip's starting with x.x.x.91. My problem is, even though there are only 46 ports, the rack is still using 60 ip's starting with the before mentioned address. My question is, how can I keep the chassis from using more than 46 ip's? Thank you.
Subject: RE: (usr-tc) TC Rack IP Assignments
From: Jolliffe, Anu <ajolliffe@imagen.net>
Date: 1999-06-14 14:01:44
Is that the same as the Max B Channels field in NetServer Manager? If so, it's already set to 46. -----Original Message----- Sent: Monday, June 14, 1999 1:42 PM you just need to do "set limit 46", "save all", "reboot". Matthew... On Monday, June 14, 1999 5:47 PM, Jolliffe, Anu [SMTP:ajolliffe@imagen.net] wrote: > I have a TC Dual Pri rack with 12 A/D Quads installed. I have the netserver > configured to hand out ip's starting with x.x.x.91. My problem is, even > though there are only 46 ports, the rack is still using 60 ip's starting > with the before mentioned address. > > My question is, how can I keep the chassis from using more than 46 ip's? > > Thank you. > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.
Subject: RE: (usr-tc) TC Rack IP Assignments
From: Jolliffe, Anu <ajolliffe@imagen.net>
Date: 1999-06-14 14:04:14
thanx -----Original Message----- Sent: Monday, June 14, 1999 1:53 PM nope.. On Monday, June 14, 1999 6:02 PM, Jolliffe, Anu [SMTP:ajolliffe@imagen.net] wrote: > Is that the same as the Max B Channels field in NetServer Manager? If so, > it's already set to 46. > > -----Original Message----- > From: matthews [mailto:matthews@staff.brunnet.net] > Sent: Monday, June 14, 1999 1:42 PM > To: 'usr-tc@lists.xmission.com' > Subject: RE: (usr-tc) TC Rack IP Assignments > > > > you just need to do "set limit 46", "save all", "reboot". > > Matthew... > > On Monday, June 14, 1999 5:47 PM, Jolliffe, Anu [SMTP:ajolliffe@imagen.net] > wrote: > > I have a TC Dual Pri rack with 12 A/D Quads installed. I have the > netserver > > configured to hand out ip's starting with x.x.x.91. My problem is, even > > though there are only 46 ports, the rack is still using 60 ip's starting > > with the before mentioned address. > > > > My question is, how can I keep the chassis from using more than 46 ip's? > > > > Thank you. > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.
Subject: Re: (usr-tc) NOTICE - HiPerDSP T1/PRI Service Release 1.2.37 (posting complete)
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1999-06-14 14:10:53
> Jeff Mcadams said once upon a time: > > >Its extremely encouraging to see 3Com continuing to work on and issue > >releases for the 1.2.x tree when they've already been working on and are > >issuing releases to the 2.0.x tree. This shows (IMO) that 3Com isn't > >trying to push people onto brand new, unproven code as much as I had > >feared. :) > > The only question I have now is what would be better to use? 2.0.81, or > 1.2.37? 2.0.81 if you need NFAS support krish > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >
Subject: RE: (usr-tc) TC Rack IP Assignments
From: Jolliffe, Anu <ajolliffe@imagen.net>
Date: 1999-06-14 14:22:30
Okay. -----Original Message----- Sent: Monday, June 14, 1999 2:10 PM No.. Max B is not related to the IP pools.. I would sugest that you dont use the NetServer manager. Its not matched with the latest code for the card.. -M |-----Original Message----- |From: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Jolliffe, Anu |Sent: Monday, June 14, 1999 4:02 PM |To: 'usr-tc@lists.xmission.com' |Subject: RE: (usr-tc) TC Rack IP Assignments | | |Is that the same as the Max B Channels field in NetServer Manager? If so, |it's already set to 46. | |-----Original Message----- |From: matthews [mailto:matthews@staff.brunnet.net] |Sent: Monday, June 14, 1999 1:42 PM |To: 'usr-tc@lists.xmission.com' |Subject: RE: (usr-tc) TC Rack IP Assignments | | | |you just need to do "set limit 46", "save all", "reboot". | |Matthew... | |On Monday, June 14, 1999 5:47 PM, Jolliffe, Anu [SMTP:ajolliffe@imagen.net] |wrote: |> I have a TC Dual Pri rack with 12 A/D Quads installed. I have the |netserver |> configured to hand out ip's starting with x.x.x.91. My problem is, even |> though there are only 46 ports, the rack is still using 60 ip's starting |> with the before mentioned address. |> |> My question is, how can I keep the chassis from using more than 46 ip's? |> |> Thank you. |> |> - |> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" |> with "unsubscribe usr-tc" in the body of the message. |> For information on digests or retrieving files and old messages send |> "help" to the same address. Do not use quotes in your message. | | | | |- | To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" | with "unsubscribe usr-tc" in the body of the message. | For information on digests or retrieving files and old messages send | "help" to the same address. Do not use quotes in your message. | |- | To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" | with "unsubscribe usr-tc" in the body of the message. | For information on digests or retrieving files and old messages send | "help" to the same address. Do not use quotes in your message. | - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.
Subject: Re: (usr-tc) NOTICE - HiPerDSP T1/PRI Service Release 1.2.37 (posting
From: Mike Andrews <mandrews@termfrost.org>
Date: 1999-06-14 14:56:51
On Mon, 14 Jun 1999, Pete Ashdown wrote: > Jeff Mcadams said once upon a time: > > >Its extremely encouraging to see 3Com continuing to work on and issue > >releases for the 1.2.x tree when they've already been working on and are > >issuing releases to the 2.0.x tree. This shows (IMO) that 3Com isn't > >trying to push people onto brand new, unproven code as much as I had > >feared. :) > > The only question I have now is what would be better to use? 2.0.81, or > 1.2.37? That's what I'm trying to figure out. :) Nobody has yet offered any feedback (maybe because most can't get 2.0.81)... so for now I'm running a mix of 2.0.81, 1.2.37, and 1.2.43 just to see what happens to our Rockwell victims. Mike Andrews (MA12) -=-=- VP & Sysadmin, Digital Crescent, Frankfort KY mandrews@dcr.net -=- mandrews@termfrost.org -=- http://www.termfrost.org "If Yoda so strong in Force is, why words in right order he cannot put?"
Subject: RE: (usr-tc) TC Rack IP Assignments
From: Chad J. LaFrenz <clafrenz@rof.net>
Date: 1999-06-14 15:02:14
Anu-- The command you are looking for is "set limit X" where X is the number of ports you have. I always set it to X+2 so that it gives me a little buffer for a busy rack. Need that? Don't know, but has always worked well for me. Regards, Chad J. LaFrenz Senior System Admin. RoFIntUG An educational, non-profit ISP proudly serving the Aspen, Glenwood Springs, Rifle and Vail Valleys. http://www.rof.net -----Original Message----- [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Jolliffe, Anu Sent: Monday, June 14, 1999 2:47 PM I have a TC Dual Pri rack with 12 A/D Quads installed. I have the netserver configured to hand out ip's starting with x.x.x.91. My problem is, even though there are only 46 ports, the rack is still using 60 ip's starting with the before mentioned address. My question is, how can I keep the chassis from using more than 46 ip's? Thank you. - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.
Subject: Re: (usr-tc) NOTICE - HiPerDSP T1/PRI Service Release 1.2.37 (posting complete)
From: Walt Gnann <wgnann@islc.net>
Date: 1999-06-14 15:41:20
So, 2.0.81 is the best choice for NFAS and 1.2.37 is the best choice if you don't need NFAS? Walt Walter N. Gnann ISLC, President 843.770.1000 843.770.1002 (fax) wgnann@islc.net http://www.islc.net http://www.beaufortonline.com http://www.beaufortcomputerclub.org -----Original Message----- Cc: usr-tc@lists.xmission.com <usr-tc@lists.xmission.com> (posting complete) -snip- >2.0.81 if you need NFAS support > >krish >
Subject: RE: (usr-tc) TC Rack IP Assignments
From: Mike Wronski <mike@coredump.ae.usr.com>
Date: 1999-06-14 15:56:36
|-----Original Message----- |From: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Jolliffe, Anu |Sent: Monday, June 14, 1999 3:47 PM |To: 'usr-tc@lists.xmission.com' |Subject: (usr-tc) TC Rack IP Assignments | | |I have a TC Dual Pri rack with 12 A/D Quads installed. I have the netserver |configured to hand out ip's starting with x.x.x.91. My problem is, even |though there are only 46 ports, the rack is still using 60 ip's starting |with the before mentioned address. | |My question is, how can I keep the chassis from using more than 46 ip's? | |Thank you. | "set limit 46" "save all" ..Wait 1 minute.. "reboot"
Subject: RE: (usr-tc) TC Rack IP Assignments
From: Mike Wronski <mike@coredump.ae.usr.com>
Date: 1999-06-14 16:10:24
No.. Max B is not related to the IP pools.. I would sugest that you dont use the NetServer manager. Its not matched with the latest code for the card.. -M |-----Original Message----- |From: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Jolliffe, Anu |Sent: Monday, June 14, 1999 4:02 PM |To: 'usr-tc@lists.xmission.com' |Subject: RE: (usr-tc) TC Rack IP Assignments | | |Is that the same as the Max B Channels field in NetServer Manager? If so, |it's already set to 46. | |-----Original Message----- |From: matthews [mailto:matthews@staff.brunnet.net] |Sent: Monday, June 14, 1999 1:42 PM |To: 'usr-tc@lists.xmission.com' |Subject: RE: (usr-tc) TC Rack IP Assignments | | | |you just need to do "set limit 46", "save all", "reboot". | |Matthew... | |On Monday, June 14, 1999 5:47 PM, Jolliffe, Anu [SMTP:ajolliffe@imagen.net] |wrote: |> I have a TC Dual Pri rack with 12 A/D Quads installed. I have the |netserver |> configured to hand out ip's starting with x.x.x.91. My problem is, even |> though there are only 46 ports, the rack is still using 60 ip's starting |> with the before mentioned address. |> |> My question is, how can I keep the chassis from using more than 46 ip's? |> |> Thank you. |> |> - |> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" |> with "unsubscribe usr-tc" in the body of the message. |> For information on digests or retrieving files and old messages send |> "help" to the same address. Do not use quotes in your message. | | | | |- | To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" | with "unsubscribe usr-tc" in the body of the message. | For information on digests or retrieving files and old messages send | "help" to the same address. Do not use quotes in your message. | |- | To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" | with "unsubscribe usr-tc" in the body of the message. | For information on digests or retrieving files and old messages send | "help" to the same address. Do not use quotes in your message. |
Subject: RE: (usr-tc) TC Rack IP Assignments
From: matthews <matthews@staff.brunnet.net>
Date: 1999-06-14 17:41:33
you just need to do "set limit 46", "save all", "reboot". Matthew... On Monday, June 14, 1999 5:47 PM, Jolliffe, Anu [SMTP:ajolliffe@imagen.net] wrote: > I have a TC Dual Pri rack with 12 A/D Quads installed. I have the netserver > configured to hand out ip's starting with x.x.x.91. My problem is, even > though there are only 46 ports, the rack is still using 60 ip's starting > with the before mentioned address. > > My question is, how can I keep the chassis from using more than 46 ip's? > > Thank you. > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message.
Subject: RE: (usr-tc) TC Rack IP Assignments
From: matthews <matthews@staff.brunnet.net>
Date: 1999-06-14 17:53:18
nope.. On Monday, June 14, 1999 6:02 PM, Jolliffe, Anu [SMTP:ajolliffe@imagen.net] wrote: > Is that the same as the Max B Channels field in NetServer Manager? If so, > it's already set to 46. > > -----Original Message----- > From: matthews [mailto:matthews@staff.brunnet.net] > Sent: Monday, June 14, 1999 1:42 PM > To: 'usr-tc@lists.xmission.com' > Subject: RE: (usr-tc) TC Rack IP Assignments > > > > you just need to do "set limit 46", "save all", "reboot". > > Matthew... > > On Monday, June 14, 1999 5:47 PM, Jolliffe, Anu [SMTP:ajolliffe@imagen.net] > wrote: > > I have a TC Dual Pri rack with 12 A/D Quads installed. I have the > netserver > > configured to hand out ip's starting with x.x.x.91. My problem is, even > > though there are only 46 ports, the rack is still using 60 ip's starting > > with the before mentioned address. > > > > My question is, how can I keep the chassis from using more than 46 ip's? > > > > Thank you. > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message.
Subject: (usr-tc) Dead HiperDSP
From: King Ho <ml@glink.net.hk>
Date: 1999-06-14 18:34:43
Hi, Today one of our HiperDSP just reboot and after reboot the status of all the modems on that card becomes "down up" when I do a "list int". I tried to pull it out and put it back in and still the same thing. I also tried to move it to another chassis and still no go. I even tried to flashing the card with 1.2.37 and still the same. When I plug a terminal to the console port the following message comes up about once every couple of minutes: (Ch.254): 09:58:02:064 Logic Error - Unknown error error = 00002603 Task = PCT Line # 2456 File pc_hdm.c Data = 577 Opt = 3 Does anyone know if this message indicates a hardware failure and needs to be RMA?! Or is there anything I can do to get it back to service. Thanks. Best regards, King Ho Global Link Information Services Ltd.
Subject: (usr-tc) SNMP Traps
From: Paul Farber <farber@admin.f-tech.net>
Date: 1999-06-15 06:19:12
hello all I am trying to set up the NMC to fire off traps for call failures.. I did the TCM thing and set up the trap destination IP and community string... but no traps are recorded. I am using Slackware 2.0.32 with UCD-SNMP 3.5. I can sent traps from another linuix machine... but the ARC refuses to play nice. ARC 4.1.59 NMC 6.0.17 DSP 2.0.19 Paul D. Farber II Farber Technology Ph. 570-628-5303 Fax 570-628-5545 farber@admin.f-tech.net
Subject: Re: (usr-tc) traps and using them
From: Steve Valiunas <steve_valiunas@mw.3com.com>
Date: 1999-06-15 09:43:45
Good guesses so far. You should grab the "HiperNMC Network Application Card SNMP and MIB Reference" (# 1.024.1661) and "HiperNMC Network Application Card Parameter Reference (#1.024.1000) from TotalService.3Com.com. They should answer your questions. STeve Paul Farber <farber@admin.f-tech.net> on 06/16/99 12:20:28 AM Please respond to usr-tc@lists.xmission.com Sent by: Paul Farber <farber@admin.f-tech.net> cc: (Steve Valiunas/MW/US/3Com) hello all I finally got the NMC to spit out some traps and, well, what next. For example.... uchasSlotIndex.1 = 1 would mean the card in slot 1? uchasEntityIndex.1 = 23 would mean the 23rd channel in the 1ist slot?? Also, what are the call failure codes and the terminate codes?? TCM Win just barfs that there is not help available for the topic if I right click in the perf mon. You get the idea... a few pointers or URL to deciphering the traps would be helpful! Paul D. Farber II Farber Technology Ph. 570-628-5303 Fax 570-628-5545 farber@admin.f-tech.net - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.
Subject: Re: (usr-tc) traps and using them
From: Ricky Beam <jfbeam@bluetopia.net>
Date: 1999-06-15 10:24:05
On Tue, 15 Jun 1999, Marcelo Souza wrote: >|I finally got the NMC to spit out some traps and, well, what next. > > Could you give me the steps? I'm trying to use the UCD_SNMP to >manage the traps but it doesn't work yet. I'm using BSDI not Linux, but I >already had compiled the package, the problem is make NMC send the traps >to snmptrapd and make it log them. :-) > In the TC manual they recommend to use the trap daemon on the same >machine of the accounting, is it mandatory? No, that's not necessary. I had 40 chassis's sending traps as well as RADIUS accounting data. SNMP went to a NOC workstation (where some idiot was supposed to be paying attention to it.) Radius when to the radius server(s). It's not that difficult to setup. (Time consuming, but not difficult.) --Ricky
Subject: Re: (usr-tc) traps and using them
From: Marcelo Souza <mpsouza@centroin.com.br>
Date: 1999-06-15 10:41:23
Hi Paul, On Wed, 16 Jun 1999, Paul Farber wrote: |I finally got the NMC to spit out some traps and, well, what next. Could you give me the steps? I'm trying to use the UCD_SNMP to manage the traps but it doesn't work yet. I'm using BSDI not Linux, but I already had compiled the package, the problem is make NMC send the traps to snmptrapd and make it log them. :-) In the TC manual they recommend to use the trap daemon on the same machine of the accounting, is it mandatory? TIA - Marcelo | |For example.... | |uchasSlotIndex.1 = 1 would mean the card in slot 1? |uchasEntityIndex.1 = 23 would mean the 23rd channel in the 1ist slot?? | |Also, what are the call failure codes and the terminate codes?? TCM Win |just barfs that there is not help available for the topic if I right click |in the perf mon. | |You get the idea... a few pointers or URL to deciphering the traps would |be helpful! | |Paul D. Farber II |Farber Technology |Ph. 570-628-5303 |Fax 570-628-5545 |farber@admin.f-tech.net | | |- | To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" | with "unsubscribe usr-tc" in the body of the message. | For information on digests or retrieving files and old messages send | "help" to the same address. Do not use quotes in your message.
Subject: (usr-tc) NEED TO BUY 3COM/USR NETSERVER
From: Andrew:PC Global, Inc. <andrew@pcglobal.net>
Date: 1999-06-15 11:49:07
Hello- Need to buy ASAP - USR/3COM Netserver PRI card set to include THESE numbers only: Card set 000976-0 includes: 69-0001003 69-0001393 67-000209 (cable) These numbers must appear on the white stickers on the cards. Can use these numbers ONLY. Cannot use incomplete sets. Will pay $1000 per set! Can use up to 4. Must guarantee working condition. Please contact me via private email if you have any to sell. Warmest Regards, Andrew Shlensky **************************** PC Global, Inc. (305) 667-2111 tel (305) 667-3636 fax (305) 216-8638 mobile URL: http://www.pcglobal.net E-MAIL: andrew@pcglobal.net ICQ: 21219089 Computer Service Parts SpEciaLiSts! ALSO:SALES of New/Used PCs,Laptops Communication & Networking,Monitors Printers, Hard Drives, Midrange/Mainframe. Hard to Get Parts. We buy and sell all types of GEAR- ****************************
Subject: (usr-tc) The owner of V.90
From: Marcelo Souza <mpsouza@centroin.com.br>
Date: 1999-06-15 14:11:59
---------- Forwarded message ---------- Continuing a years-old saga, 3Com on Monday announced that it has reached an agreement to turn over control of the patents to certain key technologies that are used in the industry's 56-kilobit-per-second modem standard to the inventor who developed them. Brent Townshend, an independent inventor who lives in Menlo Park, Calif., reacquired control from 3Com of the patents covering his inventions that are central to the pulse-code modulation (PCM) technology used in the International Telecommunication Union's V.90 specification for modems, according to the 3Com announcement. Virtually all 56K analog modems on the market today use the V.90 standard to connect. Under the agreement reached between Townshend and 3Com, Townshend has exclusive control over the licensing and enforcement of the patents, which means he can now negotiate with other manufacturers of V.90-compliant communications equipment that use the technology. 3Com has retained a nonexclusive license to use the patents. Previously, 3Com had an exclusive license on the patents in question, which the company bought from Townshend in 1997. 3Com said that it owns exclusive rights to other patented and patent-pending technologies that it believes are essential to the V.90 standard. This latest wrinkle most likely will not affect the prices of 56K modems: Townshend, as a condition of the deal with 3Com, has agreed to license the patents included in the V.90 specification "on a nondiscriminatory basis under reasonable terms and conditions," according to a 3Com statement. There have been several intellectual property disputes surrounding 56K modem technology. In October 1997, Townshend filed a lawsuit against Rockwell Semiconductor Systems -- since renamed Conexant Systems -- claiming infringement of his patents on PCM technology. In February 1998, the ITU completed the 56K modems' V.90 standard, which received official approval in September 1998. Prior to the ITU's standardization effort, there were two competing and incompatible technologies for 56K modems. First to market was U.S. Robotics' x2; 3Com merged with U.S. Robotics in June 1997. The other technology, called K56flex, was co-developed by Lucent Technologies and Rockwell Semiconductor.
Subject: (usr-tc) What to request instead of NI-2
From: Peter D. Mayer <dmayer@netwalk.com>
Date: 1999-06-15 16:11:26
Many of you (especially Jeff McAdams) are vocal bashers of NI-2. We're getting ready to switch providers for our PRI's and I was wondering what ISDN type to request instead of NI-2. (I believe NI-2 is what we currently have, although the switch type in the trunk settings is set to 5ESS.) What are your recommendations? Thanks, Peter D. Mayer NetWalk Systems Administrator dmayer@netwalk.com
Subject: Re: (usr-tc) What to request instead of NI-2
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1999-06-15 16:23:33
Thus spake Peter D. Mayer >Many of you (especially Jeff McAdams) are vocal bashers of NI-2. We're getting >ready to switch providers for our PRI's and I was wondering what ISDN type to >request instead of NI-2. (I believe NI-2 is what we currently have, although >the switch type in the trunk settings is set to 5ESS.) What are your >recommendations? Heh...I'm famous. :) (infamous probably :) We use custom 5ESS here. Really your choices are either NI-2, which is not really a switch type as such, as its a standard that all switches can support, or a custom type that is really controlled by what type of switch you're connected to. You'll likely either be dealing with a 5ESS switch, or a DMS100 or something like that. Those are the common ones in North America. Most of those switches do support the service messages that NI-2 lack, so if you go with custom, you'll *likely* be ok. Basically, if you're on NI-2, if you put your ds0's into localoutofservice (or soft-busy), the pri card (or dsp) has no way to inform the switch to not send any more calls on that ds0. Thus the switch will continue to send calls down that ds0 and the pri card or dsp can either generate a busy (breaking your hunt), take the call (in which case you card never frees up), or just drop the call on the floor (which causes all sorts of weird stuff for the end customer :) -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456
Subject: Re: (usr-tc) What to request instead of NI-2
From: Peter D. Mayer <dmayer@netwalk.com>
Date: 1999-06-15 17:58:54
----- Original Message ----- Sent: Tuesday, June 15, 1999 4:23 PM >We use custom 5ESS here. Really your choices are either NI-2, which is >not really a switch type as such, as its a standard that all switches >can support, or a custom type that is really controlled by what type of >switch you're connected to. You'll likely either be dealing with a 5ESS >switch, or a DMS100 or something like that. Those are the common ones >in North America. Most of those switches do support the service >messages that NI-2 lack, so if you go with custom, you'll *likely* be >ok. > Ok, I told the telco that we wanted 5ESS custom, and they came back saying that with 5ESS custom that we couldn't do NFAS, but with NI-2 we could. It's not imperative that we do NFAS (D channels don't cost extra here), but I wouldn't mind the extra B channels. Do you know of any limitations of 5ESS custom that would disallow NFAS? Thanks, Peter D. Mayer NetWalk System Administrator dmayer@netwalk.com
Subject: Re: (usr-tc) What to request instead of NI-2
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1999-06-15 22:02:46
Thus spake Peter D. Mayer >Ok, I told the telco that we wanted 5ESS custom, and they came back saying that >with 5ESS custom that we couldn't do NFAS, but with NI-2 we could. They're loopy. :) No...if they have a 5ESS switch, I'm relatively sure that it will do NFAS in custom mode...at least I *think* we were doing NFAS with custom translations. Been a while since we did it, but I'm pretty sure we switched to custom before we bailed from NFAS. >It's not >imperative that we do NFAS (D channels don't cost extra here), but I wouldn't >mind the extra B channels. I understand that...not sure NFAS is worth the extra hassle to get the extra B's though, but that gets into personal opinion. >Do you know of any limitations of 5ESS custom that would disallow NFAS? I'm not aware of any such limitations, but when you start talking about switch capabilities, you're getting a bit away from my personal area of expertise. :) -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456
Subject: Re: (usr-tc) traps and using them
From: Paul Farber <farber@admin.f-tech.net>
Date: 1999-06-15 22:29:47
First, I had to use UCD-SNMP 3.5.3 to get the snmptrapd working.. the RPM that came with REDHAT 5.2 didn't work. Start TCM and select the NMC card. From the menu select Faults and trap destinations. Enter your machine IP and public as the password (unless you changed the public community string to something else. Then select trap settings and enable NMC traps. Click on each card and Faults->Trap settings.. select what traps you want. The NMC is a bit chattery.. and the notes say only enable certain traps due to overhead. Read the NMC release notes or the 3Com Knowledgebase for more info. Start snmptrapd on your machine and they should magically appear. If not, start tcpdump and monitor port 612 for activity from the nmc. You should see traps go by. That's about it. Was pretty simple after I got the ucd-snmp package squared away. Paul D. Farber II Farber Technology Ph. 570-628-5303 Fax 570-628-5545 farber@admin.f-tech.net On Tue, 15 Jun 1999, Marcelo Souza wrote: > Hi Paul, > > On Wed, 16 Jun 1999, Paul Farber wrote: > > |I finally got the NMC to spit out some traps and, well, what next. > > Could you give me the steps? I'm trying to use the UCD_SNMP to > manage the traps but it doesn't work yet. I'm using BSDI not Linux, but I > already had compiled the package, the problem is make NMC send the traps > to snmptrapd and make it log them. :-) > In the TC manual they recommend to use the trap daemon on the same > machine of the accounting, is it mandatory? > > TIA > > - Marcelo > > | > |For example.... > | > |uchasSlotIndex.1 = 1 would mean the card in slot 1? > |uchasEntityIndex.1 = 23 would mean the 23rd channel in the 1ist slot?? > | > |Also, what are the call failure codes and the terminate codes?? TCM Win > |just barfs that there is not help available for the topic if I right click > |in the perf mon. > | > |You get the idea... a few pointers or URL to deciphering the traps would > |be helpful! > | > |Paul D. Farber II > |Farber Technology > |Ph. 570-628-5303 > |Fax 570-628-5545 > |farber@admin.f-tech.net > | > | > |- > | To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > | with "unsubscribe usr-tc" in the body of the message. > | For information on digests or retrieving files and old messages send > | "help" to the same address. Do not use quotes in your message. > >
Subject: Re: (usr-tc) NOTICE - HiPerDSP T1/PRI Service Release 1.2.37 (posting
From: Paul Farber <farber@admin.f-tech.net>
Date: 1999-06-16 00:04:54
Seems that the .81 code is more for NFAS than connection issues. Paul D. Farber II Farber Technology Ph. 570-628-5303 Fax 570-628-5545 farber@admin.f-tech.net On Mon, 14 Jun 1999, Pete Ashdown wrote: > Jeff Mcadams said once upon a time: > > >Its extremely encouraging to see 3Com continuing to work on and issue > >releases for the 1.2.x tree when they've already been working on and are > >issuing releases to the 2.0.x tree. This shows (IMO) that 3Com isn't > >trying to push people onto brand new, unproven code as much as I had > >feared. :) > > The only question I have now is what would be better to use? 2.0.81, or > 1.2.37? > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >
Subject: (usr-tc) traps and using them
From: Paul Farber <farber@admin.f-tech.net>
Date: 1999-06-16 01:20:28
hello all I finally got the NMC to spit out some traps and, well, what next. For example.... uchasSlotIndex.1 = 1 would mean the card in slot 1? uchasEntityIndex.1 = 23 would mean the 23rd channel in the 1ist slot?? Also, what are the call failure codes and the terminate codes?? TCM Win just barfs that there is not help available for the topic if I right click in the perf mon. You get the idea... a few pointers or URL to deciphering the traps would be helpful! Paul D. Farber II Farber Technology Ph. 570-628-5303 Fax 570-628-5545 farber@admin.f-tech.net
Subject: (usr-tc) jitter attenuation
From: Mike Andrews <mandrews@termfrost.org>
Date: 1999-06-16 02:47:29
Possibly dumb question: What are the consequences of having jitter attenuation set wrong on a T1? Slightly more bipolar violations/frame errors/etc than usual? Something worse? I've had it set on "transmitter" for a long time now, but some messages I ran across on this list a while ago (while cleaning out my mailbox today) suggested that the default was wrong on DSP's at one point... so I'm trying to figure out which is best, or if it's telco specific or something. Mike Andrews (MA12) -=-=- VP & Sysadmin, Digital Crescent, Frankfort KY mandrews@dcr.net -=- mandrews@termfrost.org -=- http://www.termfrost.org "If Yoda so strong in Force is, why words in right order he cannot put?"
Subject: (usr-tc) NFAS logical group types
From: matthews <matthews@staff.brunnet.net>
Date: 1999-06-16 09:21:13
What is the difference between the different NFAS logical group types? Is there any advantage to using SS7 rather than FAS or NFAS types? The telco tells me they can support all three types and it's up to me to choose but I'm just wondering which is the best or if they're all more or less the same. Matthew...
Subject: (usr-tc) tun:410
From: Randy Doran <randydoran@usa.net>
Date: 1999-06-16 10:32:00
Can anybody tell me what this means? tshlw1> list interface INTERFACES Interface Oper Admin tun:410 Up Up
Subject: Re: (usr-tc) tun:410
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1999-06-16 11:00:32
Thus spake Randy Doran >Can anybody tell me what this means? >tshlw1> list interface >INTERFACES >Interface Oper Admin >tun:410 Up Up Its a tunnel interface...most likely, its a Multi-Link cross-chassis bundle. This is the link that is tunneled from one nas to the other. The nas that the link is tunneled *to* shows a tunnel interface. You can do a "show int tun:410" to show more detailed info about it. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456
Subject: Re: (usr-tc) DSP hardware rev's
From: Randy Doran <randydoran@usa.net>
Date: 1999-06-16 11:43:25
I haven't noticed much differencebut one difference I came across was that on the older 0.49.0 rev the modems defaulted to roundRobin and on the 0.53.0 they defaulted to fixed assignment. I discovered this because I could dial out on all of my 0.53.0 cards but not on the 0.49.0 cards and it turned out to be this setting. At 10:04 PM 6/1/99 -0400, you wrote: >Anyone know the difference between DSP hardware revs 0.49.0, and 0.53.0? > >Thanks in advance, >Rickyz > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >
Subject: Re: (usr-tc) DSP hardware rev's
From: Ricky Beam <jfbeam@bluetopia.net>
Date: 1999-06-16 12:06:11
On Wed, 16 Jun 1999, Randy Doran wrote: >I haven't noticed much differencebut one difference I came across was that >on the older 0.49.0 rev the modems defaulted to roundRobin and on the >0.53.0 they defaulted to fixed assignment. I discovered this because I >could dial out on all of my 0.53.0 cards but not on the 0.49.0 cards and it >turned out to be this setting. [censored]! Have they not fixed that yet? Dead people fix things faster than this. --Ricky
Subject: (usr-tc) Netserver 16I - Flash ROM Reset
From: Steve Rivera <sales@wrca.net>
Date: 1999-06-16 12:17:52
I have a Netserver 16I Plus with the following symptoms. Run/Fail - Solid RED, from start up (Bottom Row) Flash ROM - Solid RED, from start up In the past I have had luck dissassembled the unit, all cards and then put back together. ROM reset and away we go :) In tis case it wont work. Does anyone have any idea of how to reset fail FLASH ROM? Is it possible thru console? Any information would be helpful.
Subject: (usr-tc) Another weirdo request from Jeff :)
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1999-06-16 12:22:45
Once again, I want to see if I can do something really funky and requires a bit of background to explain it. :) As many of you have heard before, we've got our dial-in authentication a slight bit weird here. After connection, there is a 12 second pause (set modem_group all prompt_delay 12) during which the customer can do one of two things...type in "shell" which authenticates with our RADIUS server with the userid "shell" and sets them up as a login user telnet'ing to our shell server, or they can wait and do nothing, in which case, after the 12 second pause is over, the Arc with automatically authenticate with the userid "USR_NETS" (set modem_group all user_name USR_NETS;set modem_group all connection_type prompt_user_only). OK, here's the deal I've been running into recently... I've got a few systems that are having trouble getting the HiPer Arc to start up PPP from what I can tell (they send LCP Conf-Req's over and over and never get anything in response), so what I want to do is set up a new user in my RADIUS server with the userid of "ppp", so the users can, if they need to, type in "ppp" during that 12 second wait, the Arc will then authenticate to the RADIUS server with the userid "ppp", which will be set up as a framed user. This should cause the Arc to fire up ppp, without waiting to detect PPP frames from the users...this is what I want...so it doesn't depend on the Arc detecting the frames from the user (which doesn't seem to be working perfectly from what I can tell). Now, here's the question... When the Arc authenticates with "ppp" during that 12 second window...it starts up PPP, I want it to then use PAP during the PPP negotiation to get the users real userid and password, and authenticate normally. My concerns... If they authenticate during the 12 second pause...the Arc may assume that they are fully authenticated and not insist on using PAP during the PPP negotiation, so we get people connecting without sending their full userid and password...obviously a problem. I don't know what the behavior of the Arc will be with authenticating twice like this...once as a framed user "ppp" and the second time during PAP with a framed user of their real userid and password. Can anyone fill me in on how the Arc behaves in a situation like this? I suspect this will need to be someone from 3Com as I would be seriously surprised to hear that anyone has set up anything like this to find out empirically. :) -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456
Subject: Re: (usr-tc) Another weirdo request from Jeff :)
From: Ricky Beam <jfbeam@bluetopia.net>
Date: 1999-06-16 13:49:43
On Wed, 16 Jun 1999, Jeff Mcadams wrote: >If they authenticate during the 12 second pause...the Arc may assume >that they are fully authenticated and not insist on using PAP during the >PPP negotiation, so we get people connecting without sending their full >userid and password...obviously a problem. I don't know what the >behavior of the Arc will be with authenticating twice like this...once >as a framed user "ppp" and the second time during PAP with a framed user >of their real userid and password. > >Can anyone fill me in on how the Arc behaves in a situation like this? >I suspect this will need to be someone from 3Com as I would be seriously >surprised to hear that anyone has set up anything like this to find out >empirically. :) *bows* Actually, I have tried this... Authenticated is authenticated... once they login from the prompt with "ppp", the NAS will not ask them again. In fact, it will not even ask them to do PAP. HOWEVER, there is a trick you can try... The ARC and the NetServer support "re-chap" authentication which will require the PPP session to periodically reverify authentication via CHAP as an intrustion detection/prevention tool. You might be able to use this to force a "true" authentication, but you're heading into limbo land with this. (I never tried this as I could never use CHAP -- crypt()ed passwords in the database.) --Ricky
Subject: Re: (usr-tc) Merit Radius
From: Ricky Beam <jfbeam@bluetopia.net>
Date: 1999-06-16 13:53:33
On Wed, 16 Jun 1999, Marcelo Souza wrote: > What need to be done to log correct? Get a version of Merit RADIUS (or patches) that understands USR's weird-ass way of doing vendor specific attributes. This was once refered to as "RADIUS Version 2", but was throwen out by IETF. (It's now called "DIAMETER", fwiw) --Ricky
Subject: Re: (usr-tc) Another weirdo request from Jeff :)
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1999-06-16 14:07:42
Thus spake Ricky Beam >On Wed, 16 Jun 1999, Jeff Mcadams wrote: >>If they authenticate during the 12 second pause...the Arc may assume >>that they are fully authenticated and not insist on using PAP during the >>PPP negotiation, so we get people connecting without sending their full >>userid and password...obviously a problem. I don't know what the >>behavior of the Arc will be with authenticating twice like this...once >>as a framed user "ppp" and the second time during PAP with a framed user >>of their real userid and password. >> >>Can anyone fill me in on how the Arc behaves in a situation like this? >>I suspect this will need to be someone from 3Com as I would be seriously >>surprised to hear that anyone has set up anything like this to find out >>empirically. :) >*bows* Actually, I have tried this... Wow...someone else coming up with as sick and twisted network designs as I do? You're sick. :) >Authenticated is authenticated... once they login from the prompt with >"ppp", the NAS will not ask them again. In fact, it will not even ask them >to do PAP. HOWEVER, there is a trick you can try... Blah...I was afraid of that...that leaves me in a bit of a lurch with these folks then...any other way you can think of to let the user specify ppp startup other than just throwing ppp frames at the arc (which apprently isn't working for these specific folks)? >The ARC and the NetServer support "re-chap" authentication which will require >the PPP session to periodically reverify authentication via CHAP as an >intrustion detection/prevention tool. You might be able to use this to >force a "true" authentication, but you're heading into limbo land with >this. (I never tried this as I could never use CHAP -- crypt()ed passwords >in the database.) Can't do that with PAP though...and CHAP requires clear-text passwords on the auth server... So we're stuck with PAP, which prevents the re-auth...besides...I need the auth during the PPP negotiation phase, so the Arc knows the correct values to use during IPCP, rather than whatever is returned by the "ppp" user. We've got some users who are set with static IP addresses and routes and stuff that are assigned via RADIUS, so we need to get the authentication of the user using the real userid and password during the normal PAP phase, so it can have that info during IPCP... I say again, blah. :) -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456
Subject: Re: (usr-tc) Another weirdo request from Jeff :)
From: Ricky Beam <jfbeam@bluetopia.net>
Date: 1999-06-16 14:19:40
On Wed, 16 Jun 1999, Jeff Mcadams wrote: >Wow...someone else coming up with as sick and twisted network designs as >I do? You're sick. :) <grin> And about a year ahead of ya'... What can I say. It was my job. (not that they ever listened until after something was a smoldering heap...) [I'm work for Make Systems now as a member of the technical staff. We make network planning/design software, btw.] >>Authenticated is authenticated... once they login from the prompt with >>"ppp", the NAS will not ask them again. In fact, it will not even ask them >>to do PAP. HOWEVER, there is a trick you can try... > >Blah...I was afraid of that...that leaves me in a bit of a lurch with >these folks then...any other way you can think of to let the user >specify ppp startup other than just throwing ppp frames at the arc >(which apprently isn't working for these specific folks)? Umm, if they can login as "ppp" (I'm assuming a script here) why not just login as the real user and password? (This one's a high "duh" factor.) >I say again, blah. :) Hmm, there is one other possibility... can you say "L2TP Tunnel"? --Ricky
Subject: Re: (usr-tc) Another weirdo request from Jeff :)
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1999-06-16 14:31:02
Thus spake Ricky Beam >What can I say. It was my job. (not that they ever listened until after >something was a smoldering heap...) Heh...I know the feeling...I really know the feeling...though I usually get listened to...at least within our company. >>Blah...I was afraid of that...that leaves me in a bit of a lurch with >>these folks then...any other way you can think of to let the user >>specify ppp startup other than just throwing ppp frames at the arc >>(which apprently isn't working for these specific folks)? >Umm, if they can login as "ppp" (I'm assuming a script here) why not just >login as the real user and password? (This one's a high "duh" factor.) 'Cause of our need for that 12 second timeout makes us have to set up the port to prompt for a userid with a prompt of " " (which is to say nothing), and not to prompt for a password at all...'cause it has to send in the userid "shell" and "USR_NETS" without a password in the event that those are entered or triggered in their own way (either user typing in shell, or the 12 second timer expiring)...so they could put in a userid, but not their password. >>I say again, blah. :) >Hmm, there is one other possibility... can you say "L2TP Tunnel"? Ugh...you talking about letting ppp set up an l2tp (or pptp) tunnel...maybe even to the very same Arc that the call is coming in on...and let the l2tp setup do its own PAP authentication? That's just delightfully sickening. :) -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456
Subject: (usr-tc) Merit Radius
From: Marcelo Souza <mpsouza@centroin.com.br>
Date: 1999-06-16 14:39:32
I'm trying to use Merit AAA Basic server with my ARC TC, but the logfile shows me: Wed Jun 16 14:32:09 1999: generate26: USR attribute 0 unknown Wed Jun 16 14:32:09 1999: gen_valpairs: non-encapsulated vendor specific attribute Vendor-Specific=vUSR-0000902300000015 And the detail some things like that: Vendor-Specific = vUSR-0000984200000015 Vendor-Specific = vUSR-00009843000007f1 Vendor-Specific = vUSR-0000901900000004 Vendor-Specific = vUSR-0000901a00000001 What need to be done to log correct? - Marcelo
Subject: Re: (usr-tc) Another weirdo request from Jeff :)
From: Ricky Beam <jfbeam@bluetopia.net>
Date: 1999-06-16 16:58:18
On Wed, 16 Jun 1999, Jeff Mcadams wrote: >>Umm, if they can login as "ppp" (I'm assuming a script here) why not just >>login as the real user and password? (This one's a high "duh" factor.) > >'Cause of our need for that 12 second timeout makes us have to set up >the port to prompt for a userid with a prompt of " " (which is to say >nothing), and not to prompt for a password at all...'cause it has to >send in the userid "shell" and "USR_NETS" without a password in the >event that those are entered or triggered in their own way (either user >typing in shell, or the 12 second timer expiring)...so they could put in >a userid, but not their password. Hmm... then how do they know when to send the "ppp"? Don't answer that... Actually they can enter both :-) You'll need to do some magic to your RADIUS server to understand where the password is... "user/password" (Yes, I know. I'm a sick little puppy.) >>Hmm, there is one other possibility... can you say "L2TP Tunnel"? > >Ugh...you talking about letting ppp set up an l2tp (or pptp) >tunnel...maybe even to the very same Arc that the call is coming in >on...and let the l2tp setup do its own PAP authentication? That's just >delightfully sickening. :) They enter "ppp" which the RADIUS server answers back with tunnel setup information. Once the tunnel is constructed, the PPP server on the other end of the tunnel will begin PPP LCP... *poof* (Yes, the tunnel could be on the same ARC or tunneled back to a central ARC for these schmucks.) Another evil solution would be to set the "ppp" user to be anything but a framed user and set the session-timeout to 1 second with the session-term-action to "login". (of course, if people knew this is what you were doing they could jam up your lines and/or RADIUS server :-)) --Ricky "they don't call me madd scientist for nothin'"
Subject: Re: (usr-tc) Another weirdo request from Jeff :)
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1999-06-16 17:31:01
Thus spake Ricky Beam >On Wed, 16 Jun 1999, Jeff Mcadams wrote: >>>Umm, if they can login as "ppp" (I'm assuming a script here) why not just >>>login as the real user and password? (This one's a high "duh" factor.) >>'Cause of our need for that 12 second timeout makes us have to set up >>the port to prompt for a userid with a prompt of " " (which is to say >>nothing), and not to prompt for a password at all...'cause it has to >>send in the userid "shell" and "USR_NETS" without a password in the >>event that those are entered or triggered in their own way (either user >>typing in shell, or the 12 second timer expiring)...so they could put in >>a userid, but not their password. >Hmm... then how do they know when to send the "ppp"? They don't, yet. We currently have an interface message of "Please 'type' shell to immediately connect to IgLou's ShellAccess.COM...\nYou are connected to $hostname/$port.\n" with the login prompt of " ", so they know to type "shell" if they want to get connected to the shell server...or if they just wait (ie, a scripted login that's waiting for "ogin:") then the default userid of USR_NETS will do the same. >Don't answer that... >Actually they can enter both :-) You'll need to do some magic to your >RADIUS server to understand where the password is... "user/password" >(Yes, I know. I'm a sick little puppy.) Gack...that's *really* ugly. >>>Hmm, there is one other possibility... can you say "L2TP Tunnel"? >>Ugh...you talking about letting ppp set up an l2tp (or pptp) >>tunnel...maybe even to the very same Arc that the call is coming in >>on...and let the l2tp setup do its own PAP authentication? That's just >>delightfully sickening. :) >They enter "ppp" which the RADIUS server answers back with tunnel setup >information. This is the route I decided to pursue...tests look positive at this point. Just tested on my own setup and it worked like a charm. I set the user "ppp" as a user in the Arc user's table rather than the RADIUS server, but the idea is the same. As a test I tunneled it to a spare Arc that I had (with an IP pool size of 1 just for this test :) just so I could be sure of what was going on. :) >Once the tunnel is constructed, the PPP server on the other >end of the tunnel will begin PPP LCP... *poof* (Yes, the tunnel could be >on the same ARC or tunneled back to a central ARC for these schmucks.) Yup, worked like a charm...now I get to clean up the config a bit and set them all up to tunnel to themselves (woo hoo...won't let me use the loopback address though...have to actually use an address on the eth:1...blah...lame), and then I can let loose the folks that have been having problems and see if they can get logged in this way. :) >Another evil solution would be to set the "ppp" user to be anything but >a framed user and set the session-timeout to 1 second with the >session-term-action to "login". (of course, if people knew this is what >you were doing they could jam up your lines and/or RADIUS server :-)) Eh? This one doesn't make any sense to me. So, after a second, the ppp session would be terminated, but rather than dropping the call, it fires back up into LCP? Hrmm...that could have some possibilities...but I'd be concerned about whether other software is gonna handle that correctly. I suspect a lot of PPP software out there will get an LCP Term-Req and drop the line before checking to see if a new LCP Conf-Req is forthcoming. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456
Subject: (usr-tc) PPTP to linux
From: Brian <signal@shreve.net>
Date: 1999-06-16 17:44:36
If anyone has successfully established a PPTP from the ARC to a Linux box, please let me know. Thanks. Brian Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)
Subject: Re: (usr-tc) Another weirdo request from Jeff :)
From: Ricky Beam <jfbeam@bluetopia.net>
Date: 1999-06-16 17:51:17
On Wed, 16 Jun 1999, Jeff Mcadams wrote: >>Actually they can enter both :-) You'll need to do some magic to your >>RADIUS server to understand where the password is... "user/password" >>(Yes, I know. I'm a sick little puppy.) > >Gack...that's *really* ugly. Don't laugh, that's how netblazers let users change their password! >>Another evil solution would be to set the "ppp" user to be anything but >>a framed user and set the session-timeout to 1 second with the >>session-term-action to "login". (of course, if people knew this is what >>you were doing they could jam up your lines and/or RADIUS server :-)) > >Eh? This one doesn't make any sense to me. So, after a second, the ppp >session would be terminated, but rather than dropping the call, it fires >back up into LCP? Hrmm...that could have some possibilities...but I'd >be concerned about whether other software is gonna handle that >correctly. I suspect a lot of PPP software out there will get an LCP >Term-Req and drop the line before checking to see if a new LCP Conf-Req >is forthcoming. I said "anything BUT a framed user" for that very reason. --Ricky
Subject: Re: (usr-tc) Another weirdo request from Jeff :)
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1999-06-16 18:13:44
Thus spake Ricky Beam >On Wed, 16 Jun 1999, Jeff Mcadams wrote: >>>Actually they can enter both :-) You'll need to do some magic to your >>>RADIUS server to understand where the password is... "user/password" >>>(Yes, I know. I'm a sick little puppy.) >>Gack...that's *really* ugly. >Don't laugh, that's how netblazers let users change their password! Oh lovely...can you say "cleartext?" I knew you could. :) >>Eh? This one doesn't make any sense to me. So, after a second, the ppp >>session would be terminated, but rather than dropping the call, it fires >>back up into LCP? Hrmm...that could have some possibilities...but I'd >>be concerned about whether other software is gonna handle that >>correctly. I suspect a lot of PPP software out there will get an LCP >>Term-Req and drop the line before checking to see if a new LCP Conf-Req >>is forthcoming. >I said "anything BUT a framed user" for that very reason. Ah...ok...that makes some sense then... Back to setting up l2tp tunnels... AIGH! The Arc's puke when trying to set up a tunnel to themselves...giving the messages: Jun 16 17:50:26 lou-ts1.iglou.com At 21:50:29, Facility "L2TP", Level "INFORMATI ON":: L2tp using Locally configured LNS Jun 16 17:50:38 lou-ts1.iglou.com At 21:50:41, Facility "L2TP", Level "INFORMATI ON":: IDLE Timer Expired for host at 204.255.239.3 Jun 16 17:50:38 lou-ts1.iglou.com At 21:50:41, Facility "L2TP", Level "CRITICAL" :: Could Not Contact 204.255.239.3 gonna have to back-end these things I guess...that really sucks, I was really trying to avoid that (waste of IP addresses and all that). -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456
Subject: (usr-tc) Netserver Vs Netserver PRI
From: Jolliffe, Anu <ajolliffe@imagen.net>
Date: 1999-06-16 18:49:08
Can someone please tell me what the difference is between a Netserver Nac and a Netserver PRI Nac? Thank you.
Subject: Re: (usr-tc) Another weirdo request from Jeff :)
From: Ricky Beam <jfbeam@bluetopia.net>
Date: 1999-06-16 19:23:29
On Wed, 16 Jun 1999, Jeff Mcadams wrote: >Oh lovely...can you say "cleartext?" I knew you could. :) You'd login with a regular username but the password would be old/new. It's internal password storage was the plain ol' crypt(). --Ricky
Subject: Re: (usr-tc) Another weirdo request from Jeff :)
From: Sheldon Koehler <sheldon@tenforward.com>
Date: 1999-06-16 21:13:56
What he said... ;) > At 10:10 PM 6/16/99 -0400, Jeff wrote: > >So...that's what I'll be working on in the morning. :) > > > >I'll let you all know how it turns out (in case anyone in interested). > > Most of us are probably feeling stupid, but interested nonetheless :) > Sheldon _____________________________ Sheldon Koehler, Owner/Partner/SysAdmin Chief cook and bottle washer Ten Forward Communications http://www.tenforward.com _____________________________ Someday we'll look back on all this, laugh nervously, and change the subject.
Subject: Re: (usr-tc) Another weirdo request from Jeff :)
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1999-06-16 22:10:22
Thus spake Ricky Beam >On Wed, 16 Jun 1999, Jeff Mcadams wrote: >>Oh lovely...can you say "cleartext?" I knew you could. :) >You'd login with a regular username but the password would be old/new. >It's internal password storage was the plain ol' crypt(). Ah...I was thinking along the lines of userid/new in User-Name attribute, with old password in User-Password. This is rather better than what I was thinking. :) FWIW, the latest in the travails to get l2tp working...you can't use 127.0.0.1 as the l2tp lns (lame), so I figured do something along the lines of "add ip network real-loopback address <something in rfc1918 space> enabled yes interface loopback" and then using the rfc1918 address for the lns address. I *think* it'll let me specify it that way, and that gets it using the loopback interface for this rather than the eth:1, which I think is where the problem might be. So...that's what I'll be working on in the morning. :) I'll let you all know how it turns out (in case anyone in interested). -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456
Subject: (usr-tc) mac connects
From: Brian <signal@shreve.net>
Date: 1999-06-16 22:19:46
What is the fix for macs (global village?) that have problems connecting to the hdm's (1.2.43) Brian Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)
Subject: Re: (usr-tc) Netserver Vs Netserver PRI
From: Ricky Beam <jfbeam@bluetopia.net>
Date: 1999-06-16 23:30:08
On Wed, 16 Jun 1999, Jolliffe, Anu wrote: >Can someone please tell me what the difference is between a Netserver Nac >and a Netserver PRI Nac? The PRI one has a daughter card on it for direct termination of digital traffic. Come on, ask me something difficult... <grin> --Ricky
Subject: Re: (usr-tc) Another weirdo request from Jeff :)
From: K Mitchell <mitch@keyconn.net>
Date: 1999-06-16 23:59:29
At 10:10 PM 6/16/99 -0400, Jeff wrote: >So...that's what I'll be working on in the morning. :) > >I'll let you all know how it turns out (in case anyone in interested). Most of us are probably feeling stupid, but interested nonetheless :) -- Kirk Mitchell-General Manager mitch@keyconn.net Keystone Connect Unlock Your World Altoona, PA 814-941-5000 http://www.keyconn.net
Subject: (usr-tc) USR TC searchable archives
From: Brian <signal@shreve.net>
Date: 1999-06-17 08:56:55
Where are the USR TC searchable archives at? Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)
Subject: Re: (usr-tc) Netserver Vs Netserver PRI
From: Martin Lathoud <nytral@endirect.qc.ca>
Date: 1999-06-17 09:24:26
> On Wed, 16 Jun 1999, Jolliffe, Anu wrote: > >Can someone please tell me what the difference is between a Netserver Nac > >and a Netserver PRI Nac? > > The PRI one has a daughter card on it for direct termination of digital > traffic. > > Come on, ask me something difficult... <grin> The difference between the enhanced and standart packet bus circuit netserver? Mine is: U.S. Robotics Total Control (tm) NETServer Card V.34/ISDN with Frame Relay V3.8.91 Build date: Nov 4 1998 Build time: 14:49:24 Network Interface Card: Ethernet & Frame Relay Combination (26) ISDN Interface Card : MUNICH32 (4) Packet Bus Circuit : Standard and I wonder what is the difference.. The max uptime I have is a week... Martin
Subject: Re: (usr-tc) l2tp frustrations...
From: Tim Wolfe <tim@clipper.net>
Date: 1999-06-17 09:42:43
On Thu, 17 Jun 1999, Jeff Mcadams wrote: > So...I guess (barring that I missed some configuration option on these > things that I blundered into on the other Arc that was using where it > succeeded) I'll have to use a back-end LNS for these folks. Kinda sucks > 'cause that means that I have to assign a seperate block of IP addresses > and stuff for it and configure another Arc for it...would really rather > avoid that, but I guess that's the way its gonna have to be. What about setting up a Linux PPTP server instead of using L2TP? Then you could use RFC1918 space to tunnel to the Linux boxen and then masquerade the customer as an address from your real IP pool. (Or more correctly you'd probably want to do a one-for-one NAT, but it should be easily doable) Just an idea, please feel free to point out the (inevitable) glaring hole in my logic.. :) Tim ============================================================= | Timothy M. Wolfe | Wireless Internet = Get Some | | Chief Network Engineer | 1.800.338.2629 tim@clipper.net | | ClipperNet Corporation | http://www.clipper.net/services/ | =============================================================
Subject: Re: (usr-tc) USR TC searchable archives
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1999-06-17 10:15:34
Thus spake Brian >Where are the USR TC searchable archives at? usr-tc.datasys.net, but they aren't searchable at the moment. :) -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456
Subject: (usr-tc) LCP problems with Cisco 700/800 series routers
From: ROC Services <rocsoft@itol.com>
Date: 1999-06-17 10:28:38
I've posted on this one before, and the problem then proceeded to go away on its own, but now it's back. Customers with Cisco 7xx and 8xx routers are having sporadic difficulties connecting, stalling in the LCP phase. We now have two customer routers exhitibing this behavior, one of which has been having problems since installation but was able to connect occasionally, and the other of which has been working flawlessly for months and suddenly failed of its own accord this morning. I managed to get a "mon ppp" and a tap from these failing sessions, any 3Com techs care to take a look at them? If so, I'll send them off-list so as not to spam everyone. Cisco says this is a problem with the TCH. I'm not so sure I buy that, since nobody else is having any problems connecting. I also sent both the decoded trace and the tap to Cisco for them to look at, one of the affected customers has an open ticket with them so hopefully that will go somewhere. HARC 4.1.59-6 HDSP 2.0.81 on PRI PPP offloading and receive_ACCM are still disabled, tried enabling them to no effect. Here's a small excerpt to illustrate the problem: Outgoing PPP Data on interface: slot:4/mod:23 LCP CFG_REQ MRU 05 ea ASYNC_MAP 00 00 00 00 AUTH_TYPE c0 23 MAGIC_NUM d1 3b b6 b8 PROTO_COMP AC_COMP MPP_MRRU 05 ea MPP_ENDPTID 00 Incoming PPP Data on interface: slot:4/mod:23 LCP CFG_REQ MAGIC_NUM 50 ee 4c 1e MPP_MRRU 05 f4 MPP_ENDPTID 01 53 4d 54 5f 72 6f 75 74 65 72 Outgoing PPP Data on interface: slot:4/mod:23 LCP CFG_ACK MAGIC_NUM 50 ee 4c 1e MPP_MRRU 05 f4 MPP_ENDPTID 01 53 4d 54 5f 72 6f 75 74 65 72 Incoming PPP Data on interface: slot:4/mod:23 LCP CFG_REQ MAGIC_NUM 50 ee 4c 1e MPP_MRRU 05 f4 MPP_ENDPTID 01 53 4d 54 5f 72 6f 75 74 65 72 Outgoing PPP Data on interface: slot:4/mod:23 LCP CFG_ACK MAGIC_NUM 50 ee 4c 1e MPP_MRRU 05 f4 MPP_ENDPTID 01 53 4d 54 5f 72 6f 75 74 65 72 [ .. ad infinitum ..] This clearly shows we are sending CFG_ACK's to their REQs, however two separate Cisco technicians say that their router is not receiving the ACKs. Full trace and tap output available on request.
Subject: (usr-tc) l2tp frustrations...
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1999-06-17 10:58:45
Welp...tried setting up a new ip network on the loopback interface (without using a 127.x.x.x address since 3Com decided that loopbacks shouldn't be used for anything...nevermind that this is the whole reason for their existence)...but even with that, the Arc's complained about not being able to contact the address to be an LNS... So...I guess (barring that I missed some configuration option on these things that I blundered into on the other Arc that was using where it succeeded) I'll have to use a back-end LNS for these folks. Kinda sucks 'cause that means that I have to assign a seperate block of IP addresses and stuff for it and configure another Arc for it...would really rather avoid that, but I guess that's the way its gonna have to be. This should only be used when our normal PPP login path doesn't work, so it shouldn't get used much, so I guess its livable, but it would really be nice to be able to actually use the loopback addresses for something other than nice little placeholders in the "list ip networks" output. :) -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456
Subject: RE: (usr-tc) Netserver Vs Netserver PRI
From: Jolliffe, Anu <ajolliffe@imagen.net>
Date: 1999-06-17 11:00:45
So, I guess my real question is as follows. In order to handle PRI calls do I have to have the Netserver PRI card? Can I use a non-pri Netserver card to route the data in a chassis with 15 quads? Thanxx -----Original Message----- Sent: Wednesday, June 16, 1999 8:30 PM On Wed, 16 Jun 1999, Jolliffe, Anu wrote: >Can someone please tell me what the difference is between a Netserver Nac >and a Netserver PRI Nac? The PRI one has a daughter card on it for direct termination of digital traffic. Come on, ask me something difficult... <grin> --Ricky - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.
Subject: (usr-tc) DOVBS with HDM 2.x?
From: Pete Ashdown <pashdown@xmission.com>
Date: 1999-06-17 11:10:13
Someone mentioned that DOVBS was a feature of HDM 2.x code a while back. I can't find any documentation regarding this. Were they wrong?
Subject: Re: (usr-tc) LCP problems with Cisco 700/800 series routers
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1999-06-17 12:24:44
On Thu, 17 Jun 1999, ROC Services wrote: > I've posted on this one before, and the problem then proceeded to go away > on its own, but now it's back. Customers with Cisco 7xx and 8xx routers > are having sporadic difficulties connecting, stalling in the LCP phase. We > now have two customer routers exhitibing this behavior, one of which has > been having problems since installation but was able to connect > occasionally, and the other of which has been working flawlessly for > months and suddenly failed of its own accord this morning. > > I managed to get a "mon ppp" and a tap from these failing sessions, any > 3Com techs care to take a look at them? If so, I'll send them off-list so > as not to spam everyone. Cisco says this is a problem with the TCH. I'm So Cisco says that since they do not see any PPP on the wire its a TCH problem? How about this - delete the config on the cisco, Start from fresh and do the mimimum config and dial again - It will work. From this PPP trace we are sending out the packets - Start from scratch on the cisco. You can set up tap on the hiper arc to see what exactly is being sent on the wire if need be. More over you are dealing here with Cisco 700/800 techs - they are not sure of anything at all. Default the config and start over on the cisco it will work krish > not so sure I buy that, since nobody else is having any problems > connecting. I also sent both the decoded trace and the tap to Cisco for > them to look at, one of the affected customers has an open ticket with > them so hopefully that will go somewhere. > > HARC 4.1.59-6 > HDSP 2.0.81 on PRI > > PPP offloading and receive_ACCM are still disabled, tried enabling them to > no effect. > > Here's a small excerpt to illustrate the problem: > > Outgoing PPP Data on interface: slot:4/mod:23 > LCP CFG_REQ MRU 05 ea > ASYNC_MAP 00 00 00 00 > AUTH_TYPE c0 23 > MAGIC_NUM d1 3b b6 b8 > PROTO_COMP > AC_COMP > MPP_MRRU 05 ea > MPP_ENDPTID 00 > > Incoming PPP Data on interface: slot:4/mod:23 > LCP CFG_REQ MAGIC_NUM 50 ee 4c 1e > MPP_MRRU 05 f4 > MPP_ENDPTID 01 53 4d 54 5f 72 6f 75 > 74 65 72 > > Outgoing PPP Data on interface: slot:4/mod:23 > LCP CFG_ACK MAGIC_NUM 50 ee 4c 1e > MPP_MRRU 05 f4 > MPP_ENDPTID 01 53 4d 54 5f 72 6f 75 > 74 65 72 > > Incoming PPP Data on interface: slot:4/mod:23 > LCP CFG_REQ MAGIC_NUM 50 ee 4c 1e > MPP_MRRU 05 f4 > MPP_ENDPTID 01 53 4d 54 5f 72 6f 75 > 74 65 72 > > Outgoing PPP Data on interface: slot:4/mod:23 > LCP CFG_ACK MAGIC_NUM 50 ee 4c 1e > MPP_MRRU 05 f4 > MPP_ENDPTID 01 53 4d 54 5f 72 6f 75 > 74 65 72 > > [ .. ad infinitum ..] > > This clearly shows we are sending CFG_ACK's to their REQs, however two > separate Cisco technicians say that their router is not receiving the > ACKs. > > Full trace and tap output available on request. > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >
Subject: Re: (usr-tc) l2tp frustrations...
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1999-06-17 13:03:58
Already replied privately, but figured further discussion about this on the list might be enlightening...besides...I thought of something I didn't mention in my private message. :) Thus spake Tim Wolfe >On Thu, 17 Jun 1999, Jeff Mcadams wrote: >> So...I guess (barring that I missed some configuration option on these >> things that I blundered into on the other Arc that was using where it >> succeeded) I'll have to use a back-end LNS for these folks. Kinda sucks >> 'cause that means that I have to assign a seperate block of IP addresses >> and stuff for it and configure another Arc for it...would really rather >> avoid that, but I guess that's the way its gonna have to be. >What about setting up a Linux PPTP server instead of using L2TP? Then you >could use RFC1918 space to tunnel to the Linux boxen and then masquerade the >customer as an address from your real IP pool. (Or more correctly you'd >probably want to do a one-for-one NAT, but it should be easily doable) >Just an idea, please feel free to point out the (inevitable) glaring hole in >my logic.. :) Nothing glaring. :) A few minor points. :) I mentioned in my private message (before I realized this was also posted to the list) that I tend to avoid using *nix (or *especially* NT) for dialup connection termination. I've just found that general purpose OS'es don't tend to have the reliability that is really needed for dialup connection termination (at least in theory...less code, fewer bugs in the general idea). Also, we're set up to do PPP authentication via RADIUS, doing it directly from a Linux box would be bizarre at best...and while I'm certainly not afraid to embrace bizarre situations when necessary, I tend to avoid them when there's no real benefit to it. The reason that there's no real benefit to this is that, even with NAT, or IPmasq on the Linux box...it will still require an IP pool seperate from what's on the Arc's...the idea of doing the tunneling back to the arc from which it started was to avoid allocating a seperate set of addresses for customers doing the l2tp tunneling, from the people running auto-detected ppp on the arcs directly. If the call is tunneled over to a seperate box, even with masq and NAT, it would still require a seperate IP pool to pull addresses from than the pool on the Arcs already being used with auto-detected PPP. Unfortunately, since l2tp doesn't seem to like having the lac and lns for a tunnel on the same box, it looks like I have no alternative but to use a back-end system for the lns. However, since we're already set up for RADIUS authentication and supporting the Arcs, and the Arcs are a quite competent LNS on their own, so I don't see any real need to set up a Linux box to do what the Arc will already do. Thanks for the idea, but I think there are more drawbacks to it than benefits. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456
Subject: RE: (usr-tc) Netserver Vs Netserver PRI
From: Jolliffe, Anu <ajolliffe@imagen.net>
Date: 1999-06-17 13:28:15
I have a Netserver card that came in a chassis with a bunch of Analog only modems. I want to ditch the digiboards, Analogs, and NT box, put in 12 A/D's and go about my way. Do you think it will work? -----Original Message----- Sent: Thursday, June 17, 1999 12:10 PM At 02:25 PM 6/17/1999 -0400, you wrote: >On Thu, 17 Jun 1999, Jolliffe, Anu wrote: >>In order to handle PRI calls do I have to have the Netserver PRI card? >>Can I use a non-pri Netserver card to route the data in a chassis with 15 >>quads? > >No, you do not need a netserver PRI to handle ISDN calls. The quads can do >the job -- and IMO should. Interesting as I had both Netserver & Netserver PRI Cards. Which is most recent version that came out with X2/V.90 Capable (non-Hyper) USR Chassis's then? Seems everyone always asks (via sales) for Netserver/PRI. I have a Netserver listed as part number (on the tag) 69-000809-01 R:2 that I can't seem to match up to any of the versions of the netServer as listed on 3Com's site. ******* Top Net InterNet Services ******** Omaha, Nebraska www.top.net Voice: (402) 339-5609 - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.
Subject: (usr-tc) WTB Empty 70amp Total Control chassis
From: access1 <access1@simplyweb.net>
Date: 1999-06-17 13:48:23
WTB Empty 3COM/USR 70amp Total Control chassis. Already have cards. Consider full set if price attractive enough. send private reply with price.
Subject: Re: (usr-tc) Netserver Vs Netserver PRI
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1999-06-17 14:07:42
Thus spake Jolliffe, Anu >So, I guess my real question is as follows. >In order to handle PRI calls do I have to have the Netserver PRI card? No...the original reason for the distinction was that the quads were unable to handle ISDN calls. So the ISDN calls were routed directly from the dual-pri card over to the NETServer card and terminated on the NETServer card. When the quads were upgraded to have the ability to handle ISDN calls directly (made the I-modems basically) the point of having the Munich daughtercard on the NETServer was kinda lost, but the distinction still remains. You can now tell the dual-pri card to terminate the calls to the quads, instead of passing them to the NETServer card (set the ISDN gateway slot to 0), when the calls are passed from the quads on to the NETServer, there really is no distinction in the NETServer between an analog call and an ISDN digital call...it will report a different modulation via RADIUS, but that's just a value that it relays on from the modem cards, so it could be some random string as far as the NETServer is concerned. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456
Subject: RE: (usr-tc) Netserver Vs Netserver PRI
From: Jim Logan <jim@top.net>
Date: 1999-06-17 14:09:52
At 02:25 PM 6/17/1999 -0400, you wrote: >On Thu, 17 Jun 1999, Jolliffe, Anu wrote: >>In order to handle PRI calls do I have to have the Netserver PRI card? >>Can I use a non-pri Netserver card to route the data in a chassis with 15 >>quads? > >No, you do not need a netserver PRI to handle ISDN calls. The quads can do >the job -- and IMO should. Interesting as I had both Netserver & Netserver PRI Cards. Which is most recent version that came out with X2/V.90 Capable (non-Hyper) USR Chassis's then? Seems everyone always asks (via sales) for Netserver/PRI. I have a Netserver listed as part number (on the tag) 69-000809-01 R:2 that I can't seem to match up to any of the versions of the netServer as listed on 3Com's site. ******* Top Net InterNet Services ******** Omaha, Nebraska www.top.net Voice: (402) 339-5609
Subject: RE: (usr-tc) Netserver Vs Netserver PRI
From: Ricky Beam <jfbeam@bluetopia.net>
Date: 1999-06-17 14:25:43
On Thu, 17 Jun 1999, Jolliffe, Anu wrote: >In order to handle PRI calls do I have to have the Netserver PRI card? >Can I use a non-pri Netserver card to route the data in a chassis with 15 >quads? No, you do not need a netserver PRI to handle ISDN calls. The quads can do the job -- and IMO should. --Ricky
Subject: Re: (usr-tc) USR TC still hoses passwords
From: Pete Ashdown <pashdown@xmission.com>
Date: 1999-06-17 14:58:14
Brian are you still having this problem on 2.0.81?
Subject: Re: (usr-tc) re: looking for a PRI netserver card set
From: access1 <access1@simplyweb.net>
Date: 1999-06-17 15:05:50
I have the 1393 and 1003 card set. will cannibalize spare set , we can work out acceptable details. $1500 is ok. are you still looking?????? will this help.. Andrew:PC Global, Inc. wrote: > Hello- > > I am in need of usr# 000976-0 PRI Netserver card set consisting of : > > 69-0001003, 69-0001393, 67-000209 > > these numbers are found on the white stickers on the card. If you have any, > know where to get any please email me via private email for immediate > purchase. > > Paying up to $1500 per set . Must have the numbers on the cards as listed > above. > > Warmest Regards, > Andrew Shlensky > **************************** > PC Global, Inc. > (305) 667-2111 tel > (305) 667-3636 fax > (305) 216-8638 mobile > URL: http://www.pcglobal.net > E-MAIL: andrew@pcglobal.net > ICQ: 21219089 > Computer Service Parts SpEciaLiSts! > ALSO:SALES of New/Used PCs,Laptops > Communication & Networking,Monitors > Printers, Hard Drives, Midrange/Mainframe. > Hard to Get Parts. We buy and sell all > types of GEAR- > **************************** > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message.
Subject: (usr-tc) USR TC still hoses passwords
From: Brian <signal@shreve.net>
Date: 1999-06-17 15:27:57
A while back some postings were made about the HDM ppp code totally hosing some passwords by munging the last character. What is the status on this? Was 3Com able to replicate the problem? I just did some checking and it doesn't look good. If you use Radiator, the following will check for the problem: #!/usr/bin/perl open(PASSLOG,"/usr/local/radiator/radacct/password.log"); while(<PASSLOG>) { if(/(\w+\s+\w+\s+\d+\s+\d+:\d+:\d+\s+\d+):\d+:(\w+):(\S+):ENCRYPTED:PASS/) { $date=3D$1; $username=3D$2; $password=3D$3; $pass{$username}=3D$password; } =20 } close(PASSLOG); open(PASSLOG,"/usr/local/radiator/radacct/password.log"); while(<PASSLOG>) { if(/(\w+\s+\w+\s+\d+\s+\d+:\d+:\d+\s+\d+):\d+:(\w+):(\S+):ENCRYPTED:FAIL/) { $date=3D$1; $username=3D$2; $password=3D$3; if( substr($pass{$username},0,-1) eq substr($password,0,-1)) { print "$username $pass{$username} $password\n"; }=20 } } =20 close(PASSLOG); Here is a sample of what I got in just a few days: (usernames left out to protect the innocent :) ). Kab#bfg Kab#bf=E8 qt76vR qt76v=D0 carson carso=B3 sondra sondrM 3413 341=C8 qt76vR qt76v" 52572 5257p grep19 grep1=C0 47cew 47ceu 1c53f1 1c53f=D0 d476!* d476!P txzt92 txzt9n sugar suga=D6 3413 341t wam55% wam55=CC lexus lexu=8A 6851Z92 6851Z9=92 zse456 zse45=D5 53853 5385=D9 3413 341=B7 account accounb lmc8257 lmc8257 lmc8257 lmc8257 lmc8257 lmc8257 lmc8257 lmc8257 ad!sifda ad!sifdc lmc8257 lmc8257 lmc8257 lmc8257 lmc8257 lmc8257 lmc8257 lmc8257 lmc8257 lmc8257 ad!sifda ad!sifdy 5156 515u b52cras b52craP GpM77r GpM77+ nub660 nub669 lwins lwinI 50798 5079=D5 52958 5295B iggyalf igg=D9al stormy storme 437jmb 437jm=CF sugar suga=D6 tsocc tsoc=D6 grep19 grep1 broke brokD brick bric=F4 ciret cire=F2 april apri=E2 50174 5017=BC george1 george=D6 WXB372 WXB37E d476!* d476!P lions lion=CC !cvxM57 !cvxM5=D5 nub660 nub66=82 3413 3418 ttcpx7 ttcpx 3413 3418 3413 341=94 kirkt kirko 1046 104> 81239 8123x kirkt kirk0 nub660 nub66=CC 5139 513=80 nub660 nub66=CC 52993 5299=D5 This translates to customers having to call mutliple times to get a connection. What is the fix? Brian Feeny (BF304) signal@shreve.net =20 318-222-2638 x 109=09http://www.shreve.net/~signal =20 Network Administrator ShreveNet Inc. (ASN 11881) =09 =20
Subject: Re: (usr-tc) USR TC still hoses passwords
From: Brian <signal@shreve.net>
Date: 1999-06-17 16:12:08
On Thu, 17 Jun 1999, Pete Ashdown wrote: > Brian are you still having this problem on 2.0.81? I havne't moved to 2.0.81............I am wondering if the latest 1.2.x service release fixes this, I didn't see anythign in the release notes about it................ I suppose maybe with the new code I could disable ppp offloading, and then it would be fine. You couldn't disable ppp offloading up to 1.2.43 because I think it broke other stuff (I can't remember what though) Brian > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)
Subject: Re: (usr-tc) USR TC still hoses passwords
From: Brian <signal@shreve.net>
Date: 1999-06-17 16:13:01
On Thu, 17 Jun 1999, Tatai SV Krishnan wrote: > On Thu, 17 Jun 1999, Brian wrote: > > > > > A while back some postings were made about the HDM ppp code totally hosing > > some passwords by munging the last character. What is the status on this? > > Was 3Com able to replicate the problem? I just did some checking and it > > doesn't look good. > > Is this with 2.0.81 code? > > krish This is 1.2.43 code. I am making the move to the latest 1.2.x service release like tommorow, will that fix it? Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)
Subject: Re: (usr-tc) USR TC still hoses passwords
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1999-06-17 16:32:35
On Thu, 17 Jun 1999, Brian wrote: >=20 > A while back some postings were made about the HDM ppp code totally hosin= g > some passwords by munging the last character. What is the status on this= ? > Was 3Com able to replicate the problem? I just did some checking and it > doesn't look good. Is this with 2.0.81 code? krish >=20 > If you use Radiator, the following will check for the problem: >=20 > #!/usr/bin/perl > open(PASSLOG,"/usr/local/radiator/radacct/password.log"); > while(<PASSLOG>) { >=20 > if(/(\w+\s+\w+\s+\d+\s+\d+:\d+:\d+\s+\d+):\d+:(\w+):(\S+):ENCRYPTED:PASS/= ) > { > $date=3D$1; > $username=3D$2; > $password=3D$3; > $pass{$username}=3D$password; > } =20 > } > close(PASSLOG); >=20 > open(PASSLOG,"/usr/local/radiator/radacct/password.log"); > while(<PASSLOG>) { >=20 > if(/(\w+\s+\w+\s+\d+\s+\d+:\d+:\d+\s+\d+):\d+:(\w+):(\S+):ENCRYPTED:FAIL/= ) > { > $date=3D$1; > $username=3D$2; > $password=3D$3; > if( substr($pass{$username},0,-1) eq substr($password,0,-1)) { > print "$username $pass{$username} $password\n"; > }=20 > } > } =20 > close(PASSLOG); >=20 >=20 > Here is a sample of what I got in just a few days: > (usernames left out to protect the innocent :) ). >=20 > Kab#bfg Kab#bf=E8 > qt76vR qt76v=D0 > carson carso=B3 > sondra sondrM > 3413 341=C8 > qt76vR qt76v" > 52572 5257p > grep19 grep1=C0 > 47cew 47ceu > 1c53f1 1c53f=D0 > d476!* d476!P > txzt92 txzt9n > sugar suga=D6 > 3413 341t > wam55% wam55=CC > lexus lexu=8A > 6851Z92 6851Z9=92 > zse456 zse45=D5 > 53853 5385=D9 > 3413 341=B7 > account accounb > lmc8257 lmc8257 > lmc8257 lmc8257 > lmc8257 lmc8257 > lmc8257 lmc8257 > ad!sifda ad!sifdc > lmc8257 lmc8257 > lmc8257 lmc8257 > lmc8257 lmc8257 > lmc8257 lmc8257 > lmc8257 lmc8257 > ad!sifda ad!sifdy > 5156 515u > b52cras b52craP > GpM77r GpM77+ > nub660 nub669 > lwins lwinI > 50798 5079=D5 > 52958 5295B > iggyalf igg=D9al > stormy storme > 437jmb 437jm=CF > sugar suga=D6 > tsocc tsoc=D6 > grep19 grep1 > broke brokD > brick bric=F4 > ciret cire=F2 > april apri=E2 > 50174 5017=BC > george1 george=D6 > WXB372 WXB37E > d476!* d476!P > lions lion=CC > !cvxM57 !cvxM5=D5 > nub660 nub66=82 > 3413 3418 > ttcpx7 ttcpx > 3413 3418 > 3413 341=94 > kirkt kirko > 1046 104> > 81239 8123x > kirkt kirk0 > nub660 nub66=CC > 5139 513=80 > nub660 nub66=CC > 52993 5299=D5 >=20 >=20 > This translates to customers having to call mutliple times to get a > connection. What is the fix? >=20 >=20 > ----------------------------------------------------- > Brian Feeny (BF304) signal@shreve.net =20 > 318-222-2638 x 109=09http://www.shreve.net/~signal =20 > Network Administrator ShreveNet Inc. (ASN 11881) =09 =20 >=20 >=20 > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >=20
Subject: (usr-tc) re: looking for a PRI netserver card set
From: Andrew:PC Global, Inc. <andrew@pcglobal.net>
Date: 1999-06-17 16:36:13
Hello- I am in need of usr# 000976-0 PRI Netserver card set consisting of : 69-0001003, 69-0001393, 67-000209 these numbers are found on the white stickers on the card. If you have any, know where to get any please email me via private email for immediate purchase. Paying up to $1500 per set . Must have the numbers on the cards as listed above. Warmest Regards, Andrew Shlensky **************************** PC Global, Inc. (305) 667-2111 tel (305) 667-3636 fax (305) 216-8638 mobile URL: http://www.pcglobal.net E-MAIL: andrew@pcglobal.net ICQ: 21219089 Computer Service Parts SpEciaLiSts! ALSO:SALES of New/Used PCs,Laptops Communication & Networking,Monitors Printers, Hard Drives, Midrange/Mainframe. Hard to Get Parts. We buy and sell all types of GEAR- ****************************
Subject: Re: (usr-tc) USR TC still hoses passwords
From: Brian <signal@shreve.net>
Date: 1999-06-17 16:37:46
On Thu, 17 Jun 1999, Tatai SV Krishnan wrote: > On Thu, 17 Jun 1999, Brian wrote: > > > On Thu, 17 Jun 1999, Tatai SV Krishnan wrote: > > > > > On Thu, 17 Jun 1999, Brian wrote: > > > > > > > > > > > A while back some postings were made about the HDM ppp code totally hosing > > > > some passwords by munging the last character. What is the status on this? > > > > Was 3Com able to replicate the problem? I just did some checking and it > > > > doesn't look good. > > > > > > Is this with 2.0.81 code? > > > > > > krish > > > > This is 1.2.43 code. I am making the move to the latest 1.2.x service > > release like tommorow, will that fix it? > > > 1.2.37 and 2.0.81 should have addressed this problem. ok, is the following still recommended/necessary? enable ppp offloading disable ppp receive_accm I suppose ppp offloading is good anyways, putting it on the hdm's, but what about ppp receive_accm, do we want that? Any issues with macintosh in this release or fixed in this release (1.2.37) Brian > > krish > > > > > ----------------------------------------------------- > > Brian Feeny (BF304) signal@shreve.net > > 318-222-2638 x 109 http://www.shreve.net/~signal > > Network Administrator ShreveNet Inc. (ASN 11881) > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)
Subject: Re: (usr-tc) USR TC still hoses passwords
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1999-06-17 16:45:55
On Thu, 17 Jun 1999, Brian wrote: > On Thu, 17 Jun 1999, Tatai SV Krishnan wrote: > > > On Thu, 17 Jun 1999, Brian wrote: > > > > > > > > A while back some postings were made about the HDM ppp code totally hosing > > > some passwords by munging the last character. What is the status on this? > > > Was 3Com able to replicate the problem? I just did some checking and it > > > doesn't look good. > > > > Is this with 2.0.81 code? > > > > krish > > This is 1.2.43 code. I am making the move to the latest 1.2.x service > release like tommorow, will that fix it? 1.2.37 and 2.0.81 should have addressed this problem. krish > > ----------------------------------------------------- > Brian Feeny (BF304) signal@shreve.net > 318-222-2638 x 109 http://www.shreve.net/~signal > Network Administrator ShreveNet Inc. (ASN 11881) > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >
Subject: (usr-tc) What is "Client-Port-Id?"
From: Randy Doran <randydoran@usa.net>
Date: 1999-06-17 16:50:53
I saw this once before in other threads on this list. Does anybody know what exactly "Client-Port-Id" is? Is it an ID you can find on the HiPerARC? Or is it a 3Com VSA that is sent to the Radius accounting detail logs?
Subject: (usr-tc) Lastest release
From: Terry Kennedy <terry@olypen.com>
Date: 1999-06-17 16:57:23
3com says there's an eng. release for the DSP's still 1.x.x version. It's not on totalservice. I'm not ready for 2.x.x and don't need it, channelized T1. Has anyone seen it or know where to get it?
Subject: Re: (usr-tc) DSP Error - HELP
From: Peter Olson <peter.olson@chi.frb.org>
Date: 1999-06-17 17:53:30
Marcelo Souza wrote: > > What should be the "Reason for call failure": > > pbGenericError(46) > > On the performance monitor of TCM. > > I have two of my DSP rejecting calls with it. > I don't have an answer, but I too have seen this error on a chassis. I did a reset of the management card, and the system started accepting calls. Perhaps corruption on the management bus? We are running NMC 5.5.5, HiperDSP 1.2.59. --Peter
Subject: (usr-tc) DSP Error - HELP
From: Marcelo Souza <mpsouza@centroin.com.br>
Date: 1999-06-17 18:11:32
What should be the "Reason for call failure": pbGenericError(46) On the performance monitor of TCM. I have two of my DSP rejecting calls with it. - Marcelo
Subject: RE: (usr-tc) WTB Empty 70amp Total Control chassis
From: John Verreault <verreaul@aei.ca>
Date: 1999-06-17 19:22:42
$2K w/power supply if you are interested John > -----Original Message----- > From: owner-usr-tc@lists.xmission.com > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of access1 > Sent: Thursday, June 17, 1999 4:48 PM > To: usr-tc@lists.xmission.com > Subject: (usr-tc) WTB Empty 70amp Total Control chassis > > > WTB Empty 3COM/USR 70amp Total Control chassis. Already have cards. > Consider full set if price attractive enough. send private reply with > price. > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >
Subject: Re: (usr-tc) DSP Error - HELP
From: Marcelo Souza <mpsouza@centroin.com.br>
Date: 1999-06-17 19:29:13
On Thu, 17 Jun 1999, Marcelo Souza wrote: | What should be the "Reason for call failure": | | pbGenericError(46) | | On the performance monitor of TCM. | | I have two of my DSP rejecting calls with it. Ok, I changed the DSPs to another empty slots and the problem stoped. Is it a hardware problem? - Marcelo
Subject: Re: (usr-tc) Lastest release
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1999-06-17 20:08:38
Thus spake Terry Kennedy >3com says there's an eng. release for the DSP's >still 1.x.x version. It's not on totalservice. >I'm not ready for 2.x.x and don't need it, channelized T1. >Has anyone seen it or know where to get it? Don't choose latest code, pick the software library, and select the HiPer DSP. It's 1.2.37. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456
Subject: Re: (usr-tc) Lastest release
From: Brian <signal@shreve.net>
Date: 1999-06-17 21:28:03
On Thu, 17 Jun 1999, Terry Kennedy wrote: > 3com says there's an eng. release for the DSP's > still 1.x.x version. It's not on totalservice. > I'm not ready for 2.x.x and don't need it, channelized T1. > Has anyone seen it or know where to get it? You are probably going to "latest code". 2.0.x is the "latest code". Goto Software Library Then goto TCS v3.3 You will find it there. Brian > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)
Subject: Re: (usr-tc) re: looking for a PRI netserver card set
From: Andrew:PC Global, Inc. <andrew@pcglobal.net>
Date: 1999-06-17 23:25:08
found a few for $1100.. Could use more.. can you provide a contact tel # and name so we can work out the transaction tomorrow? Thanks, Andrew Shlensky **************************** PC Global, Inc. (305) 667-2111 tel (305) 667-3636 fax (305) 216-8638 mobile URL: http://www.pcglobal.net E-MAIL: andrew@pcglobal.net ICQ: 21219089 Computer Service Parts SpEciaLiSts! ALSO:SALES of New/Used PCs,Laptops Communication & Networking,Monitors Printers, Hard Drives, Midrange/Mainframe. Hard to Get Parts. We buy and sell all types of GEAR- **************************** ----- Original Message ----- Sent: Thursday, June 17, 1999 6:05 PM I have the 1393 and 1003 card set. will cannibalize spare set , we can work out acceptable details. $1500 is ok. are you still looking?????? will this help.. Andrew:PC Global, Inc. wrote: > Hello- > > I am in need of usr# 000976-0 PRI Netserver card set consisting of : > > 69-0001003, 69-0001393, 67-000209 > > these numbers are found on the white stickers on the card. If you have any, > know where to get any please email me via private email for immediate > purchase. > > Paying up to $1500 per set . Must have the numbers on the cards as listed > above. > > Warmest Regards, > Andrew Shlensky > **************************** > PC Global, Inc. > (305) 667-2111 tel > (305) 667-3636 fax > (305) 216-8638 mobile > URL: http://www.pcglobal.net > E-MAIL: andrew@pcglobal.net > ICQ: 21219089 > Computer Service Parts SpEciaLiSts! > ALSO:SALES of New/Used PCs,Laptops > Communication & Networking,Monitors > Printers, Hard Drives, Midrange/Mainframe. > Hard to Get Parts. We buy and sell all > types of GEAR- > **************************** > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.
Subject: (usr-tc) Shell Accounts
From: Nader Kheyrdan <nader@ccinet.com>
Date: 1999-06-18 00:08:11
Hello, I have a problem and thought some of you can help. We have Total control and Postmaster PM2's and we have been providing Shell Dialup accounts to some of our customer. The problem I am having is if a customer dials to Postmaster the shell works fine since I have added the Postmaster IP in hosts.equiv, but even though I have added the Total Control IP to the same file, when I dial to TC, I get the following error: login: test ******* Host not available ********** What seems to be the problem? How can I fix it. Nader Kheyrdan CCI Industries, Inc. E-mail: Nader@ccinet.com Voice: (714)738-7270 Fax: (714)447-0544 WEB: www.ccinet.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Subject: Re: (usr-tc) LCP problems with Cisco 700/800 series routers
From: ROC Services <rocsoft@itol.com>
Date: 1999-06-18 08:47:16
On Thu, 17 Jun 1999, Tatai SV Krishnan wrote: > > I've posted on this one before, and the problem then proceeded to go away > > on its own, but now it's back. Customers with Cisco 7xx and 8xx routers > > are having sporadic difficulties connecting, stalling in the LCP phase. We > > now have two customer routers exhitibing this behavior, one of which has > > been having problems since installation but was able to connect > > occasionally, and the other of which has been working flawlessly for > > months and suddenly failed of its own accord this morning. > > > > I managed to get a "mon ppp" and a tap from these failing sessions, any > > 3Com techs care to take a look at them? If so, I'll send them off-list so > > as not to spam everyone. Cisco says this is a problem with the TCH. I'm > > So Cisco says that since they do not see any PPP on the wire its a TCH > problem? How about this - delete the config on the cisco, Start from > fresh and do the mimimum config and dial again - It will work. OK, false alarm... this one is some kind of bizarre telco problem. A few other customers in the same geographic area are now having the same problem, and we're able to replicate it with any kind of ISDN equipment, not just the Ciscos, and upon bringing one of the Ciscos into the office for testing, it works fine. Based on the tap output I had pretty much figured it as "not our problem" but I wanted to make sure.
Subject: Re: (usr-tc) DSP Error - HELP
From: Jason Kelton <cascade@keltec.com.au>
Date: 1999-06-18 09:08:37
Marcelo, An educated guess, but could it be a problem with the chassis - a dry joint maybe? I have seen this in the past with quads and ns combo's... primarily with the netservers tho... moving it to a different slot was the workaround, but replacing the chassis fixed it. Regards, Jase. ----- Original Message ----- Sent: Friday, June 18, 1999 8:29 AM > On Thu, 17 Jun 1999, Marcelo Souza wrote: > > | What should be the "Reason for call failure": > | > | pbGenericError(46) > | > | On the performance monitor of TCM. > | > | I have two of my DSP rejecting calls with it. > > > Ok, I changed the DSPs to another empty slots and the problem > stoped. > Is it a hardware problem? > > > - Marcelo > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message.
Subject: Re: (usr-tc) mac connects
From: Pete Ashdown <pashdown@xmission.com>
Date: 1999-06-18 10:38:40
Brian said once upon a time: > >What is the fix for macs (global village?) that have problems connecting >to the hdm's (1.2.43) Upgrade your code, or tell your customers to use Apple's Open Transport PPP rather than FreePPP.
Subject: (usr-tc) 1.2.37 update
From: Brian <signal@shreve.net>
Date: 1999-06-18 11:47:45
1.2.37 did indeed fix the problems we saw with PPP offloading corrupting the last character of a password. That was one serious bug which caused alot of customer service issues, 3Com had a problem replicating/identifying the problem initially, but I am glad it is fixed. I would be interested in knowing what the problem was, and who the problem was affecting. I noticed alot of Mac users got the last char corruption, was their a correlation there? If anyone is still running 1.2.43 and ppp offloading, and has not made the switch to 1.2.37..........you are more than likely putting quite a few users thru multiple re-connects. Brian Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)
Subject: Re: (usr-tc) mac connects
From: Brian <signal@shreve.net>
Date: 1999-06-18 11:48:58
On Fri, 18 Jun 1999, Pete Ashdown wrote: > Brian said once upon a time: > > > >What is the fix for macs (global village?) that have problems connecting > >to the hdm's (1.2.43) > > Upgrade your code, or tell your customers to use Apple's Open Transport PPP > rather than FreePPP. Ok, I know we encourage Open Transport. Regarding FreePPP, what was the problem with FreePPP and 1.2.43? What that the password corruption problem? > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)
Subject: RE: (usr-tc) Lastest release
From: Terry Kennedy <terry@olypen.com>
Date: 1999-06-18 14:27:31
Thanks Brian, Found it, the code isn't 2.x series but 1.2.37 update. -----Original Message----- [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Brian Sent: Thursday, June 17, 1999 7:28 PM On Thu, 17 Jun 1999, Terry Kennedy wrote: > 3com says there's an eng. release for the DSP's > still 1.x.x version. It's not on totalservice. > I'm not ready for 2.x.x and don't need it, channelized T1. > Has anyone seen it or know where to get it? You are probably going to "latest code". 2.0.x is the "latest code". Goto Software Library Then goto TCS v3.3 You will find it there. Brian > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881) - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.
Subject: (usr-tc) netsvr manager software
From: John Campbell <sparky@roava.net>
Date: 1999-06-18 17:54:45
I had a software crash of my netserver manager software, and it has been so long since I have installed this software I forgot where I got it... Could someone please offer advice to where I can get this software fairly quickly... Please respond directly to sparky@roava.net . Thanks in advance. John Campbell Owner - Roanoke Virginia Net http://www.roava.net mailto:sparky@roava.net
Subject: (usr-tc) obscure MIB variables
From: Mike Andrews <mandrews@termfrost.org>
Date: 1999-06-18 18:54:47
How does one decode the information in mdmCsTrainingInfo and mdmCsX2signature -- or for the TCM people, "Training Info" and "x2 Signature" under the Performance Monitor? Is there anything useful for debugging x2/v.90 connections in there? Also in Performance Monitor, how do you get the Remote Modem Management to do anything useful? Does it only work when the remote modem is another Total Control (or perhaps Courier) modem? Mike Andrews (MA12) -=-=- VP & Sysadmin, Digital Crescent, Frankfort KY mandrews@dcr.net -=- mandrews@termfrost.org -=- http://www.termfrost.org "If Yoda so strong in Force is, why words in right order he cannot put?"
Subject: Re: (usr-tc) T3 mux vs. T1s
From: Frank Basso <frank@okwhatever.com>
Date: 1999-06-18 22:45:37
If you are using channleized t-1's then you have your answer. Can you say Robbed Bit Signalling ? ---------- Original Message ---------------------------------- Reply-To: usr-tc@lists.xmission.com >We recently changed to a T3 mux from individual T1s for our dial-up trunks. >Since then we have noticed that our disconnect rates for users has tripled. >Everything is set fine on the mux, and Ameritech says the trunks (both t1 >and t3) look clean. The error log on the mux tends to back them up. I use >mostly hyper dsps but still have a few Netserver boxes with quads. Anyone >have this problem before? Is their any known issues or special settings to >do on the hyperarcs or Netservers? > >Russ Miescke >Power Web Connect > > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message.
Subject: Re: (usr-tc) obscure MIB variables
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1999-06-18 22:47:24
Thus spake Mike Andrews >How does one decode the information in mdmCsTrainingInfo and >mdmCsX2signature -- or for the TCM people, "Training Info" and "x2 >Signature" under the Performance Monitor? Is there anything useful for >debugging x2/v.90 connections in there? Haven't a clue on these...You're definitely ahead of me in using SNMP MIBS (though I am catching up! :) >Also in Performance Monitor, how do you get the Remote Modem Management to >do anything useful? Does it only work when the remote modem is another >Total Control (or perhaps Courier) modem? You don't yet...it will be a feature in the Couriers...but it isn't there yet from what I've been told. I guess you might get info if there's another TC at the other end, but that doesn't exactly happen all too often. :) -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456
Subject: (usr-tc) T3 mux vs. T1s
From: Russ Miescke <russm@powerweb.net>
Date: 1999-06-18 23:22:46
We recently changed to a T3 mux from individual T1s for our dial-up trunks. Since then we have noticed that our disconnect rates for users has tripled. Everything is set fine on the mux, and Ameritech says the trunks (both t1 and t3) look clean. The error log on the mux tends to back them up. I use mostly hyper dsps but still have a few Netserver boxes with quads. Anyone have this problem before? Is their any known issues or special settings to do on the hyperarcs or Netservers? Russ Miescke Power Web Connect
Subject: RE: (usr-tc) T3 mux vs. T1s
From: Frank Basso <frank@okwhatever.com>
Date: 1999-06-18 23:34:10
It is. We use PRI's only, channelized T-1's seem to croak. Thanks for remebering. -Frank ---------- Original Message ---------------------------------- Reply-To: usr-tc@lists.xmission.com >Hey Frank, in 1998 you said something a little different: > >========================================== >From: "Frank Basso" <frank@okwhatever.com> >To: <usr-tc@lists.xmission.com>, <sbarrett@cyberzone.net> >Subject: Re: (usr-tc) Looking for a good DS3 MUX >Date: Fri, 5 Jun 1998 08:21:15 -0700 > >We are using the 3COM Accessbuilder 6200. It supports multiple DS-3's and is >a GREAT Unit for provisioning your links. > >Check it out. > >Frank Basso >Network Administrator >The Internet Connection, Inc. >DBA. Got.Net? >========================================== > >Russ, there was an issue with certain t3 mux's and hiperdsp modems (specific >code versions) but I cannot seem to remember the subject or find it in the >3kb. I would ask one of our faithful 3com reps on the list. We have both PRI >and CT1 circuits and the disconnect rates are not appreciably different nor >has the data presented by our old guru David formerly from ANS agree with >Frank's statement. > >Marshall Morgan > >Internet Doorway, Inc. (aka NETDOOR) > >> -----Original Message----- >> From: owner-usr-tc@lists.xmission.com >> [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Frank Basso >> Sent: Saturday, June 19, 1999 1:46 AM >> To: usr-tc@lists.xmission.com >> Subject: Re: (usr-tc) T3 mux vs. T1s >> >> >> If you are using channleized t-1's then you have your answer. Can >> you say Robbed Bit Signalling ? >> >> ---------- Original Message ---------------------------------- >> From: "Russ Miescke" <russm@powerweb.net> >> Reply-To: usr-tc@lists.xmission.com >> Date: Fri, 18 Jun 1999 23:22:46 -0500 >> >> >We recently changed to a T3 mux from individual T1s for our dial-up trunks. >> >Since then we have noticed that our disconnect rates for users has tripled. >> >Everything is set fine on the mux, and Ameritech says the trunks (both t1 >> >and t3) look clean. The error log on the mux tends to back them up. I use >> >mostly hyper dsps but still have a few Netserver boxes with quads. Anyone >> >have this problem before? Is their any known issues or special settings to >> >do on the hyperarcs or Netservers? >> > >> >Russ Miescke >> >Power Web Connect > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message.
Subject: Re: (usr-tc) jitter attenuation
From: Aaron Nabil <nabil@spiritone.com>
Date: 1999-06-19 00:34:59
Mike Andrews writes... >What are the consequences of having jitter attenuation set wrong on a T1? >Slightly more bipolar violations/frame errors/etc than usual? Something >worse? I've had it set on "transmitter" for a long time now, but some >messages I ran across on this list a while ago (while cleaning out my >mailbox today) suggested that the default was wrong on DSP's at one >point... so I'm trying to figure out which is best, or if it's telco >specific or something. Yes, that was me. The default was wrong, (should be rx) but has been fixed in the TCS 3.5 release (remember to reset the NVRAM from default after you upgrade). It's not telco specific, it's a function of the fact that it's looped timed. Other than bugging the heck out of me, the effect should be negligible except under very degraded timing conditions, like running thru several plesiosynchronus devices (like M31 muxes). -- Aaron Nabil
Subject: RE: (usr-tc) T3 mux vs. T1s
From: Marshall Morgan <marshall@netdoor.com>
Date: 1999-06-19 01:23:04
Hey Frank, in 1998 you said something a little different: ========================================== We are using the 3COM Accessbuilder 6200. It supports multiple DS-3's and is a GREAT Unit for provisioning your links. Check it out. Frank Basso Network Administrator The Internet Connection, Inc. DBA. Got.Net? ========================================== Russ, there was an issue with certain t3 mux's and hiperdsp modems (specific code versions) but I cannot seem to remember the subject or find it in the 3kb. I would ask one of our faithful 3com reps on the list. We have both PRI and CT1 circuits and the disconnect rates are not appreciably different nor has the data presented by our old guru David formerly from ANS agree with Frank's statement. Marshall Morgan Internet Doorway, Inc. (aka NETDOOR) > -----Original Message----- > From: owner-usr-tc@lists.xmission.com > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Frank Basso > Sent: Saturday, June 19, 1999 1:46 AM > To: usr-tc@lists.xmission.com > Subject: Re: (usr-tc) T3 mux vs. T1s > > > If you are using channleized t-1's then you have your answer. Can > you say Robbed Bit Signalling ? > > ---------- Original Message ---------------------------------- > From: "Russ Miescke" <russm@powerweb.net> > Reply-To: usr-tc@lists.xmission.com > Date: Fri, 18 Jun 1999 23:22:46 -0500 > > >We recently changed to a T3 mux from individual T1s for our dial-up trunks. > >Since then we have noticed that our disconnect rates for users has tripled. > >Everything is set fine on the mux, and Ameritech says the trunks (both t1 > >and t3) look clean. The error log on the mux tends to back them up. I use > >mostly hyper dsps but still have a few Netserver boxes with quads. Anyone > >have this problem before? Is their any known issues or special settings to > >do on the hyperarcs or Netservers? > > > >Russ Miescke > >Power Web Connect
Subject: RE: (usr-tc) T3 mux vs. T1s
From: Marshall Morgan <marshall@netdoor.com>
Date: 1999-06-19 01:23:04
Hey Frank, in 1998 you said something a little different: ========================================== We are using the 3COM Accessbuilder 6200. It supports multiple DS-3's and is a GREAT Unit for provisioning your links. Check it out. Frank Basso Network Administrator The Internet Connection, Inc. DBA. Got.Net? ========================================== Russ, there was an issue with certain t3 mux's and hiperdsp modems (specific code versions) but I cannot seem to remember the subject or find it in the 3kb. I would ask one of our faithful 3com reps on the list. We have both PRI and CT1 circuits and the disconnect rates are not appreciably different nor has the data presented by our old guru David formerly from ANS agree with Frank's statement. Marshall Morgan Internet Doorway, Inc. (aka NETDOOR) > -----Original Message----- > From: owner-usr-tc@lists.xmission.com > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Frank Basso > Sent: Saturday, June 19, 1999 1:46 AM > To: usr-tc@lists.xmission.com > Subject: Re: (usr-tc) T3 mux vs. T1s > > > If you are using channleized t-1's then you have your answer. Can > you say Robbed Bit Signalling ? > > ---------- Original Message ---------------------------------- > From: "Russ Miescke" <russm@powerweb.net> > Reply-To: usr-tc@lists.xmission.com > Date: Fri, 18 Jun 1999 23:22:46 -0500 > > >We recently changed to a T3 mux from individual T1s for our dial-up trunks. > >Since then we have noticed that our disconnect rates for users has tripled. > >Everything is set fine on the mux, and Ameritech says the trunks (both t1 > >and t3) look clean. The error log on the mux tends to back them up. I use > >mostly hyper dsps but still have a few Netserver boxes with quads. Anyone > >have this problem before? Is their any known issues or special settings to > >do on the hyperarcs or Netservers? > > > >Russ Miescke > >Power Web Connect
Subject: Re: (usr-tc) T3 mux vs. T1s
From: Ricky Beam <jfbeam@bluetopia.net>
Date: 1999-06-19 02:20:52
On Fri, 18 Jun 1999, Frank Basso wrote: >If you are using channleized t-1's then you have your answer. Can you say Robbed Bit Signalling ? > >---------- Original Message ---------------------------------- >From: "Russ Miescke" <russm@powerweb.net> >Reply-To: usr-tc@lists.xmission.com >Date: Fri, 18 Jun 1999 23:22:46 -0500 > >>We recently changed to a T3 mux from individual T1s for our dial-up trunks. >>Since then we have noticed that our disconnect rates for users has tripled. RBS ain't a problem until something thinks it's got a 64k path end-to-end even tho' it has not been explicitely told so. If it's not digital end-to-end (i.e. a PRI/BRI digital serviced call), then you should never assume you have the entire 64k channel as there could be any number of points using in-band signalling (RBS.) There could be timing problems between the DSP and the telco and the remote modem. Drop a PCM code here and there and all hell insues... What kind of distribution of connect termination reasons are you seeing? I've seen CT1's all over (800 service almost always is) and never seen any problems. (Ok, so I did in one idiot case where BTI sold us a "PRI" for 800 access... all they did was trunk a CT1 into a PRI. Brilliant! Also 99% unusable -- I could dial the digital switch directly and it worked fine.) I'll also add the DSP card could be dropping calls for perceived signal errors -- e.g. it failed to see a PCM code here and there. This might be reported as any number of disconnect reasons. (There is, of course, no proof this happens (or doesn't.)) [The HDSP is much more powerful, but it also has 40x more to do.] --Ricky
Subject: Re: (usr-tc) T3 mux vs. T1s
From: Ricky Beam <jfbeam@bluetopia.net>
Date: 1999-06-19 02:20:52
On Fri, 18 Jun 1999, Frank Basso wrote: >If you are using channleized t-1's then you have your answer. Can you say Robbed Bit Signalling ? > >---------- Original Message ---------------------------------- >From: "Russ Miescke" <russm@powerweb.net> >Reply-To: usr-tc@lists.xmission.com >Date: Fri, 18 Jun 1999 23:22:46 -0500 > >>We recently changed to a T3 mux from individual T1s for our dial-up trunks. >>Since then we have noticed that our disconnect rates for users has tripled. RBS ain't a problem until something thinks it's got a 64k path end-to-end even tho' it has not been explicitely told so. If it's not digital end-to-end (i.e. a PRI/BRI digital serviced call), then you should never assume you have the entire 64k channel as there could be any number of points using in-band signalling (RBS.) There could be timing problems between the DSP and the telco and the remote modem. Drop a PCM code here and there and all hell insues... What kind of distribution of connect termination reasons are you seeing? I've seen CT1's all over (800 service almost always is) and never seen any problems. (Ok, so I did in one idiot case where BTI sold us a "PRI" for 800 access... all they did was trunk a CT1 into a PRI. Brilliant! Also 99% unusable -- I could dial the digital switch directly and it worked fine.) I'll also add the DSP card could be dropping calls for perceived signal errors -- e.g. it failed to see a PCM code here and there. This might be reported as any number of disconnect reasons. (There is, of course, no proof this happens (or doesn't.)) [The HDSP is much more powerful, but it also has 40x more to do.] --Ricky
Subject: Re: (usr-tc) T3 mux vs. T1s
From: Russ Miescke <russm@powerweb.net>
Date: 1999-06-19 03:03:58
Most disconnect reasons are mainly normal. The people that can't connect, get no carrier reasons for call failure. If it is any help, we are using a Telco Systems mux. We are using channleized T1's in the high failure areas. I have the latest code loaded on all hyperdsps. Is there any settings that will make the modem connections more stable? Russ Miescke Power Web Connect ----- Original Message ----- Sent: Saturday, June 19, 1999 1:20 AM > On Fri, 18 Jun 1999, Frank Basso wrote: > >If you are using channleized t-1's then you have your answer. Can you say Robbed Bit Signalling ? > > > >---------- Original Message ---------------------------------- > >From: "Russ Miescke" <russm@powerweb.net> > >Reply-To: usr-tc@lists.xmission.com > >Date: Fri, 18 Jun 1999 23:22:46 -0500 > > > >>We recently changed to a T3 mux from individual T1s for our dial-up trunks. > >>Since then we have noticed that our disconnect rates for users has tripled. > > RBS ain't a problem until something thinks it's got a 64k path end-to-end > even tho' it has not been explicitely told so. If it's not digital > end-to-end (i.e. a PRI/BRI digital serviced call), then you should never > assume you have the entire 64k channel as there could be any number of > points using in-band signalling (RBS.) > > There could be timing problems between the DSP and the telco and the remote > modem. Drop a PCM code here and there and all hell insues... What kind of > distribution of connect termination reasons are you seeing? I've seen CT1's > all over (800 service almost always is) and never seen any problems. (Ok, > so I did in one idiot case where BTI sold us a "PRI" for 800 access... all > they did was trunk a CT1 into a PRI. Brilliant! Also 99% unusable -- I > could dial the digital switch directly and it worked fine.) > > I'll also add the DSP card could be dropping calls for perceived signal > errors -- e.g. it failed to see a PCM code here and there. This might be > reported as any number of disconnect reasons. (There is, of course, no > proof this happens (or doesn't.)) [The HDSP is much more powerful, but it > also has 40x more to do.] > > --Ricky > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >
Subject: Re: (usr-tc) Merit Radius
From: Ricky Beam <jfbeam@bluetopia.net>
Date: 1999-06-20 07:35:49
On Sun, 20 Jun 1999, Peter Evans wrote: >> Wed Jun 16 14:32:09 1999: generate26: USR attribute 0 unknown >> Wed Jun 16 14:32:09 1999: gen_valpairs: non-encapsulated vendor specific >> attribute Vendor-Specific=vUSR-0000902300000015 > > This is caused by USR/3com not putting in a (IMHO redundant) > length field as per the RFC in question. I had this problem > a while back. Actually, strictly speaking, USR didn't break the RFC. It's "vendor specific" which means they can put what ever they want to in there. RFC suggests putting a standard attribute within the data of the vendor specific attribute. You'll notice their vendor attribute numbers are 16 bit -- and left space for full 32 bit numbers. (They don't need to specify a size as everything after the attribute number is data.) --Ricky
Subject: Re: (usr-tc) Merit Radius
From: Peter Evans <peter@gol.com>
Date: 1999-06-20 18:22:35
Marcelo Souza (mpsouza@centroin.com.br) wrote: > I'm trying to use Merit AAA Basic server with my ARC TC, but the > logfile shows me: > Wed Jun 16 14:32:09 1999: generate26: USR attribute 0 unknown > Wed Jun 16 14:32:09 1999: gen_valpairs: non-encapsulated vendor specific > attribute Vendor-Specific=vUSR-0000902300000015 This is caused by USR/3com not putting in a (IMHO redundant) length field as per the RFC in question. I had this problem a while back. This lame-o fix is from radius 2.1b6 in radiusd.c Its called DICT_FIX, because it was part of the code I modified to make it accept the USR VSA stuff's hex field numbers. Peter ----+ (you need a portmaster to be "licensed" to use their radius.) if (pair->attribute == PW_VENDOR) { #ifndef DICT_FIX if (attrlen < 6 || ((vsattrlen = *(ptr+5)) != (attrlen-4))) { # else if (attrlen < 6 ) { /* doesnt look like livinston stuff and usr stuff speak the same * language */ #endif /* DICT_FIX */ pair->vendor = 0; pair->vsattribute = 0; pair->type = PW_TYPE_STRING; } else { memcpy(&vendor, ptr, sizeof(UINT4)); vendor = ntohl(vendor); ptr += 4; #ifndef DICT_FIX vsa = *ptr++; attrlen = vsattrlen - 2; ptr++; length -= 6; #else memcpy(&vsa, ptr, sizeof(UINT4)); vsa = ntohl(vsa); ptr += 4; attrlen -= 8; length -= 8; #endif /* DICT_FIX */ pair->vendor = vendor; pair->vsattribute = vsa;
Subject: (usr-tc) Dicitonary file problem
From: Grzegorz . Paszka <pashen@pik-net.pl>
Date: 1999-06-21 00:28:33
Hi. I've enabled sending traps from Dual PRI Card to my log server. My log server is Cistron Radius on Linux box. IMHO it doesn't matter that is Cistron and Linux. My problem rather concern dictionary file and TCH box. It's part of debug output generated by radiusd: Sending Accounting Ack of id 246 to c352b006 (nas netserv) radrecv: Request from host c352b007 code=4, id=173, length=229 NAS-IP-Address = xxx.xxx.xxx.xxx NAS-Port-Id = 1 Acct-Delay-Time = 44 Acct-Session-Id = "1205" USR-Event-Id = 81 USR-Event-Date-Time (Unknown Type 3) USR-Chassis-Slot = 1 USR-Channel = 1 USR-Call-Event-Code = 30 USR-DS0 = 28 USR-Device-Connected-To = 4 USR-Slot-Connected-To = 5 USR-Channel-Connected-To = 1 USR-Last-Number-Dialed-In-DNIS = "00" Received unknown attribute 179794 Received unknown attribute 179791 Accounting: no Accounting-Status-Type record. [cut] Acct-Delay-Time = 113360 Acct-Session-Id = "1173" USR-Event-Id = 84 USR-Event-Date-Time (Unknown Type 3) USR-Chassis-Slot = 1 USR-Channel = 1 USR-Call-Event-Code = noFreeIGW USR-DS0 = 23 Received unknown attribute 179794 Received unknown attribute 179792 Received unknown attribute 179791 Accounting: no Accounting-Status-Type record. What do values 81 and 84 mean for Event-Id ? What does value 30 mean for Call-Event-Code ? What does value 4 mean for Device-Connected-To ? And attributes 179791, 179792 and 179794 ? I thing that why i get in my radius.log file multitude annoying messages : Accounting: no Accounting-Status-Type record. Help me plz. Regards -- Grzegorz Paszka, System Administrator, Gliwice ul. Toszecka 102 e-mail: Grzegorz.Paszka@pik-net.pl tel. 48-32-2799600 wew 333
Subject: (usr-tc) Today's fun with TC's: DSP that before being rebooted wasn't havi
From: Scott Trautman <scottt@corp.gdinet.com>
Date: 1999-06-21 16:20:31
Nothing else changed. Users with HCF modems get a long tone and never connect. All that was done was entire unit was power cycled. All other calls fine on same DSP; only problem is with HCF modems. Like the bad old days. No connection at all. Running 2.0.81; was on 2.0.81 for last couple weeks. Any ideas? By the by, it seems like about 50% of the time I reboot TC equipment something very wrong happens. Won't boot. Won't see cards. Needs cards pulled out and put back in. Lose their minds. Lose their OS. Your experiences? I'm just glad my computers aren't as fragile. SMT Scott M. Trautman 800-482-4638 Global Dialog Internet 608-240-4638,4637fax 2810 Crossroads, STE LL2 scott@gdinet.com Madison WI 53718 http://www.gdinet.com
Subject: (usr-tc) 1.2.37 ISDN wierdness
From: Brian <signal@shreve.net>
Date: 1999-06-21 16:58:25
Since upgrading to 1.2.37 (from 1.2.43), I am having problems with a P50 keeping dual channel connections. Even single channel doens't last for too long (~1-2hours). P50 code is 6.0.10 (which I'll try updating). no Link Comp is being used. Does anyone know of any issues? Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)
Subject: Re: (usr-tc) obscure MIB variables
From: Mike Andrews <mandrews@termfrost.org>
Date: 1999-06-21 18:01:29
On Fri, 18 Jun 1999, Jeff Mcadams wrote: > Thus spake Mike Andrews > >How does one decode the information in mdmCsTrainingInfo and > >mdmCsX2signature -- or for the TCM people, "Training Info" and "x2 > >Signature" under the Performance Monitor? Is there anything useful for > >debugging x2/v.90 connections in there? > > Haven't a clue on these...You're definitely ahead of me in using SNMP > MIBS (though I am catching up! :) Heh. :) Anyone from 3Com? (John Powell, perhaps?) > >Also in Performance Monitor, how do you get the Remote Modem Management to > >do anything useful? Does it only work when the remote modem is another > >Total Control (or perhaps Courier) modem? > > You don't yet...it will be a feature in the Couriers...but it isn't > there yet from what I've been told. I guess you might get info if > there's another TC at the other end, but that doesn't exactly happen all > too often. :) Hm. I'll have to experiment with my Courier later and see. It sure would be nice if you could figure out what brand of modem was at the other end of a connection -- that's kinda what I was hoping for. Anyone at 3Com care to shed more light on the Remote Modem MIB? (Random thought: maybe there's some vendor flag in the v.8 or v.42 handshakes that could be used to tell what's at the other end -- if so, it'd be nice if there was a way to retrieve that information... on either a client or a server modem. The last ITU-T stuff I read was a bit dense for my brain to parse...) Mike Andrews (MA12) -=-=- VP & Sysadmin, Digital Crescent, Frankfort KY mandrews@dcr.net -=- mandrews@termfrost.org -=- http://www.termfrost.org "If Yoda so strong in Force is, why words in right order he cannot put?"
Subject: Re: (usr-tc) Today's fun with TC's: DSP that before being rebooted
From: Mike Andrews <mandrews@termfrost.org>
Date: 1999-06-21 18:20:21
On Mon, 21 Jun 1999, Scott Trautman wrote: > Nothing else changed. > Users with HCF modems get a long tone and never connect. > > All that was done was entire unit was power cycled. All other calls fine on > same DSP; > only problem is with HCF modems. Like the bad old days. No connection at > all. > > Running 2.0.81; was on 2.0.81 for last couple weeks. > > Any ideas? Probably a setting got whacked somewhere, but hell if I could guess which one. :) Maybe check your T1 settings? (especially if you're not using PRI) > By the by, it seems like about 50% of the time I reboot TC equipment > something very wrong happens. > Won't boot. Won't see cards. Needs cards pulled out and put back in. Lose > their minds. Lose their > OS. Your experiences? I'm just glad my computers aren't as fragile. Yup. This is why I just gave up and wrote a program to sweep through the whole chassis and verify every parameter on every card once a week. The other alternative was going through every group of settings on every card one-by-one in TCM -- waaaay too tedious for me. It's worst on the DSP's, because of the whole profiles thing -- it's really hard to know what settings to change where and what to save to where -- do I set it in the profile, on the individual modem, do I need to refresh to channels, etc etc... took forever for me to find the right magical incantation to get things to stick, and even now I'm not 100% sure I got it right. (The order I use: check T1 settings, check profile settings, save profiles, refresh profile 1 to channels, check per-channel settings, save each channel, refresh profile 1 to channels again, save T1 settings.) Aside from DSP's, the NMC almost always forgets some of its SNMP trap and logging settings, and things stop getting logged that used to be logged. Dual PRI's, ARCs, and NETservers are pretty good about not forgetting their settings. At least I haven't had much in the way of hardware failure, save one dead NMC and one Quad with constant "DSP interrupt timeout" connect failures on the first channel.... Mike Andrews (MA12) -=-=- VP & Sysadmin, Digital Crescent, Frankfort KY mandrews@dcr.net -=- mandrews@termfrost.org -=- http://www.termfrost.org "If Yoda so strong in Force is, why words in right order he cannot put?"
Subject: Re: (usr-tc) obscure MIB variables
From: Steve Valiunas <steve_valiunas@mw.3com.com>
Date: 1999-06-21 21:35:23
You might want to take a look at the HiperNMC Parameter reference and the HiperNMC SNMP and MIB reference (Part No. 1.024.1000-03 and 1.024.1661-00). You'll find them under the NMC if you search totalservice for TCS3.5. They don't explain x2 signature or training info though. Steve Paul Farber <farber@admin.f-tech.net> on 06/22/99 05:58:20 AM Please respond to usr-tc@lists.xmission.com Sent by: Paul Farber <farber@admin.f-tech.net> cc: (Steve Valiunas/MW/US/3Com) Actually.. a document that would shed some light on ANY of the MIBS in the modem tree would be helpfull. All the trap information I am collecting on failed connects is pretty useless with knowing what enterprises.usr.nas.mdm.mdmCs.mdmCsTable.mdmCsEntry.mdmCsConnectFailReason.1 = 0 means.... every one of the call failures record this as the MIB value. Right now I'm just going off the span/channel to see if its a random occurance or a pattern. Paul D. Farber II Farber Technology Ph. 570-628-5303 Fax 570-628-5545 farber@admin.f-tech.net On Mon, 21 Jun 1999, Mike Andrews wrote: > On Fri, 18 Jun 1999, Jeff Mcadams wrote: > > > Thus spake Mike Andrews > > >How does one decode the information in mdmCsTrainingInfo and > > >mdmCsX2signature -- or for the TCM people, "Training Info" and "x2 > > >Signature" under the Performance Monitor? Is there anything useful for > > >debugging x2/v.90 connections in there? > > > > Haven't a clue on these...You're definitely ahead of me in using SNMP > > MIBS (though I am catching up! :) > > Heh. :) > > Anyone from 3Com? (John Powell, perhaps?) > > > > >Also in Performance Monitor, how do you get the Remote Modem Management to > > >do anything useful? Does it only work when the remote modem is another > > >Total Control (or perhaps Courier) modem? > > > > You don't yet...it will be a feature in the Couriers...but it isn't > > there yet from what I've been told. I guess you might get info if > > there's another TC at the other end, but that doesn't exactly happen all > > too often. :) > > Hm. I'll have to experiment with my Courier later and see. It sure would > be nice if you could figure out what brand of modem was at the other end > of a connection -- that's kinda what I was hoping for. > > Anyone at 3Com care to shed more light on the Remote Modem MIB? > > (Random thought: maybe there's some vendor flag in the v.8 or v.42 > handshakes that could be used to tell what's at the other end -- if so, > it'd be nice if there was a way to retrieve that information... on either > a client or a server modem. The last ITU-T stuff I read was a bit dense > for my brain to parse...) > > > Mike Andrews (MA12) -=-=- VP & Sysadmin, Digital Crescent, Frankfort KY > mandrews@dcr.net -=- mandrews@termfrost.org -=- http://www.termfrost.org > "If Yoda so strong in Force is, why words in right order he cannot put?" > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.
Subject: Re: (usr-tc) obscure MIB variables
From: Paul Farber <farber@admin.f-tech.net>
Date: 1999-06-22 06:58:20
Actually.. a document that would shed some light on ANY of the MIBS in the modem tree would be helpfull. All the trap information I am collecting on failed connects is pretty useless with knowing what enterprises.usr.nas.mdm.mdmCs.mdmCsTable.mdmCsEntry.mdmCsConnectFailReason.1 = 0 means.... every one of the call failures record this as the MIB value. Right now I'm just going off the span/channel to see if its a random occurance or a pattern. Paul D. Farber II Farber Technology Ph. 570-628-5303 Fax 570-628-5545 farber@admin.f-tech.net On Mon, 21 Jun 1999, Mike Andrews wrote: > On Fri, 18 Jun 1999, Jeff Mcadams wrote: > > > Thus spake Mike Andrews > > >How does one decode the information in mdmCsTrainingInfo and > > >mdmCsX2signature -- or for the TCM people, "Training Info" and "x2 > > >Signature" under the Performance Monitor? Is there anything useful for > > >debugging x2/v.90 connections in there? > > > > Haven't a clue on these...You're definitely ahead of me in using SNMP > > MIBS (though I am catching up! :) > > Heh. :) > > Anyone from 3Com? (John Powell, perhaps?) > > > > >Also in Performance Monitor, how do you get the Remote Modem Management to > > >do anything useful? Does it only work when the remote modem is another > > >Total Control (or perhaps Courier) modem? > > > > You don't yet...it will be a feature in the Couriers...but it isn't > > there yet from what I've been told. I guess you might get info if > > there's another TC at the other end, but that doesn't exactly happen all > > too often. :) > > Hm. I'll have to experiment with my Courier later and see. It sure would > be nice if you could figure out what brand of modem was at the other end > of a connection -- that's kinda what I was hoping for. > > Anyone at 3Com care to shed more light on the Remote Modem MIB? > > (Random thought: maybe there's some vendor flag in the v.8 or v.42 > handshakes that could be used to tell what's at the other end -- if so, > it'd be nice if there was a way to retrieve that information... on either > a client or a server modem. The last ITU-T stuff I read was a bit dense > for my brain to parse...) > > > Mike Andrews (MA12) -=-=- VP & Sysadmin, Digital Crescent, Frankfort KY > mandrews@dcr.net -=- mandrews@termfrost.org -=- http://www.termfrost.org > "If Yoda so strong in Force is, why words in right order he cannot put?" > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >
Subject: (usr-tc) RADIUS maintaining pools for NetServers
From: Kevin Benton <s1kevin@tims.net>
Date: 1999-06-22 09:55:18
I am trying to figure out how to tell our RADIUS person how to change 3Com's RADIUS databases to begin doing pool management for NetServers. We're trying to implement VPN addresses for customers in multiple cities with multiple TC platforms (both NSC and HARC) and the NSC's are creating a real challenge. Obviously the HARC's are a breeze. Should we consider changing to a different RADIUS server? If so, which one? Kevin Benton Sr. Network Engineer SOTA Technologies E-Mail: s1kevin@tims.net Web: http://users.sota-oh.com/~s1kevin/ Unsolicited advertisements processing fee: $50 subject to change without notice
Subject: Re: (usr-tc) RADIUS maintaining pools for NetServers
From: Ricky Beam <jfbeam@bluetopia.net>
Date: 1999-06-22 10:26:39
On Tue, 22 Jun 1999, Kevin Benton wrote: >I am trying to figure out how to tell our RADIUS person how to change >3Com's RADIUS databases to begin doing pool management for NetServers. >We're trying to implement VPN addresses for customers in multiple cities >with multiple TC platforms (both NSC and HARC) and the NSC's are creating >a real challenge. Obviously the HARC's are a breeze. Should we consider >changing to a different RADIUS server? If so, which one? The netserver can do local IP address pooling just as well as the HARC. (as far as RADIUS is involved, identically.) --Ricky
Subject: (usr-tc) 2 channels
From: Brian <signal@shreve.net>
Date: 1999-06-22 15:13:58
To allow 2 channel logins (bonding) in TCS 3.3, all that is needed is Max-Channels = 2 right? Brian Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)
Subject: RE: (usr-tc) 2 channels
From: Marshall Morgan <marshall@netdoor.com>
Date: 1999-06-22 15:34:06
The Port-Limit Attribute does not work on the ARC but the Max-Channels does. Marshall Morgan Internet Doorway, Inc. (aka NETDOOR) > -----Original Message----- > From: owner-usr-tc@lists.xmission.com > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Jeff Mcadams > Sent: Tuesday, June 22, 1999 3:21 PM > To: usr-tc@lists.xmission.com > Subject: Re: (usr-tc) 2 channels > > > Thus spake Brian > >To allow 2 channel logins (bonding) in TCS 3.3, all that is needed is > >Max-Channels = 2 right? > > Max-Channels is non-standard, use Port-Limit. > -- > Jeff McAdams Email: jeffm@iglou.com > Head Network Administrator Voice: (502) 966-3848 > IgLou Internet Services (800) 436-4456 > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > >
Subject: RE: (usr-tc) radius attribute for connect speed
From: Marshall Morgan <marshall@netdoor.com>
Date: 1999-06-22 15:35:04
VSA USR Connect-Speed 0x9023 integer VALUE Connect-Speed NONE 1 VALUE Connect-Speed 300-BPS 2 VALUE Connect-Speed 1200-BPS 3 VALUE Connect-Speed 2400-BPS 4 VALUE Connect-Speed 4800-BPS 5 VALUE Connect-Speed 7200-BPS 6 VALUE Connect-Speed 9600-BPS 7 VALUE Connect-Speed 12000-BPS 8 VALUE Connect-Speed 14400-BPS 9 VALUE Connect-Speed 16800-BPS 10 VALUE Connect-Speed 19200-BPS 11 VALUE Connect-Speed 21600-BPS 12 VALUE Connect-Speed 28800-BPS 13 VALUE Connect-Speed 38400-BPS 14 VALUE Connect-Speed 57600-BPS 15 VALUE Connect-Speed 115200-BPS 16 VALUE Connect-Speed 288000-BPS 17 VALUE Connect-Speed 75-1200-BPS 18 VALUE Connect-Speed 1200-75-BPS 19 VALUE Connect-Speed 24000-BPS 20 VALUE Connect-Speed 26400-BPS 21 VALUE Connect-Speed 31200-BPS 22 VALUE Connect-Speed 33600-BPS 23 VALUE Connect-Speed 33333-BPS 24 VALUE Connect-Speed 37333-BPS 25 VALUE Connect-Speed 41333-BPS 26 VALUE Connect-Speed 42666-BPS 27 VALUE Connect-Speed 44000-BPS 28 VALUE Connect-Speed 45333-BPS 29 VALUE Connect-Speed 46666-BPS 30 VALUE Connect-Speed 48000-BPS 31 VALUE Connect-Speed 49333-BPS 32 VALUE Connect-Speed 50666-BPS 33 VALUE Connect-Speed 52000-BPS 34 VALUE Connect-Speed 53333-BPS 35 VALUE Connect-Speed 54666-BPS 36 VALUE Connect-Speed 56000-BPS 37 VALUE Connect-Speed 57333-BPS 38 VALUE Connect-Speed 64000-BPS 39 VALUE Connect-Speed 25333-BPS 40 VALUE Connect-Speed 26666-BPS 41 VALUE Connect-Speed 28000-BPS 42 VALUE Connect-Speed 29333-BPS 43 VALUE Connect-Speed 30666-BPS 44 VALUE Connect-Speed 32000-BPS 45 VALUE Connect-Speed 34666-BPS 46 VALUE Connect-Speed 36000-BPS 47 VALUE Connect-Speed 38666-BPS 48 VALUE Connect-Speed 40000-BPS 49 VALUE Connect-Speed 58666-BPS 50 VALUE Connect-Speed 60000-BPS 51 VALUE Connect-Speed 61333-BPS 52 VALUE Connect-Speed 62666-BPS 53 Marshall Morgan Internet Doorway, Inc. (aka NETDOOR) > -----Original Message----- > From: owner-usr-tc@lists.xmission.com > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Scott Boggs > Sent: Tuesday, June 22, 1999 3:18 PM > To: USRobotics TC Mailing List > Subject: (usr-tc) radius attribute for connect speed > > > Does any one know of a radius accounting attribute that will return > the connection speed in bps or something similar. > Using ARC 4.1.59-6. > > by the way , is there another ARC radius reference other that the > ARC user guide. It is not so clear about some VSA things. > > Thanks, > Scott Boggs > AccessUnited Internet > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > >
Subject: Re: (usr-tc) 2 channels
From: Brian <signal@shreve.net>
Date: 1999-06-22 15:58:00
On Tue, 22 Jun 1999, Jeff Mcadams wrote: > Thus spake Brian > >To allow 2 channel logins (bonding) in TCS 3.3, all that is needed is > >Max-Channels = 2 right? > > Max-Channels is non-standard, use Port-Limit. I remember before that when using Port-Limit it gave problems, perhaps this is corrected now? For example two scenerios: 1. I have a customer that has an account they need 5 logins on. Should I use Max-Channels or Port-Limit? or both? 2. Customer wants to bond channels, usually 2. You are saying Port-Limit, or should I use both? > -- > Jeff McAdams Email: jeffm@iglou.com > Head Network Administrator Voice: (502) 966-3848 > IgLou Internet Services (800) 436-4456 > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)
Subject: RE: (usr-tc) 2 channels
From: Brian <signal@shreve.net>
Date: 1999-06-22 15:58:56
On Tue, 22 Jun 1999, Marshall Morgan wrote: > The Port-Limit Attribute does not work on the ARC but the Max-Channels does. That's what I saw from the past. The thing is, is ever since upgrading to 1.2.37 we are seeing problems with isdn dual channel bonding, not just mpip either. > > Marshall Morgan > > Internet Doorway, Inc. (aka NETDOOR) > > > -----Original Message----- > > From: owner-usr-tc@lists.xmission.com > > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Jeff Mcadams > > Sent: Tuesday, June 22, 1999 3:21 PM > > To: usr-tc@lists.xmission.com > > Subject: Re: (usr-tc) 2 channels > > > > > > Thus spake Brian > > >To allow 2 channel logins (bonding) in TCS 3.3, all that is needed is > > >Max-Channels = 2 right? > > > > Max-Channels is non-standard, use Port-Limit. > > -- > > Jeff McAdams Email: jeffm@iglou.com > > Head Network Administrator Voice: (502) 966-3848 > > IgLou Internet Services (800) 436-4456 > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)
Subject: (usr-tc) radius attribute for connect speed
From: Scott Boggs <sboggs@unitedbank.net>
Date: 1999-06-22 16:18:16
Does any one know of a radius accounting attribute that will return the connection speed in bps or something similar. Using ARC 4.1.59-6. by the way , is there another ARC radius reference other that the ARC user guide. It is not so clear about some VSA things. Thanks, Scott Boggs AccessUnited Internet
Subject: Re: (usr-tc) 2 channels
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1999-06-22 16:20:56
Thus spake Brian >To allow 2 channel logins (bonding) in TCS 3.3, all that is needed is >Max-Channels = 2 right? Max-Channels is non-standard, use Port-Limit. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456
Subject: Re: (usr-tc) 2 channels
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1999-06-22 17:46:45
Thus spake Brian >On Tue, 22 Jun 1999, Marshall Morgan wrote: >> The Port-Limit Attribute does not work on the ARC but the Max-Channels does. >That's what I saw from the past. The thing is, is ever since upgrading to >1.2.37 we are seeing problems with isdn dual channel bonding, not just >mpip either. The DSP really doesn't have anything to do with PPP, multi-link or otherwise, other than possibly doing the framing if you have offloading enabled. MultiLink bundling (bonding is an old, no longer supported protocol) really is completely handled by the Arc. At some point in the past (perhaps in early 4.1.x code) Max-Channels was required to limit the number of links allowed in an MP bundle. That was fixed at some point along the way so that the attribute used was Port-Limit. I believe Max-Channels still works for that, but I'd suggest not using it. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456
Subject: Re: (usr-tc) 2 channels
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1999-06-22 17:48:06
Thus spake Brian >On Tue, 22 Jun 1999, Jeff Mcadams wrote: >> Thus spake Brian >> >To allow 2 channel logins (bonding) in TCS 3.3, all that is needed >> >is Max-Channels = 2 right? >> >> Max-Channels is non-standard, use Port-Limit. >I remember before that when using Port-Limit it gave problems, perhaps >this is corrected now? >For example two scenerios: >1. I have a customer that has an account they need 5 logins on. Should >I use Max-Channels or Port-Limit? or both? Simultaneous-Use in your RADIUS server...most likely backed up with some SNMP polling or something or other along those lines. >2. Customer wants to bond channels, usually 2. You are saying >Port-Limit, or should I use both? Port-Limit...Max-Channels may work for this, but if you have reasonably recent Arc code, Port-Limit will work and is the one you really want to use. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456
Subject: Re: (usr-tc) 2 channels
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1999-06-22 17:49:15
Thus spake Marshall Morgan >The Port-Limit Attribute does not work on the ARC but the Max-Channels >does. Works in 4.1.59-6 at least. I believe at some point in the past, it was a requirement to use Max-Channels, but like I said...that's non-standard, so you'll almost assuredly want to move away from that as soon as possible as I don't believe there is any committment to continue supporting that in future Arc code versions. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456
Subject: RE: (usr-tc) radius attribute for connect speed
From: Stephen Amadei <amadei@dandy.net>
Date: 1999-06-22 18:07:42
On Tue, 22 Jun 1999, Marshall Morgan wrote: > VALUE Connect-Speed 58666-BPS 50 I'm so glad this came up. I was helping a customer, watching our Radius servers the other day when I got one of these. I thought it was a typo, but double checking the dictionary, and source code shows it's not. I wasn't able to double check the speed with the Performance Monitor, but it definately came up on RADIUS as 58666. Anyone care to explain how this is possible? It's an modem customer and it's obviously over both the 53.333K and 56K limits. By the way, why are X2 and V.90 speeds defined for 56-64K? ----Steve Stephen Amadei Director of MIS Dandy Connections, Inc. Atlantic City, NJ
Subject: Re: (usr-tc) 2 channels
From: Brian <signal@shreve.net>
Date: 1999-06-22 18:14:51
On Tue, 22 Jun 1999, Jeff Mcadams wrote: > Thus spake Brian > >On Tue, 22 Jun 1999, Marshall Morgan wrote: > >> The Port-Limit Attribute does not work on the ARC but the Max-Channels does. > > >That's what I saw from the past. The thing is, is ever since upgrading to > >1.2.37 we are seeing problems with isdn dual channel bonding, not just > >mpip either. > > The DSP really doesn't have anything to do with PPP, multi-link or > otherwise, other than possibly doing the framing if you have offloading > enabled. MultiLink bundling (bonding is an old, no longer supported > protocol) really is completely handled by the Arc. Well you know, maybe its not a multi-link problem. It looks like it might just be *all* isdn. It just looked like a multi-link problem, because I was noticing second channels not connected. > > At some point in the past (perhaps in early 4.1.x code) Max-Channels was > required to limit the number of links allowed in an MP bundle. That was > fixed at some point along the way so that the attribute used was > Port-Limit. I believe Max-Channels still works for that, but I'd > suggest not using it. So basically your saying Port-Limit should work in the last tcs3.3 arc code releases? > -- > Jeff McAdams Email: jeffm@iglou.com > Head Network Administrator Voice: (502) 966-3848 > IgLou Internet Services (800) 436-4456 > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)
Subject: Re: (usr-tc) 2 channels
From: Brian <signal@shreve.net>
Date: 1999-06-22 18:16:22
> > Simultaneous-Use in your RADIUS server...most likely backed up with some > SNMP polling or something or other along those lines. I use pmmon to limit that, I just don't want an arc that gets two of the same usersnames on it to deny access. > > >2. Customer wants to bond channels, usually 2. You are saying > >Port-Limit, or should I use both? > > Port-Limit...Max-Channels may work for this, but if you have reasonably > recent Arc code, Port-Limit will work and is the one you really want to > use. ok thanks > -- > Jeff McAdams Email: jeffm@iglou.com > Head Network Administrator Voice: (502) 966-3848 > IgLou Internet Services (800) 436-4456 > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)
Subject: Re: (usr-tc) 2 channels
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1999-06-22 19:42:37
Thus spake Brian >Well you know, maybe its not a multi-link problem. It looks like it might >just be *all* isdn. It just looked like a multi-link problem, because I >was noticing second channels not connected. OK...that's quite possible. :) Haven't played with 1.2.37 myself, so can't say for sure. :0 >> At some point in the past (perhaps in early 4.1.x code) Max-Channels was >> required to limit the number of links allowed in an MP bundle. That was >> fixed at some point along the way so that the attribute used was >> Port-Limit. I believe Max-Channels still works for that, but I'd >> suggest not using it. >So basically your saying Port-Limit should work in the last tcs3.3 arc >code releases? Yup, I'm using it quite successfully with 4.1.59-6 at least. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456
Subject: Re: (usr-tc) 2 channels
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1999-06-22 19:43:11
Thus spake Brian >> Simultaneous-Use in your RADIUS server...most likely backed up with >> some SNMP polling or something or other along those lines. >I use pmmon to limit that, I just don't want an arc that gets two of >the same usersnames on it to deny access. Nope, Port-Limit won't do that...only limits the number of links in an MP bundle. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456
Subject: RE: (usr-tc) radius attribute for connect speed
From: Mike Andrews <mandrews@termfrost.org>
Date: 1999-06-22 21:11:14
On Tue, 22 Jun 1999, Stephen Amadei wrote: > On Tue, 22 Jun 1999, Marshall Morgan wrote: > > > VALUE Connect-Speed 58666-BPS 50 > > I'm so glad this came up. I was helping a customer, watching our > Radius servers the other day when I got one of these. I thought it > was a typo, but double checking the dictionary, and source code shows > it's not. I wasn't able to double check the speed with the Performance > Monitor, but it definately came up on RADIUS as 58666. > > Anyone care to explain how this is possible? It's an modem customer > and it's obviously over both the 53.333K and 56K limits. > > By the way, why are X2 and V.90 speeds defined for 56-64K? First off, remember 53333 is only a USA limit, which has to do with the transmit power limit (-12dBm I think). Other countries can pump more power down the line, thus faster speeds. In *theory* I guess you could use the whole 64K DS0 but in the real world there's things like robbed-bit T1's and imperfect D/A's that glitch things up. Maybe it's for symmetric mode (which I've never seen work; it's an interesting alternative idea to DOVBS)... maybe it's optimistic thinking... I have an LT Winmodem (w/ 5.4x drivers, not the original garbage ones) connected to a BRI at the office, and I can get 54666 out of it fairly regularly... with the analog part of the line being only 6 feet long, these things can happen. :) I've also seen some client modems connect at 56000, but the BLER rate was so high it was unusable -- I think it was a Rockwell HCF modem with the country code to something besides USA, and it wasn't downshifting correctly. This might have been a DSP bug too that's been fixed; something about buggy client modems telling the server it could accept a 0 dBm signal and the server taking its word for it anyway... Also, if you're on NMC version 5.5.5 and you're running DSP's, be aware there's a BIG off-by-one bug there -- connect speeds, modulation, compression, and a fair chunk of all the other values will be off by one click. That's probably not what you're seeing though, because I thought it reported one click lower, not higher... Mike Andrews (MA12) -=-=- VP & Sysadmin, Digital Crescent, Frankfort KY mandrews@dcr.net -=- mandrews@termfrost.org -=- http://www.termfrost.org "If Yoda so strong in Force is, why words in right order he cannot put?"
Subject: Re: (usr-tc) 2 channels
From: Brian <signal@shreve.net>
Date: 1999-06-22 21:46:46
On Tue, 22 Jun 1999, Jeff Mcadams wrote: > Thus spake Brian > >> Simultaneous-Use in your RADIUS server...most likely backed up with > >> some SNMP polling or something or other along those lines. > > >I use pmmon to limit that, I just don't want an arc that gets two of > >the same usersnames on it to deny access. > > Nope, Port-Limit won't do that...only limits the number of links in an > MP bundle. Ok, thats fine then, Max Channels behaved differently.......sooooo port-limit limits number of links in an mp bundle, basically default is 1, so make this 2 for isdn 128k users. then just leave the rest to pmmon. This is what works for me. Brian > -- > Jeff McAdams Email: jeffm@iglou.com > Head Network Administrator Voice: (502) 966-3848 > IgLou Internet Services (800) 436-4456 > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)
Subject: RE: (usr-tc) 2 channels
From: Marshall Morgan <marshall@netdoor.com>
Date: 1999-06-22 22:43:43
Thanks. Tested it as you mentioned the Port-Limit was working and I agree. Nice to see 3com use the standards approach! Marshall Morgan Internet Doorway, Inc (aka NETDOOR) http://www.netdoor.com > -----Original Message----- > From: owner-usr-tc@lists.xmission.com > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Jeff Mcadams > Sent: Tuesday, June 22, 1999 4:49 PM > To: usr-tc@lists.xmission.com > Subject: Re: (usr-tc) 2 channels > > > Thus spake Marshall Morgan > >The Port-Limit Attribute does not work on the ARC but the Max-Channels > >does. > > Works in 4.1.59-6 at least. I believe at some point in the past, it was > a requirement to use Max-Channels, but like I said...that's > non-standard, so you'll almost assuredly want to move away from that as > soon as possible as I don't believe there is any committment to continue > supporting that in future Arc code versions. > -- > Jeff McAdams Email: jeffm@iglou.com > Head Network Administrator Voice: (502) 966-3848 > IgLou Internet Services (800) 436-4456 > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > >
Subject: (usr-tc) default user
From: Brian <signal@shreve.net>
Date: 1999-06-23 08:28:47
The default user on the ARC has a Max-Channels of 2: PARAMETERS for NETWORK PPP USERS Max Channels 2 Channel Decrement Percent: 0 Channel Expansion Percent: 0 Shouldn't this be 1? I didn't see where one could set port-limit for the default user "on the arc itself", can you? I don't want users to be able to get a 2 channel isdn connection unless they have port-limit = 2. Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)
Subject: (usr-tc) just to clarify (port-limit/max-channels)
From: Brian <signal@shreve.net>
Date: 1999-06-23 08:41:07
If I have a user, and they have no port-limit set, and no max-channels set, then that user will not be restricted by the ARC in any way from dialing in 2, 4, 10 times correct? (simultaneously). And port-limit is just for mp bundles, so even with a port-limit of say 1 set, a user could still have 2, 3, 4, etc seperate unilink sessions correct? and max-channels, from what I can see, basically limits the number of sessions a user can have "per arc", irregardless of MP or not. So if max-channels = 2 is set for a user, and they dial into an ARC, then "that arc" will only allow one more session for that user onto it. I don't beleive their is any inter-arc communication about max-channels and it only applies to the arc the session was established on. Brian Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)
Subject: Re: (usr-tc) Windows 3.1/MacTCP Nightmare
From: vito@aracnet.net
Date: 1999-06-23 08:44:08
So did anyone figure out how to fix the Mac TCP problem?? Vito At 07:08 PM 6/11/99 -0400, Scott Bailey wrote: >2 Weeks ago our Tech. Support queue suddenly, overnight, became saturated >with Windows 3.1 and Mac (MacTCP) customers having trouble. The MacTCP >customers were getting "Broken Pipe" errors. The windows 3.1 customers could >only load a half a page in their browser. After trying a few sites on either >system, > >the computer would lock up completely, and would have to be rebooted. None >of the settings on the client side (believe me we tried everything) made any >difference. Oddly they could get E-mail from our POP Server, and could also >access any Web Servers within our domain, but nothing outside. All our Network >and Systems Personnel insist that NOTHING has changed. > >After a week of Hell we found that upgrading the MAC's to Open Transport >fixed their problem. Our windows 3.1 customers are using a Netscape Dial-Up >Edition that we supply, It uses the Shiva Remote for a Dialer. We found that >the >Shiva Remote that comes with IE 4.0 works, but it will not run on all of our >customers computers. Also the newer Communicator dialer (also a newer Shiva) >works, but will not run on all older 3.1 machines. On the server side we have >tried configuring radius with VJ compression on and off and by making the MTU >smaller and larger. NOTHING!!! > >We have aprox. 15 POP's and use a combination of Hiper ARCs and DSP's >at these exchanges. It does not matter which modems they are dialing in to. >Aprox. 6 weeks ago we replaced all our 3COM routers with Cisco routers, >however, this took place at least 2 weeks before any of this happened. >Our backbone is supplied by Sprintlink and UUnet, they insist NOTHING >has changed. > >If I dial in to a modem (standard External modem) connected to a linux box on >our network, everything works. > >Telling the customer to upgrade to Windows 95/98, or trying to get them to >download alternate programs has just resulted in lost customers. Has anyone >seen anything similar to this? Does it seem like a 3COM issue? Any Ideas? >What changed? Thanks for any input. > >Scott Bailey >Epix Internet Services > > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message.
Subject: Re: (usr-tc) default user
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1999-06-23 09:36:37
Thus spake Brian >The default user on the ARC has a Max-Channels of 2: >PARAMETERS for NETWORK PPP USERS >Max Channels 2 >Channel Decrement Percent: 0 >Channel Expansion Percent: 0 >Shouldn't this be 1? I didn't see where one could set port-limit for the >default user "on the arc itself", can you? >I don't want users to be able to get a 2 channel isdn connection unless >they have port-limit = 2. Hrmm...hadn't realized that the default user had it set to 2 channels...interesting. Of course, we're setting it the DEFAULT user in our RADIUS server, so we're overriding it anyway...interesting to note that though. This setting "Max Channels" for the default user in the Arc is the equivalent of Port-Limit in RADIUS I'm pretty sure. I've never worried about the default user too much since we override most all of the settings in our DEFAULT user in RADIUS. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456
Subject: Re: (usr-tc) just to clarify (port-limit/max-channels)
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1999-06-23 09:55:11
Thus spake Brian >If I have a user, and they have no port-limit set, and no max-channels >set, then that user will not be restricted by the ARC in any way from >dialing in 2, 4, 10 times correct? (simultaneously). I believe that is correct. >And port-limit is just for mp bundles, so even with a port-limit of say >1 set, a user could still have 2, 3, 4, etc seperate unilink sessions >correct? Yup, I believe that is correct as well. >and max-channels, from what I can see, basically limits the number of >sessions a user can have "per arc", irregardless of MP or not. Which basically makes it useless. :) >So if max-channels = 2 is set for a user, and they dial into an ARC, >then "that arc" will only allow one more session for that user onto it. >I don't beleive their is any inter-arc communication about max-channels >and it only applies to the arc the session was established on. There is definitely no inter-arc communication. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456
Subject: (usr-tc) More Max-Channels clarification
From: Brian <signal@shreve.net>
Date: 1999-06-23 10:02:35
So if a user is 2 Channel ISDN, then we would definitly have Port-Limit = 2..................what about Max-Channels, should that be set to 2 also? i would think so......... Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)
Subject: Re: (usr-tc) just to clarify (port-limit/max-channels)
From: Brian <signal@shreve.net>
Date: 1999-06-23 10:04:58
This is totally strange, I hope someone from 3Com comes forward with official clarification. I was not using Port-Limit. I *had* to set Max-Channels > 1 to allow multiple uni link sessions for a user, but I have been doing this so long, that perhap sit is fixed now I don't know. On Wed, 23 Jun 1999, Ricky Beam wrote: > On Wed, 23 Jun 1999, Brian wrote: > >If I have a user, and they have no port-limit set, and no max-channels > >set, then that user will not be restricted by the ARC in any way from > >dialing in 2, 4, 10 times correct? (simultaneously). > > > >And port-limit is just for mp bundles, so even with a port-limit of say 1 > >set, a user could still have 2, 3, 4, etc seperate unilink sessions > >correct? > > > >and max-channels, from what I can see, basically limits the number of > >sessions a user can have "per arc", irregardless of MP or not. So if > >max-channels = 2 is set for a user, and they dial into an ARC, then "that > >arc" will only allow one more session for that user onto it. I don't > >beleive their is any inter-arc communication about max-channels and it > >only applies to the arc the session was established on. > > You've got it backwards... "Port-Limit" limits the number of ports to which > the user is allowed access. If it's set to one (1) then the user can only > login once on any single ARC (or netserver if it pays attention to it.) > Access will be denied at authentication so the user will never get a chance > to bond channels together. (I don't think there is a default anywhere.) > > "Max-Channels" controls the maximum number of channels allow into a single > bundle. There is an ARC "default" user limit that will apply if RADIUS > doesn't set it. This does not limit the number of times any user can > simultaneously login; it only limits the number of logins per bundle -- > they could have more than one bundle. (Yes, you can set it to zero.) > > This information was correct as of ARC 4.2.10 (alpha) [4.1.59?]. That does > not mean the behavior has not been changed. It takes about two (2) minutes > to verify the behavior. (No one is holding a gun to your head stopping you > from trying these two attributes on a single user. To borrow the Nike (tm) > phrase, "Just do it!") > > --Ricky > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)
Subject: Re: (usr-tc) just to clarify (port-limit/max-channels)
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1999-06-23 10:06:46
Thus spake Robert von Bismarck >Uhh... if MPIP is configured, max-channels gets broadcast over to the >second, third or whatever ARC. It is then checked with the Port-Limit >statement gotten from the RADIUS server or the Max-Channels entry in the >DEFAULT user (not sure about the 2nd possibility, but it makes sense ;-) Uhm...not quite...MPIP is *only* for multi-link bundles...and then that's still only controlled by the Arc that handles the bundle head, the Port-Limit value isn't transmitted via MPIP. The way that works is if another link comes in, its tunneled over to the bundle head (which is found via MPIP), and the bundle head can then reject that link from joining the bundle saying that the max number of links (Port-Limit) has been reached...the tunnel is then killed by the bundle head, and when the arc that started the tunnel sees the tunnel get dropped, it drops the call. Max-Channels (the RADIUS attribute) is not conveyed between the Arcs in *any* way...if you get a different login on a different Arc, the Max-Channels RADIUS attribute will in no way stop them from logging in. If its a multi-link connection, its subject to the limitations of the above mechanism. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456
Subject: Re: (usr-tc) just to clarify (port-limit/max-channels)
From: Ricky Beam <jfbeam@bluetopia.net>
Date: 1999-06-23 10:29:14
On Wed, 23 Jun 1999, Brian wrote: >If I have a user, and they have no port-limit set, and no max-channels >set, then that user will not be restricted by the ARC in any way from >dialing in 2, 4, 10 times correct? (simultaneously). > >And port-limit is just for mp bundles, so even with a port-limit of say 1 >set, a user could still have 2, 3, 4, etc seperate unilink sessions >correct? > >and max-channels, from what I can see, basically limits the number of >sessions a user can have "per arc", irregardless of MP or not. So if >max-channels = 2 is set for a user, and they dial into an ARC, then "that >arc" will only allow one more session for that user onto it. I don't >beleive their is any inter-arc communication about max-channels and it >only applies to the arc the session was established on. You've got it backwards... "Port-Limit" limits the number of ports to which the user is allowed access. If it's set to one (1) then the user can only login once on any single ARC (or netserver if it pays attention to it.) Access will be denied at authentication so the user will never get a chance to bond channels together. (I don't think there is a default anywhere.) "Max-Channels" controls the maximum number of channels allow into a single bundle. There is an ARC "default" user limit that will apply if RADIUS doesn't set it. This does not limit the number of times any user can simultaneously login; it only limits the number of logins per bundle -- they could have more than one bundle. (Yes, you can set it to zero.) This information was correct as of ARC 4.2.10 (alpha) [4.1.59?]. That does not mean the behavior has not been changed. It takes about two (2) minutes to verify the behavior. (No one is holding a gun to your head stopping you from trying these two attributes on a single user. To borrow the Nike (tm) phrase, "Just do it!") --Ricky
Subject: (usr-tc) usr-tc list requirements
From: Kevin Benton <s1kevin@tims.net>
Date: 1999-06-23 10:39:08
What is the criteria on whether or not messages get posted to this list? I have sent a number of messages which seem to have "dissapeared" without any notice on why it was rejected or not. As an example, I'm still looking to see the message I posted yesterday afternoon. Kevin Benton SOTA Technologies E-Mail: s1kevin@tims.net Web: http://users.sota-oh.com/~s1kevin/ Unsolicited advertisements processing fee: $50 subject to change without notice
Subject: Re: (usr-tc) just to clarify (port-limit/max-channels)
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1999-06-23 10:48:00
Thus spake Ricky Beam >You've got it backwards... "Port-Limit" limits the number of ports to which >the user is allowed access. If it's set to one (1) then the user can only >login once on any single ARC (or netserver if it pays attention to it.) >Access will be denied at authentication so the user will never get a chance >to bond channels together. (I don't think there is a default anywhere.) >"Max-Channels" controls the maximum number of channels allow into a single >bundle. There is an ARC "default" user limit that will apply if RADIUS >doesn't set it. This does not limit the number of times any user can >simultaneously login; it only limits the number of logins per bundle -- >they could have more than one bundle. (Yes, you can set it to zero.) >This information was correct as of ARC 4.2.10 (alpha) [4.1.59?]. Then they regressed. It was pointed out at some point after 4.1.11 I believe, that Port-Limit was intended for use in limiting the number of links in a Multi-Link bundle per the RFC. The wording of the RFC isn't a *requirement* that it only be used for Multi-Link, but there is wording that states that this is the intent of Port-Limit. There is not, to my knowledge, a standard RADIUS attribute used to limit the number of channels to provide to the user total...though the RFC doesn't restrict using Port-Limit in this way, its certainly discouraged. Its also discouraged since this usage is pretty much useless as soon as you start putting multiple NAS in a hunt group, since there is no mechanism for coordination of this between NASen. >That does >not mean the behavior has not been changed. It takes about two (2) minutes >to verify the behavior. (No one is holding a gun to your head stopping you >from trying these two attributes on a single user. To borrow the Nike (tm) >phrase, "Just do it!") Agreed...the best way to confirm how these attributes work is to just try it. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456
Subject: (usr-tc) Max-Channels/Port-Limit
From: Brian <signal@shreve.net>
Date: 1999-06-23 11:02:17
I would be interested in knowing what the correct values should be for each of: Port-Limit Max-Channels One UniLink Session 1 1 Two UniLink Sessions 2 1 Ten UniLink Sessions 10 1 One MultiLink Session (2 chan) 2 2 I filled in my best guess given whats been posted to this group, but I am very confused at this point. Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)
Subject: Re: (usr-tc) just to clarify (port-limit/max-channels)
From: Brian <signal@shreve.net>
Date: 1999-06-23 11:19:46
On Wed, 23 Jun 1999, Tatai SV Krishnan wrote: > On Wed, 23 Jun 1999, Brian wrote: > > > > > This is totally strange, I hope someone from 3Com comes forward with > > official clarification. > > > > I was not using Port-Limit. I *had* to set Max-Channels > 1 to allow > > multiple uni link sessions for a user, but I have been doing this so long, > > that perhap sit is fixed now I don't know. > > > > At one point in the 4.0.x code port-limit was broken - the code 4.1.59 > has prot-limit working as it should per the RFC I appreciate the response, but the RFC leaves a little to the imagination. Could you please describe breifly what the difference is between Max-Channels and Port-Limit: i.e. Max-Channels is entirely for MP bundles has nothing to do with limiting number of sessions on an ARC or whatever the case may be. Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)
Subject: Re: (usr-tc) just to clarify (port-limit/max-channels)
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1999-06-23 11:31:46
On Wed, 23 Jun 1999, Brian wrote: > > This is totally strange, I hope someone from 3Com comes forward with > official clarification. > > I was not using Port-Limit. I *had* to set Max-Channels > 1 to allow > multiple uni link sessions for a user, but I have been doing this so long, > that perhap sit is fixed now I don't know. > At one point in the 4.0.x code port-limit was broken - the code 4.1.59 has prot-limit working as it should per the RFC krish > > > On Wed, 23 Jun 1999, Ricky Beam wrote: > > > On Wed, 23 Jun 1999, Brian wrote: > > >If I have a user, and they have no port-limit set, and no max-channels > > >set, then that user will not be restricted by the ARC in any way from > > >dialing in 2, 4, 10 times correct? (simultaneously). > > > > > >And port-limit is just for mp bundles, so even with a port-limit of say 1 > > >set, a user could still have 2, 3, 4, etc seperate unilink sessions > > >correct? > > > > > >and max-channels, from what I can see, basically limits the number of > > >sessions a user can have "per arc", irregardless of MP or not. So if > > >max-channels = 2 is set for a user, and they dial into an ARC, then "that > > >arc" will only allow one more session for that user onto it. I don't > > >beleive their is any inter-arc communication about max-channels and it > > >only applies to the arc the session was established on. > > > > You've got it backwards... "Port-Limit" limits the number of ports to which > > the user is allowed access. If it's set to one (1) then the user can only > > login once on any single ARC (or netserver if it pays attention to it.) > > Access will be denied at authentication so the user will never get a chance > > to bond channels together. (I don't think there is a default anywhere.) > > > > "Max-Channels" controls the maximum number of channels allow into a single > > bundle. There is an ARC "default" user limit that will apply if RADIUS > > doesn't set it. This does not limit the number of times any user can > > simultaneously login; it only limits the number of logins per bundle -- > > they could have more than one bundle. (Yes, you can set it to zero.) > > > > This information was correct as of ARC 4.2.10 (alpha) [4.1.59?]. That does > > not mean the behavior has not been changed. It takes about two (2) minutes > > to verify the behavior. (No one is holding a gun to your head stopping you > > from trying these two attributes on a single user. To borrow the Nike (tm) > > phrase, "Just do it!") > > > > --Ricky > > > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > ----------------------------------------------------- > Brian Feeny (BF304) signal@shreve.net > 318-222-2638 x 109 http://www.shreve.net/~signal > Network Administrator ShreveNet Inc. (ASN 11881) > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >
Subject: Re: (usr-tc) just to clarify (port-limit/max-channels)
From: Brian <signal@shreve.net>
Date: 1999-06-23 11:42:42
> > > > Max-channels is nothing but port-limt. It does not limit the number of > sessions. So essentially you have the option either to use port-limit or > Max-channels to control the number of sessions. If set to 1 then the > user will be able to get one session but does not stop the user from > dialing from another modem to get a new session Ok, so let me get this straight: We can all say to hell with Max-Channels if we want, and just use "Port-Limit". Port Limit will *only* restrict the number of sessions in an MP bundle, and has *nothing* to do with the number of uni link sessions a user establishes to an ARC. Right? Brian > > > krish > > > > > > > > > ----------------------------------------------------- > > Brian Feeny (BF304) signal@shreve.net > > 318-222-2638 x 109 http://www.shreve.net/~signal > > Network Administrator ShreveNet Inc. (ASN 11881) > > > Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)
Subject: Re: (usr-tc) just to clarify (port-limit/max-channels)
From: Brian <signal@shreve.net>
Date: 1999-06-23 11:57:09
> > Right? > Yes - you are correct. > This being the case, it totally blows my mind the VSA was ever created. What was the purpose of it? I would hope that Port-Limit has precedence, in the case that: The ARC's default for Max-Channels is 2 A User has a RADIUS attribute Port-Limit = 1 I would hope that the user could not establish MLPPP becuase of Port-Limit, and that Max-Channels won't allow if Port-Limit is 1. Brian > krish > > > > > Brian > > > > > > > > > > > > > krish > > > > > > > > > > > > > > > > > > > ----------------------------------------------------- > > > > Brian Feeny (BF304) signal@shreve.net > > > > 318-222-2638 x 109 http://www.shreve.net/~signal > > > > Network Administrator ShreveNet Inc. (ASN 11881) > > > > > > > > > > > ----------------------------------------------------- > > Brian Feeny (BF304) signal@shreve.net > > 318-222-2638 x 109 http://www.shreve.net/~signal > > Network Administrator ShreveNet Inc. (ASN 11881) > > > Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)
Subject: Re: (usr-tc) just to clarify (port-limit/max-channels)
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1999-06-23 11:59:03
On Wed, 23 Jun 1999, Brian wrote: > On Wed, 23 Jun 1999, Tatai SV Krishnan wrote: > > > On Wed, 23 Jun 1999, Brian wrote: > > > > > > > > This is totally strange, I hope someone from 3Com comes forward with > > > official clarification. > > > > > > I was not using Port-Limit. I *had* to set Max-Channels > 1 to allow > > > multiple uni link sessions for a user, but I have been doing this so long, > > > that perhap sit is fixed now I don't know. > > > > > > > At one point in the 4.0.x code port-limit was broken - the code 4.1.59 > > has prot-limit working as it should per the RFC > > > I appreciate the response, but the RFC leaves a little to the imagination. > Could you please describe breifly what the difference is between > Max-Channels and Port-Limit: > > i.e. Max-Channels is entirely for MP bundles has nothing to do with > limiting number of sessions on an ARC or whatever the case may be. > Max-channels is nothing but port-limt. It does not limit the number of sessions. So essentially you have the option either to use port-limit or Max-channels to control the number of sessions. If set to 1 then the user will be able to get one session but does not stop the user from dialing from another modem to get a new session krish > > > > ----------------------------------------------------- > Brian Feeny (BF304) signal@shreve.net > 318-222-2638 x 109 http://www.shreve.net/~signal > Network Administrator ShreveNet Inc. (ASN 11881) >
Subject: Re: (usr-tc) just to clarify (port-limit/max-channels)
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1999-06-23 12:05:00
On Wed, 23 Jun 1999, Brian wrote: > > > > > > > > Max-channels is nothing but port-limt. It does not limit the number of > > sessions. So essentially you have the option either to use port-limit or > > Max-channels to control the number of sessions. If set to 1 then the > > user will be able to get one session but does not stop the user from > > dialing from another modem to get a new session > > Ok, so let me get this straight: > > We can all say to hell with Max-Channels if we want, and just use > "Port-Limit". Port Limit will *only* restrict the number of sessions in > an MP bundle, and has *nothing* to do with the number of uni link sessions > a user establishes to an ARC. > > Right? Yes - you are correct. krish > > Brian > > > > > > > > krish > > > > > > > > > > > > > > ----------------------------------------------------- > > > Brian Feeny (BF304) signal@shreve.net > > > 318-222-2638 x 109 http://www.shreve.net/~signal > > > Network Administrator ShreveNet Inc. (ASN 11881) > > > > > > > ----------------------------------------------------- > Brian Feeny (BF304) signal@shreve.net > 318-222-2638 x 109 http://www.shreve.net/~signal > Network Administrator ShreveNet Inc. (ASN 11881) >
Subject: (usr-tc) PPP Offloading
From: Brian <signal@shreve.net>
Date: 1999-06-23 12:10:45
I don't know what it is, but I am having one hell of a time with ISDN and 1.2.37 HDM code. I was going to mess with ppp offloading (right now its enabled).........I was going to try and disable it......can this be done on the fly, or does an ARC reboot have to happen for the new setting to take effect? Brian Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)
Subject: Re: (usr-tc) Max-Channels/Port-Limit
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1999-06-23 12:11:14
Thus spake Brian >I would be interested in knowing what the correct values should be for >each of: Port-Limit Max-Channels One UniLink Session 1 1 Two UniLink Sessions 1 2 Ten UniLink Sessions 1 10 One MultiLink Session (2 chan) 2 1 These would be my takes at it...at least per RFC, this is how it *should* work. As Ricky said though, the best way is just to try it out...its not like your TC box is gonna blow up or anything if you plug these values in via your RADIUS server. :) I've *long* believed that the best way to figure out how this stuff works is to experiment with it...asking other people can only give you some idea of how it works, you're not going to truly understand it until you play with it, experiment with it and poke at it to see what it does in reaction to various inputs. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456
Subject: Re: (usr-tc) just to clarify (port-limit/max-channels)
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1999-06-23 12:44:53
Thus spake Tatai SV Krishnan >Max-channels is nothing but port-limt. It does not limit the number of >sessions. So essentially you have the option either to use port-limit or >Max-channels to control the number of sessions. If set to 1 then the >user will be able to get one session but does not stop the user from >dialing from another modem to get a new session Aha...so Max-Channels and Port-Limit are synonymous now...ok...that's cool. That of course means that one of those entries in my little table was wrong, but I can deal with that. :) So, since they're synonymous at this point, you'll want to use Port-Limit. :) -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456
Subject: Re: (usr-tc) just to clarify (port-limit/max-channels)
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1999-06-23 13:06:05
On Wed, 23 Jun 1999, Brian wrote: > > This being the case, it totally blows my mind the VSA was ever created. > What was the purpose of it? > The VSA was created for two reasons 1. To have a Specific configuration for the default user templete so with minimum config on the radius you can have the modifications done to the default user that would affect all the users. 2. A blunder - guess they did not look at port limit when it all started. > I would hope that Port-Limit has precedence, in the case that: > > Yes. > The ARC's default for Max-Channels is 2 > A User has a RADIUS attribute Port-Limit = 1 > > I would hope that the user could not establish MLPPP becuase of > Port-Limit, and that Max-Channels won't allow if Port-Limit is 1. > Yes that should be true, but I have not checked it need to verify the same krish > Brian > > > > krish > > > > > > > > Brian > > > > > > > > > > > > > > > > > > krish > > > > > > > > > > > > > > > > > > > > > > > > ----------------------------------------------------- > > > > > Brian Feeny (BF304) signal@shreve.net > > > > > 318-222-2638 x 109 http://www.shreve.net/~signal > > > > > Network Administrator ShreveNet Inc. (ASN 11881) > > > > > > > > > > > > > > > ----------------------------------------------------- > > > Brian Feeny (BF304) signal@shreve.net > > > 318-222-2638 x 109 http://www.shreve.net/~signal > > > Network Administrator ShreveNet Inc. (ASN 11881) > > > > > > > ----------------------------------------------------- > Brian Feeny (BF304) signal@shreve.net > 318-222-2638 x 109 http://www.shreve.net/~signal > Network Administrator ShreveNet Inc. (ASN 11881) >
Subject: Re: (usr-tc) PPP Offloading
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1999-06-23 13:07:20
Yes you can do it on the fly - no rebooting required. 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, 23 Jun 1999, Brian wrote: > > I don't know what it is, but I am having one hell of a time with ISDN and > 1.2.37 HDM code. I was going to mess with ppp offloading (right now its > enabled).........I was going to try and disable it......can this be done > on the fly, or does an ARC reboot have to happen for the new setting to > take effect? > > Brian > > > ----------------------------------------------------- > Brian Feeny (BF304) signal@shreve.net > 318-222-2638 x 109 http://www.shreve.net/~signal > Network Administrator ShreveNet Inc. (ASN 11881) > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >
Subject: Re: (usr-tc) Max-Channels/Port-Limit
From: Ricky Beam <jfbeam@bluetopia.net>
Date: 1999-06-23 13:27:30
On Wed, 23 Jun 1999, Brian wrote: >I would be interested in knowing what the correct values should be for >each of: > > Port-Limit Max-Channels > >One UniLink Session 1 1 >Two UniLink Sessions 2 1 >Ten UniLink Sessions 10 1 >One MultiLink Session (2 chan) 2 2 > >I filled in my best guess given whats been posted to this group, but I am >very confused at this point. Dude, just stick a user in your RADIUS server and _try_ _it_. Personally, I never believe what 3Com says (they've been known to be wrong before -- no offense to krish.) We can banter back and forth for ever; the only way to know for with any certainty is to try it. (Looking at the source code is one way, but that just leads to "why the hell did it do that?") What you have above is conceptually correct. That's exactly how it worked several months ago. And IMO, that's how it should work. As always, your milage _will_ vary as you change firmware. (read: as 3Com changes their mind and breaks things.) --Ricky
Subject: Re: (usr-tc) Max-Channels/Port-Limit
From: Ricky Beam <jfbeam@bluetopia.net>
Date: 1999-06-23 13:28:47
On Wed, 23 Jun 1999, Jeff Mcadams wrote: >As Ricky said though, the best way is just to try it out...its not like >your TC box is gonna blow up or anything if you plug these values in via >your RADIUS server. :) And I'm not responsible if it does... >I've *long* believed that the best way to figure out how this stuff >works is to experiment with it...asking other people can only give you >some idea of how it works, you're not going to truly understand it until >you play with it, experiment with it and poke at it to see what it does >in reaction to various inputs. Translation: YMMV. --Ricky
Subject: (usr-tc) Problem with 1.2.37
From: Brian <signal@shreve.net>
Date: 1999-06-23 14:52:32
I have been having a very hard time getting connects, especially dual channel between Pipeline P50 (6.0.10) and the USR TC with 1.2.37. Does anyone know if an issue exists? I think someone at 3com should try a dual channel connection to a chassis running 1.2.37/4.1.59 -6. We are running with: enable ppp offloading disable ppp receive_accm I tried with ppp offloading disabled, and although at first it seemed to work (5 2-channel connects in a row), it no longer does. I dialed in 50 times for good measure, and only got dual channel 2 times. The P50 is set for perm switched. But it would appear that when only 1 of the 2 channels fails, it does not persistantly try to connect, anyone know how to acheive that on a p50? Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)
Subject: (usr-tc) 3Com web site open tickets
From: Brian <signal@shreve.net>
Date: 1999-06-23 15:07:00
Where can one look at the currently open tickets on say tcs3.5? I can't seem to find on totalservice how to get to the section where you can browse open tickets. Brian Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)
Subject: (usr-tc) default filter behaviour
From: Jeff Carneal <jeff@apex.net>
Date: 1999-06-23 15:13:50
Looking thru past posts, I see contradictory statements regarding the default actions of HARC filters if no match is found. Ie: <MSG> |> #filter |> IP: |> 001 AND src-addr = 208.198.5.0/24; |> 011 REJECT dst-addr = 0.0.0.0/0; The above rejects everything.. Since there is an implied DENY attached to all filters unless PERMIT is specified. </MSG> However, in the pdf docs on the CD, we have: Protocol Rules ... Filtering is performed based on the first match that occurs. If there is no match, the packet is accepted by default. ... It repeats that sentiment throughout the chapter. Yes, I know that with a little tinkering I could figure out the default behaviour, but I'd rather be right the first time :) Correct, unambiguous input is appreciated... -- Jeff Carneal - Sys Admin - Apex Internet jeff@apex.net http://www.apex.net (502) 442-5363 The opinions expressed above aren't really mine. They belong to someone else who also refuses to take responsibility for them.
Subject: RE: (usr-tc) just to clarify (port-limit/max-channels)
From: Robert von Bismarck <rvb@petrel.ch>
Date: 1999-06-23 16:01:31
If I have a user, and they have no port-limit set, and no max-channels set, then that user will not be restricted by the ARC in any way from dialing in 2, 4, 10 times correct? (simultaneously). Not true, the ARC internal DEFAULT user set max-channels to 2 by default. And port-limit is just for mp bundles, so even with a port-limit of say 1 set, a user could still have 2, 3, 4, etc seperate unilink sessions correct? True, it's up to your RADIUS server to lock him out or a soft like Tsmon. and max-channels, from what I can see, basically limits the number of sessions a user can have "per arc", irregardless of MP or not. So if max-channels = 2 is set for a user, and they dial into an ARC, then "that arc" will only allow one more session for that user onto it. I don't beleive their is any inter-arc communication about max-channels and it only applies to the arc the session was established on. Uhh... if MPIP is configured, max-channels gets broadcast over to the second, third or whatever ARC. It is then checked with the Port-Limit statement gotten from the RADIUS server or the Max-Channels entry in the DEFAULT user (not sure about the 2nd possibility, but it makes sense ;-) Robert Brian ----------------------------------------------------- Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881) - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.
Subject: (usr-tc) ARC -> Linxu PoPTop (PPTP)
From: Brian <signal@shreve.net>
Date: 1999-06-23 16:54:21
Has anyone as of yet had any luck whatsoever in getting a PPTP session from the ARC to connect to a Linux PPTP server? I don't really have alot of experience with PPTP. Here is how I have the user configured: demo Auth-Type = "Unix-PW" Service-Type = "Framed-User", Framed-Protocol = "PPP", Framed-IP-Address = "255.255.255.254", Framed-Netmask = "255.255.255.255", Framed-MTU = "1500", Port-Limit = "1", Framed-Routing = "None", Framed-Compression = "Van-Jacobson-TCP-IP", Tunnel-Type = "PPTP", Tunnel-Server-Endpoint = "208.206.76.27" Does this look sane? Is this all that is needed on 3com's end? Does anyone know much about the Linux PoPToP side of it? Linux Box's eth0 interface is 208.206.76.27 ARC's IP is 208.206.76.71 my config file for pptpd I just put: debug 1 pptpdlog /var/log/pptpd.log option /etc/ppp/options localip 208.206.76.27 remoteip 208.206.76.71 Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)
Subject: (usr-tc) filtering eth??
From: Jeff Carneal <jeff@apex.net>
Date: 1999-06-23 17:25:12
Ok, I can't get outgoing ethernet filtering to work at all on V4.1.59 :-( Haven't tried incoming yet, but outgoing is just as important to me at the moment. Here's a very simple example of a session where I add a filter that should kill all ethernet traffic to the HARC...however, you'll notice that it doesn't. Here's all the info: hiper1> add filter broken.fil hiper1> sh filter broken.fil RULES FOR FILTER /./broken.fil SHOW PROTOCOLS: ALL #filter IP: 010 DENY; hiper1> set interFACE eth:1 filTER_ACCESS on outPUT_FILTER "broken.fil" hiper1> sh interFACE eth:1 INTERFACE eth:1 SETTINGS Description: Ethernet Driver Type: ETHERNET-CSMACD Speed: 10485760 High Speed: 0 Administrative Status: Up Operational Status: Up Link Up/Down Traps: ENABLED Promiscuous Mode: FALSE Connector Present: TRUE Filter Access: ON Last Change: 0d 00:01:05 Input Filter: Output Filter: broken.fil Physical Address: 00:c0:49:12:79:54 hiper1> hiper1> list intERFACES INTERFACES Interface Oper Admin Name Status Status eth:1 Up Up eth:2 Down Up Does anybody have outgoing ethernet filtering working on this version? Is it a bug or am I missing something...TIA. -- Jeff Carneal - Sys Admin - Apex Internet jeff@apex.net http://www.apex.net (502) 442-5363 The opinions expressed above aren't really mine. They belong to someone else who also refuses to take responsibility for them.
Subject: Re: (usr-tc) ARC -> Linxu PoPTop (PPTP)
From: Brian <signal@shreve.net>
Date: 1999-06-23 18:16:30
> > > > demo Auth-Type = "Unix-PW" > > Service-Type = "Framed-User", > > Framed-Protocol = "PPP", > > > Framed-IP-Address = "255.255.255.254", > > Framed-Netmask = "255.255.255.255", > > Framed-MTU = "1500", > > Port-Limit = "1", > > > You do not need the above 4 lines - the ip address netmask mty prot limit > is set by the PPTP server > that configuration should be set on the PPTP server So it is ok if the ARC has no ip pool then, correct? You all haven't played with 3Com TC -> Linux PPTPd yet? Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)
Subject: Re: (usr-tc) ARC -> Linxu PoPTop (PPTP)
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1999-06-23 18:22:15
On Wed, 23 Jun 1999, Brian wrote: > > Has anyone as of yet had any luck whatsoever in getting a PPTP session > from the ARC to connect to a Linux PPTP server? > > I don't really have alot of experience with PPTP. Here is how I have the > user configured: > > demo Auth-Type = "Unix-PW" > Service-Type = "Framed-User", > Framed-Protocol = "PPP", > Framed-IP-Address = "255.255.255.254", > Framed-Netmask = "255.255.255.255", > Framed-MTU = "1500", > Port-Limit = "1", You do not need the above 4 lines - the ip address netmask mty prot limit is set by the PPTP server that configuration should be set on the PPTP server krish > Framed-Routing = "None", > Framed-Compression = "Van-Jacobson-TCP-IP", > Tunnel-Type = "PPTP", > Tunnel-Server-Endpoint = "208.206.76.27" > > > Does this look sane? Is this all that is needed on 3com's end? > > Does anyone know much about the Linux PoPToP side of it? > > Linux Box's eth0 interface is 208.206.76.27 > ARC's IP is 208.206.76.71 > > > > my config file for pptpd I just put: > > debug 1 > pptpdlog /var/log/pptpd.log > option /etc/ppp/options > localip 208.206.76.27 > remoteip 208.206.76.71 > > > > > ----------------------------------------------------- > Brian Feeny (BF304) signal@shreve.net > 318-222-2638 x 109 http://www.shreve.net/~signal > Network Administrator ShreveNet Inc. (ASN 11881) > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >
Subject: Re: (usr-tc) filtering eth??
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1999-06-23 18:24:37
On Wed, 23 Jun 1999, Jeff Carneal wrote: > > Ok, I can't get outgoing ethernet filtering to work at all on V4.1.59 :-( > Haven't tried incoming yet, but outgoing is just as important to me at the > moment. Here's a very simple example of a session where I add a filter > that should kill all ethernet traffic to the HARC...however, you'll notice > that it doesn't. Here's all the info: You want all the IP traffic from the network to be filtered on the ARC - correct - then this should be a in-filter not a out filter. krish > > hiper1> add filter broken.fil > hiper1> sh filter broken.fil > > RULES FOR FILTER /./broken.fil SHOW PROTOCOLS: ALL > #filter > IP: > 010 DENY; > hiper1> set interFACE eth:1 filTER_ACCESS on outPUT_FILTER "broken.fil" > hiper1> sh interFACE eth:1 > > INTERFACE eth:1 SETTINGS > Description: Ethernet Driver > Type: ETHERNET-CSMACD > Speed: 10485760 > High Speed: 0 > Administrative Status: Up > Operational Status: Up > Link Up/Down Traps: ENABLED > Promiscuous Mode: FALSE > Connector Present: TRUE > Filter Access: ON > Last Change: 0d 00:01:05 > Input Filter: > Output Filter: broken.fil > Physical Address: 00:c0:49:12:79:54 > hiper1> > hiper1> list intERFACES > > INTERFACES > Interface Oper Admin > Name Status Status > eth:1 Up Up > eth:2 Down Up > > Does anybody have outgoing ethernet filtering working on this version? Is > it a bug or am I missing something...TIA. > > > -- > Jeff Carneal - Sys Admin - Apex Internet > jeff@apex.net http://www.apex.net (502) 442-5363 > > The opinions expressed above aren't really mine. > They belong to someone else who also refuses to > take responsibility for them. > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >
Subject: (usr-tc) IP Pools & Modem Pools
From: Jesse Sipprell <jss@evcom.net>
Date: 1999-06-23 19:29:09
Is there an prefered method of configuring specific interfaces (via modemgroups) on a HARC for specific ip pool usage (for dynamic IP)? I have two hunt groups of circuits back-hauled from different geographical locations, and for organizational purposes I would like one group of HDMs to use one ip pool, while another uses the default pool. Thanks! -- Jesse Sipprell Technical Operations Director Evolution Communications, Inc. 800-496-4736 (ext 106) * Finger jss@evcom.net for my PGP Public Key *
Subject: Re: (usr-tc) ARC -> Linxu PoPTop (PPTP)
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1999-06-23 20:11:06
On Wed, 23 Jun 1999, Brian wrote: > > > > > > demo Auth-Type = "Unix-PW" > > > Service-Type = "Framed-User", > > > Framed-Protocol = "PPP", > > > > > Framed-IP-Address = "255.255.255.254", > > > Framed-Netmask = "255.255.255.255", > > > Framed-MTU = "1500", > > > Port-Limit = "1", > > > > > > You do not need the above 4 lines - the ip address netmask mty prot limit > > is set by the PPTP server > > that configuration should be set on the PPTP server > > So it is ok if the ARC has no ip pool then, correct? You all haven't > played with 3Com TC -> Linux PPTPd yet? If the call is PPTP or L2tp - there is no necessary for the hiper arc to have a Pool. I have not tried Linux PPTP yet, I have used NT, Ascend, Netserver and other flavors of PPTP krish > > ----------------------------------------------------- > Brian Feeny (BF304) signal@shreve.net > 318-222-2638 x 109 http://www.shreve.net/~signal > Network Administrator ShreveNet Inc. (ASN 11881) >
Subject: Re: (usr-tc) IP Pools & Modem Pools
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1999-06-23 20:17:16
On Wed, 23 Jun 1999, Jesse Sipprell wrote: > Is there an prefered method of configuring specific interfaces (via > modemgroups) on a HARC for specific ip pool usage (for dynamic IP)? I have two > hunt groups of circuits back-hauled from different geographical locations, and > for organizational purposes I would like one group of HDMs to use one ip pool, > while another uses the default pool. > There is not a real easy way to do this, you can setup two private pools and based on user setup you can assign them to different pools but currently there is no solution. However there is plans to setup DNIS based IP pool setup configuration in plans. That would allow you to setup a DNIS - to point to a IP pool on the hiper arc - so anyone who use that DNIS will get assigned to that pool krish > Thanks! > > -- > Jesse Sipprell > Technical Operations Director > Evolution Communications, Inc. > 800-496-4736 (ext 106) > > * Finger jss@evcom.net for my PGP Public Key * > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >
Subject: Re: (usr-tc) ARC -> Linxu PoPTop (PPTP)
From: Brian <signal@shreve.net>
Date: 1999-06-23 20:57:32
> If the call is PPTP or L2tp - there is no necessary for the hiper arc to > have a Pool. > I have not tried Linux PPTP yet, I have used NT, Ascend, Netserver and > other flavors of PPTP Ok, I made the user: demo Auth-Type = "Unix-PW" Service-Type = "Framed-User", Framed-Protocol = "PPP", Framed-Routing = "None", Framed-Compression = "Van-Jacobson-TCP-IP", Tunnel-Type = "PPTP", Tunnel-Server-Endpoint = "208.206.76.27" I don't know much about PPTP but I will do some testing with Linux tommorow, hopefully all goes well. > > krish > > > > > ----------------------------------------------------- > > Brian Feeny (BF304) signal@shreve.net > > 318-222-2638 x 109 http://www.shreve.net/~signal > > Network Administrator ShreveNet Inc. (ASN 11881) > > > Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)
Subject: Re: (usr-tc) Windows 3.1/MacTCP Nightmare
From: Scott Bailey <scott@epix.net>
Date: 1999-06-23 21:08:03
----- Original Message ----- Sent: Wednesday, June 23, 1999 8:44 AM > So did anyone figure out how to fix the Mac TCP problem?? > > Vito > One explanation that was offered, was that our backbone providers may have done some traffic shaping. Aparently some providers are starting to make use of TOS. The way it was explained to me was, there is a set of bits in the IP header called TOS (Type Of Service). Essentially it's assigning values to a set of unused bits in the IP header and then prioritizing packets through ones routers and switches differently based on how the bits are set. MacTCP is known not to be able to handle these bit settings and breaks. Our old Windows 3.1 dialers aparently have the same problem. Unfortunately our backbone providers will not confirm that this is what has happened. In the meantime, we found that running a squid proxy cache on a linux box, and having the customers pull everything down from that works. I'm in the process of trying to get the resources (bigger machine) to do it for all our 3.1/MacTCP customers. It will be easier than having the customer fiddle around with different software. Scott Bailey Epix Internet Services
Subject: Re: (usr-tc) filtering eth??
From: Jeff Carneal <jeff@apex.net>
Date: 1999-06-23 22:39:21
On Wed, 23 Jun 1999, Tatai SV Krishnan wrote: > On Wed, 23 Jun 1999, Jeff Carneal wrote: > > > > > Ok, I can't get outgoing ethernet filtering to work at all on V4.1.59 :-( > > Haven't tried incoming yet, but outgoing is just as important to me at the > > moment. Here's a very simple example of a session where I add a filter > > that should kill all ethernet traffic to the HARC...however, you'll notice > > that it doesn't. Here's all the info: > > You want all the IP traffic from the network to be filtered on the ARC - > correct - then this should be a in-filter not a out filter. No, in this case I want all traffic *from* the ARC *to* the network to be filtered. What I really want is an outbound filter, but the example I gave was only to demonstrate that it wasn't working... The real filters I want to implement prevent spoofing, routing loops, etc, and I have them working nicely on other RAS equipment. However, I can't get *any* ethernet outbound filter to work on the HARC, which was what I was trying to show with the simple "DENY everything" filter I posted... So, what am I missing? Why does that last filter not block all outgoing packets spewing forth through eth:1 to the local network? -- Jeff Carneal - Sys Admin - Apex Internet jeff@apex.net http://www.apex.net (502) 442-5363 The opinions expressed above aren't really mine. They belong to someone else who also refuses to take responsibility for them.
Subject: (usr-tc) Upgrade sequence..
From: Roy <garlic@garlic.com>
Date: 1999-06-23 23:39:27
I have a brand new TCH with HiperARC and HiperDSP. The software as it came is a bit old. What's the recommended sequence for upgrading the software? Which card first? Any common pitfalls?
Subject: Re: (usr-tc) Upgrade sequence..
From: Frank Basso <frank@okwhatever.com>
Date: 1999-06-24 02:12:48
Use the TC Manager in windows, Upgrade all componenets to the TCS release that you want, the Software will do them in the correct order. Restart after the upgrade...It helps. Make sure you read the release notes as you may have to manually save templates on the DSP in some TCS releases. -Frank ---------- Original Message ---------------------------------- Reply-To: usr-tc@lists.xmission.com > > >I have a brand new TCH with HiperARC and HiperDSP. The software as it >came is a bit old. What's the recommended sequence for upgrading the >software? Which card first? Any common pitfalls? > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message.
Subject: Re: (usr-tc) Upgrade sequence..
From: florin_neamtu@3com.com
Date: 1999-06-24 08:27:57
Hi Roy, The suggested sequence in upgrading is NMC first (to can handle the new MIBs and keep the config for the rest of the cards in TCH) and after, the rest of the cards: HARC , HDSP(s). Regards, Florin N
Subject: (usr-tc) Suggested Code
From: brian@semo.net
Date: 1999-06-24 10:47:03
I'm having difficulty with some Flex modem connects. User can dial in through their office phone system fine (because it won't even try a flex connect then) but not on a real phone line. They won't negotiate down to a 33.6k connect...TC just hangs up. User refuses to upgrade modem because it works fine with our competition (who also uses TC). What code would you suggest for Arc / NMC / DSP cards in my boxes to handle this and not mess with other v90 & x2 customers (pipe dream I know). But what code seems to be the most stable. Our DSP's are hooked up to channelized T1s. THANK YOU! Brian Becker Poplar Bluff Internet, Inc. http://www.semo.net Home of JerusalemPerspective.com Bookstore http://www.JerusalemPerspective.com TotallyFabricated.com's Webgabber Chat Software http://www.TotallyFabricated.com and my personal page http://www.Tonionio.com
Subject: (usr-tc) modems wont answer
From: Scott Boggs <sboggs@unitedbank.net>
Date: 1999-06-24 10:47:49
One of my dsp's (1.2.37) wont take calls. On "Reason for call Failure" the TCM reports: "pbReceivedLsWhileLinkUp(55)". All the Near End stats are fine on the T1-pri. All the modems are operational. The card is set up like all my others. I rebooted at least twice. Anyone have a suggestion? Thanks, Scott Boggs
Subject: Re: (usr-tc) filtering eth??
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1999-06-24 11:12:58
On Wed, 23 Jun 1999, Jeff Carneal wrote: > No, in this case I want all traffic *from* the ARC *to* the network to be > filtered. What I really want is an outbound filter, but the example I > gave was only to demonstrate that it wasn't working... > > The real filters I want to implement prevent spoofing, routing loops, etc, > and I have them working nicely on other RAS equipment. However, I can't > get *any* ethernet outbound filter to work on the HARC, which was what I > was trying to show with the simple "DENY everything" filter I posted... The filter access on the interface should be off set inter eth:1 filter_access off krish > > So, what am I missing? Why does that last filter not block all outgoing > packets spewing forth through eth:1 to the local network? > > -- > Jeff Carneal - Sys Admin - Apex Internet > jeff@apex.net http://www.apex.net (502) 442-5363 > > The opinions expressed above aren't really mine. > They belong to someone else who also refuses to > take responsibility for them. > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >
Subject: Re: (usr-tc) filtering eth??
From: Jeff Carneal <jeff@apex.net>
Date: 1999-06-24 12:29:58
On Thu, 24 Jun 1999, Tatai SV Krishnan wrote: > On Wed, 23 Jun 1999, Jeff Carneal wrote: > > No, in this case I want all traffic *from* the ARC *to* the network to be > > filtered. What I really want is an outbound filter, but the example I > > gave was only to demonstrate that it wasn't working... > > > > The real filters I want to implement prevent spoofing, routing loops, etc, > > and I have them working nicely on other RAS equipment. However, I can't > > get *any* ethernet outbound filter to work on the HARC, which was what I > > was trying to show with the simple "DENY everything" filter I posted... > > The filter access on the interface should be off > > set inter eth:1 filter_access off Thank you very much, that did the trick. I must add, however, that it's extraordinarily counterintuitive. Also, it appears to be undocumented, at least in version 1.0 of the HARC User Manual...perhaps I just looked in the wrong place. Once again, thanks for the help, -- Jeff Carneal - Sys Admin - Apex Internet jeff@apex.net http://www.apex.net (502) 442-5363 The opinions expressed above aren't really mine. They belong to someone else who also refuses to take responsibility for them.
Subject: Re: (usr-tc) usr-tc list requirements
From: Pete Ashdown <pashdown@xmission.com>
Date: 1999-06-24 12:39:54
Kevin Benton said once upon a time: > >What is the criteria on whether or not messages get posted to this list? >I have sent a number of messages which seem to have "dissapeared" without >any notice on why it was rejected or not. As an example, I'm still >looking to see the message I posted yesterday afternoon. 1. It is sent from the same email address you are subscribed as. 2. It is under 10K 3. It does not contain words like "subscribe" or "help" or a set of other commonly abused keywords. If a message does hit one of these three rules, it is sent to me for approval. Sometimes I do not get around to approving messages for up to a week. That is why they may be delayed. In some cases, usually if someone sends a digest back to the list with one comment, or a huge MIME poop, I'll delete it rather than approve it.
Subject: Re: (usr-tc) mac connects
From: Pete Ashdown <pashdown@xmission.com>
Date: 1999-06-24 12:42:56
Brian said once upon a time: >> Upgrade your code, or tell your customers to use Apple's Open Transport PPP >> rather than FreePPP. > >Ok, I know we encourage Open Transport. Regarding FreePPP, what was the >problem with FreePPP and 1.2.43? What that the password corruption >problem? No, 1.2.43 had some problems with LCP extensions like async-maps and such. Shutting of the LCP extensions on FreePPP and NT would usually allow people to connect smoother, but it wasn't 100%.
Subject: (usr-tc) DOVBS
From: Pete Ashdown <pashdown@xmission.com>
Date: 1999-06-24 15:12:16
Am I to presume that the wind-blowing sound signifies the fact that DOVBS is still not possible with HiPer equipment? Didn't Ascend have this ability from day one?
Subject: (usr-tc) ppp negotiation problem.
From: Randy McMillan <randy@pacinfo.com>
Date: 1999-06-24 16:43:55
One of our users can dial in and authenticate, but then it just hangs up. Below is a monitor ppp for the user. It appears at the end there is a PROT_REJ message and then it is hung up. Is there anything that I can determine from this that will point me in the right direction? This is on a Win95 system with a USR Win modem. The network and DUN settings seem to be normal. TCS 3.5 Hiper ARC and quad modems. Thanks. Outgoing PPP Data on interface: slot:12/mod:4 PAP ACK Outgoing PPP Data on interface: slot:12/mod:4 IPCP CFG_REQ COMPR_TYPE 00 2d 0f 00 NEW_ADDRS 0c 07 78 fb Incoming PPP Data on interface: slot:12/mod:4 CCP CFG_REQ MS_COMP 00 00 00 01 STAC_COMP 00 01 04 Outgoing PPP Data on interface: slot:12/mod:4 CCP CFG_REJ STAC_COMP 00 01 04 Outgoing PPP Data on interface: slot:12/mod:4 CCP CFG_REQ MS_COMP 00 00 00 01 Incoming PPP Data on interface: slot:12/mod:4 LCP PROT_REJ IPCP COMPR_TYPE 00 2d 0f 00 NEW_ADDRS 0c 07 78 fb Tracing stopped, Return/Enter to re-start, ESCAPE to quit.
Subject: Re: (usr-tc) DOVBS
From: Ricky Beam <jfbeam@bluetopia.net>
Date: 1999-06-24 18:08:04
On Thu, 24 Jun 1999, Pete Ashdown wrote: >Am I to presume that the wind-blowing sound signifies the fact that DOVBS >is still not possible with HiPer equipment? Didn't Ascend have this >ability from day one? *laugh* DoVBS is available in the quads as I recall... you'll have to setup some funky DNIS based modem inits to get everything to play nicely with the other children :-) --Ricky
Subject: (usr-tc) Office Connect....Doesn't
From: Greg Owens <gowens@magnolia-net.com>
Date: 1999-06-24 20:53:58
Need some advice here. It appears (according to the people at 3Com) that our system is the only one in the world that a brand new 3Com Office Connect box will not connect with. I have a company that is attempting to use 5 of these through out their organization and none will connect (They are just using it as a analog 56k dial up connection). The people with 3Com can't even get one to log in with us. We have upgraded all our Hyper equipment and DSP cards to latest codes (No Help) I attempted to capture a ppp session with it but never received anything from the office connect box to capture. We use CT-1's if it matters. Anyone have any suggestions? Is there something I need to have enabled that I might not? They are using a different provider right now but will switch to us if we can get this to work. Any help would be greatly appreciated. Thanks in advance Greg Owens Magnolia Internet Services http://www.magnolia-net.com
Subject: Re: (usr-tc) ppp negotiation problem.
From: Mike Andrews <mandrews@termfrost.org>
Date: 1999-06-25 00:09:55
On Thu, 24 Jun 1999, Randy McMillan wrote: > One of our users can dial in and authenticate, but then it just hangs up. > Below is a monitor ppp for the user. It appears at the end there is a > PROT_REJ message and then it is hung up. Is there anything that I can > determine from this that will point me in the right direction? This is on a > Win95 system with a USR Win modem. The network and DUN settings seem to be > normal. TCS 3.5 Hiper ARC and quad modems. Thanks. > > Outgoing PPP Data on interface: slot:12/mod:4 > PAP ACK > Outgoing PPP Data on interface: slot:12/mod:4 > IPCP CFG_REQ COMPR_TYPE 00 2d 0f 00 > NEW_ADDRS 0c 07 78 fb > > Incoming PPP Data on interface: slot:12/mod:4 > CCP CFG_REQ MS_COMP 00 00 00 01 > STAC_COMP 00 01 04 > > Outgoing PPP Data on interface: slot:12/mod:4 > CCP CFG_REJ STAC_COMP 00 01 04 > > Outgoing PPP Data on interface: slot:12/mod:4 > CCP CFG_REQ MS_COMP 00 00 00 01 > > Incoming PPP Data on interface: slot:12/mod:4 > LCP PROT_REJ IPCP > COMPR_TYPE 00 2d 0f 00 > NEW_ADDRS 0c 07 78 fb > Tracing stopped, Return/Enter to re-start, ESCAPE to quit. My guess: they don't have TCP/IP installed in the Network control panel. That's why they rejected IPCP as an unknown protocol. Mike Andrews (MA12) -=-=- VP & Sysadmin, Digital Crescent, Frankfort KY mandrews@dcr.net -=- mandrews@termfrost.org -=- http://www.termfrost.org "If Yoda so strong in Force is, why words in right order he cannot put?"
Subject: Re: (usr-tc) Office Connect....Doesn't
From: Paul M. Oster <devious@minot.com>
Date: 1999-06-25 09:28:21
Hrm... I had a similar problem... upgrade the code on the OC... I had a OCRDA do the same thing. Paul M. Oster <devious@minot.com> http://www.minot.com/ Magic Internet Services (701) 838-1265 Minots FIRST Internet Connection -=**=--=**=--=**=--=**=--=**=--=**=--=**=--=**=--=**=- "I might not agree with what you have to say but I will defend, to my death, your right to say it." - Voltaire On Thu, 24 Jun 1999, Greg Owens wrote: > Need some advice here. It appears (according to the people at 3Com) that our > system is the only one in the world that a brand new 3Com Office Connect box > will not connect with. I have a company that is attempting to use 5 of these > through out their organization and none will connect (They are just using it > as a analog 56k dial up connection). The people with 3Com can't even get one > to log in with us. We have upgraded all our Hyper equipment and DSP cards to > latest codes (No Help) I attempted to capture a ppp session with it but > never received anything from the office connect box to capture. We use > CT-1's if it matters. Anyone have any suggestions? Is there something I need > to have enabled that I might not? They are using a different provider right > now but will switch to us if we can get this to work. Any help would be > greatly appreciated. Thanks in advance > Greg Owens > Magnolia Internet Services > http://www.magnolia-net.com > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >
Subject: Re: (usr-tc) modems wont answer
From: SCAT SCAT <siemensscat@yahoo.com>
Date: 1999-06-25 12:23:37
I have experienced this one in the past when using RADIUS. If RADIUS is down or not configured correctly, my DSP HiPer will not answer. --- Scott Boggs <sboggs@unitedbank.net> wrote: > One of my dsp's (1.2.37) wont take calls. > On "Reason for call Failure" the TCM reports: > "pbReceivedLsWhileLinkUp(55)". > All the Near End stats are fine on the T1-pri. > All the modems are operational. > The card is set up like all my others. > I rebooted at least twice. > > Anyone have a suggestion? > > Thanks, > Scott Boggs > > > - > To unsubscribe to usr-tc, send an email to > "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the > message. > For information on digests or retrieving files and > old messages send > "help" to the same address. Do not use quotes in > your message. > _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
Subject: RE: (usr-tc) totalservice.usr.com
From: Marshall Morgan <marshall@netdoor.com>
Date: 1999-06-25 12:57:34
They both seem up! =================== root@webmail 7# traceroute totalservice.usr.com traceroute: Warning: Multiple interfaces found; using 208.137.128.40 @ cnft0 traceroute to totalservice.usr.com (207.24.160.20), 30 hops max, 40 byte packets 1 core1-fe0-0.jxn.netdoor.net (208.137.128.1) 0.633 ms 0.493 ms 0.459 ms 2 157.130.129.161 (157.130.129.161) 15.081 ms 15.911 ms 15.800 ms 3 106.ATM2-0.XR2.ATL1.ALTER.NET (146.188.232.118) 13.688 ms 13.695 ms 13.700 ms 4 194.ATM10-0-0.BR1.ATL1.ALTER.NET (146.188.232.53) 19.549 ms 15.973 ms 15.325 ms 5 h111.t104-0.Atlanta.t3.ans.net (137.39.140.14) 16.917 ms 17.210 ms 16.627 ms 6 h12-1.t64-0.Houston.t3.ans.net (140.223.65.17) 49.650 ms 45.526 ms 46.943 ms 7 h14-1.t80-1.St-Louis.t3.ans.net (140.223.65.14) 62.376 ms 62.606 ms 61.812 ms 8 f3-1.t24-0.Chicago.t3.ans.net (140.222.27.122) 52.452 ms 60.388 ms 52.876 ms 9 h1-0-0.bnss1056.Chicago2.t3.ans.net (140.223.25.26) 57.077 ms 59.578 ms 55.153 ms 10 s1.enss3466.t3.ans.net (207.25.1.90) 59.229 ms 65.386 ms 82.731 ms 11 207.24.160.20 (207.24.160.20) 58.839 ms 66.814 ms 93.271 ms root@webmail 8# traceroute totalservice.3com.com traceroute: Warning: Multiple interfaces found; using 208.137.128.40 @ cnft0 traceroute to totalservice.3com.com (207.24.160.21), 30 hops max, 40 byte packets 1 core1-fe0-0.jxn.netdoor.net (208.137.128.1) 0.710 ms 0.521 ms 0.417 ms 2 157.130.129.161 (157.130.129.161) 15.857 ms 17.080 ms 16.104 ms 3 106.ATM3-0.XR1.ATL1.ALTER.NET (146.188.232.114) 13.783 ms 13.778 ms 13.842 ms 4 195.ATM9-0-0.BR1.ATL1.ALTER.NET (146.188.232.57) 14.801 ms 14.373 ms 14.467 ms 5 h111.t104-0.Atlanta.t3.ans.net (137.39.140.14) 16.674 ms 15.330 ms 24.314 ms 6 h12-1.t64-0.Houston.t3.ans.net (140.223.65.17) 43.800 ms 43.225 ms 44.200 ms 7 h14-1.t80-1.St-Louis.t3.ans.net (140.223.65.14) 63.424 ms 59.932 ms 63.505 ms 8 f3-1.t24-0.Chicago.t3.ans.net (140.222.27.122) 52.572 ms 49.866 ms 51.894 ms 9 h1-0-0.bnss1056.Chicago2.t3.ans.net (140.223.25.26) 51.994 ms 53.357 ms 53.699 ms 10 s1.enss3466.t3.ans.net (207.25.1.90) 62.096 ms 66.617 ms 83.353 ms 11 207.24.160.21 (207.24.160.21) 84.821 ms 64.480 ms 68.173 ms root@webmail 9# telnet totalservice.usr.com 80 Trying 207.24.160.20... Connected to totalservice.usr.com. Escape character is '^]'. GET / <html> <head> <title>3Com - TOTALservice Online</title> Marshall Morgan Internet Doorway, Inc (aka NETDOOR) http://www.netdoor.com > -----Original Message----- > From: owner-usr-tc@lists.xmission.com > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Bob Purdon > Sent: Friday, June 25, 1999 4:33 AM > To: usr-tc@xmission.com > Subject: (usr-tc) totalservice.usr.com > > > > Is it just me, or is everyone seeing that totalservice.usr.com is down? > > ------------------------------------------------------------------------ > Bob Purdon, Ground Floor, Marine Board Building > Technical Manager (Tas/Vic), 1 Franklin Wharf, Tas 7000 > Southern Internet Services. +61 (3) 6234 7444 > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > >
Subject: RE: (usr-tc) totalservice.usr.com
From: brian@semo.net
Date: 1999-06-25 14:32:02
We worked over the phone with them and it seems to be back up now. Brian Becker Poplar Bluff Internet, Inc. http://www.semo.net Home of JerusalemPerspective.com Bookstore http://www.JerusalemPerspective.com TotallyFabricated.com's Webgabber Chat Software http://www.TotallyFabricated.com and my personal page http://www.Tonionio.com -----Original Message----- [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Bob Purdon Sent: Friday, June 25, 1999 4:33 AM Is it just me, or is everyone seeing that totalservice.usr.com is down? Bob Purdon, Ground Floor, Marine Board Building Technical Manager (Tas/Vic), 1 Franklin Wharf, Tas 7000 Southern Internet Services. +61 (3) 6234 7444 - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.
Subject: (usr-tc) Shiva Access Port 2.1 and TC HiperDSP/ARC
From: Jason Cropper <jason@clearsail.net>
Date: 1999-06-25 15:14:37
The Shiva Access Port 2.1 will connect and authenticate when using what is called DIAT (Dynamic IP Address Translation) to our HiperDSP. It will not connect when using static IP assignment and turning off DIAT on the Shiva. Anyone know any tricks to getting a Shiva hooked up to a TC HiperDSP/ARC? We're using the latest revision of the HiperDSP code too. Jason Cropper CTO ClearSail Communications
Subject: RE: (usr-tc) modems wont answer
From: Scott Boggs <sboggs@unitedbank.net>
Date: 1999-06-25 15:54:34
I worked with my vendor support line. The packet-bus from the DSP to the ARC was hung up somehow. Rebooting the ARC fixed it. I think this problem was caused by changing ownership of the DSP from ARCa to ARCb , in the same chassis. > -----Original Message----- > From: SCAT SCAT [SMTP:siemensscat@yahoo.com] > Sent: Friday, June 25, 1999 3:24 PM > To: usr-tc@lists.xmission.com > Subject: Re: (usr-tc) modems wont answer > > I have experienced this one in the past when using > RADIUS. If RADIUS is down or not configured > correctly, my DSP HiPer will not answer. > > --- Scott Boggs <sboggs@unitedbank.net> wrote: > > One of my dsp's (1.2.37) wont take calls. > > On "Reason for call Failure" the TCM reports: > > "pbReceivedLsWhileLinkUp(55)". > > All the Near End stats are fine on the T1-pri. > > All the modems are operational. > > The card is set up like all my others. > > I rebooted at least twice. > > > > Anyone have a suggestion? > > > > Thanks, > > Scott Boggs > > > > > > - > > To unsubscribe to usr-tc, send an email to > > "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the > > message. > > For information on digests or retrieving files and > > old messages send > > "help" to the same address. Do not use quotes in > > your message. > > > > _________________________________________________________ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message.
Subject: Re: (usr-tc) Office Connect....Doesn't
From: Greg Owens <gowens@magnolia-net.com>
Date: 1999-06-25 19:20:10
I wish!!!!!.....These OC's were donated by the Gates Center to several rural libraries in our area as a grant. They will not allow me to even touch any of the setting on them much less upgrade the code. They say they have a unit that is logging into a ISP running 3Com equipment with no problem. I was hoping that I might have over looked something since it doesn't even appear to attempt log on....They have told me it is my authentication program. I don't by that.......Any other suggestions???????? -----Original Message----- > > > Hrm... I had a similar problem... upgrade the code on the OC... I had a >OCRDA do the same thing. > >Paul M. Oster <devious@minot.com> http://www.minot.com/ >Magic Internet Services (701) 838-1265 >Minots FIRST Internet Connection > >-=**=--=**=--=**=--=**=--=**=--=**=--=**=--=**=--=**=- > >"I might not agree with what you have to say but I will defend, to >my death, your right to say it." - Voltaire > >On Thu, 24 Jun 1999, Greg Owens wrote: > >> Need some advice here. It appears (according to the people at 3Com) that our >> system is the only one in the world that a brand new 3Com Office Connect box >> will not connect with. I have a company that is attempting to use 5 of these >> through out their organization and none will connect (They are just using it >> as a analog 56k dial up connection). The people with 3Com can't even get one >> to log in with us. We have upgraded all our Hyper equipment and DSP cards to >> latest codes (No Help) I attempted to capture a ppp session with it but >> never received anything from the office connect box to capture. We use >> CT-1's if it matters. Anyone have any suggestions? Is there something I need >> to have enabled that I might not? They are using a different provider right >> now but will switch to us if we can get this to work. Any help would be >> greatly appreciated. Thanks in advance >> Greg Owens >> Magnolia Internet Services >> http://www.magnolia-net.com >> >> >> - >> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" >> with "unsubscribe usr-tc" in the body of the message. >> For information on digests or retrieving files and old messages send >> "help" to the same address. Do not use quotes in your message. >> > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >
Subject: (usr-tc) totalservice.usr.com
From: Bob Purdon <bobp@southcom.com.au>
Date: 1999-06-25 19:32:57
Is it just me, or is everyone seeing that totalservice.usr.com is down? Bob Purdon, Ground Floor, Marine Board Building Technical Manager (Tas/Vic), 1 Franklin Wharf, Tas 7000 Southern Internet Services. +61 (3) 6234 7444
Subject: RE: (usr-tc) WebTV revisited...again
From: Marshall Morgan <marshall@netdoor.com>
Date: 1999-06-26 05:00:21
Get 4.1.59-6 of the ARC code. I believe it is the most current and reliable ARC code out. Marshall Morgan Internet Doorway, Inc (aka NETDOOR) http://www.netdoor.com > -----Original Message----- > From: owner-usr-tc@lists.xmission.com > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Walt Gnann > Sent: Saturday, June 26, 1999 4:49 AM > To: TC List > Subject: (usr-tc) WebTV revisited...again > > > OK...just upgraded our chassis to HARC 4.1.11 and HDSPs to 2.0.81 and now > WebTV is broken...again. > > Last time I set ppp authentication_preference PAP, set ppp > receive_authentication PAP, and changed Framed-Compression in Radius from > None to Van-Jacobsen-TCP-IP and it starting working. Now it doesn't seem > to want to work. > > montor ppp call events gives the following for a webtv connection attempt: > > New PPP Call received on interface slot:13/mod:5 > ....Tracing of Call Events; Escape to stop... > Unexpected (LCP) Layer Down, ID 1, Restarting Link 34561816, to . > Peer has not requested Auth, PPP link down to . > PPP connection down to . > > Any suggestions? Anyone else having similar problems with TCS 3.5? > > Walt > ----------------------------------------------------- > Walter N. Gnann > ISLC, President > 843.770.1000 > 843.770.1002 (fax) > wgnann@islc.net > http://www.islc.net > http://www.beaufortonline.com > http://www.beaufortcomputerclub.org > ----------------------------------------------------- > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > >
Subject: (usr-tc) WebTV revisited...again
From: Walt Gnann <wgnann@islc.net>
Date: 1999-06-26 05:49:04
OK...just upgraded our chassis to HARC 4.1.11 and HDSPs to 2.0.81 and now WebTV is broken...again. Last time I set ppp authentication_preference PAP, set ppp receive_authentication PAP, and changed Framed-Compression in Radius from None to Van-Jacobsen-TCP-IP and it starting working. Now it doesn't seem to want to work. montor ppp call events gives the following for a webtv connection attempt: New PPP Call received on interface slot:13/mod:5 ....Tracing of Call Events; Escape to stop... Unexpected (LCP) Layer Down, ID 1, Restarting Link 34561816, to . Peer has not requested Auth, PPP link down to . PPP connection down to . Any suggestions? Anyone else having similar problems with TCS 3.5? Walt Walter N. Gnann ISLC, President 843.770.1000 843.770.1002 (fax) wgnann@islc.net http://www.islc.net http://www.beaufortonline.com http://www.beaufortcomputerclub.org
Subject: Re: (usr-tc) WebTV revisited...again
From: Walt Gnann <wgnann@islc.net>
Date: 1999-06-26 07:46:13
Thanks....that did the trick. Walt Walter N. Gnann ISLC, President 843.770.1000 843.770.1002 (fax) wgnann@islc.net http://www.islc.net http://www.beaufortonline.com http://www.beaufortcomputerclub.org -----Original Message----- >Get 4.1.59-6 of the ARC code. I believe it is the most current and reliable ARC >code out. > >Marshall Morgan > >Internet Doorway, Inc (aka NETDOOR) >http://www.netdoor.com > > >> -----Original Message----- >> From: owner-usr-tc@lists.xmission.com >> [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Walt Gnann >> Sent: Saturday, June 26, 1999 4:49 AM >> To: TC List >> Subject: (usr-tc) WebTV revisited...again >> >> >> OK...just upgraded our chassis to HARC 4.1.11 and HDSPs to 2.0.81 and now >> WebTV is broken...again. >> >> Last time I set ppp authentication_preference PAP, set ppp >> receive_authentication PAP, and changed Framed-Compression in Radius from >> None to Van-Jacobsen-TCP-IP and it starting working. Now it doesn't seem >> to want to work. >> >> montor ppp call events gives the following for a webtv connection attempt: >> >> New PPP Call received on interface slot:13/mod:5 >> ....Tracing of Call Events; Escape to stop... >> Unexpected (LCP) Layer Down, ID 1, Restarting Link 34561816, to . >> Peer has not requested Auth, PPP link down to . >> PPP connection down to . >> >> Any suggestions? Anyone else having similar problems with TCS 3.5? >> >> Walt >> ----------------------------------------------------- >> Walter N. Gnann >> ISLC, President >> 843.770.1000 >> 843.770.1002 (fax) >> wgnann@islc.net >> http://www.islc.net >> http://www.beaufortonline.com >> http://www.beaufortcomputerclub.org >> ----------------------------------------------------- >> >> >> >> - >> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" >> with "unsubscribe usr-tc" in the body of the message. >> For information on digests or retrieving files and old messages send >> "help" to the same address. Do not use quotes in your message. >> >> > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >
Subject: (usr-tc) NFAS and 2.0.81 setup
From: pferraro@wna-linknet.com
Date: 1999-06-26 10:34:53
We are getting ready to change from Channelized T-1s to ISDN/PRI circuits... We have 2.0.81 on the DSPs. Now we need to know how to configure NFAS so that a SINGLE D-Channel will support 3 DSPs. There is NO HELP at the NFAS Settings screen, so we need to know EXACTLY what Logical Group, NFAS Span D-Channel, and Logical Grp Type is and how they get configured. I assume that NFAS ID is defaulted to 1. We already have OUR Dual/PRI hub configured with our QUADS using NFAS. Thanks in advance! P.S. The 3COM documentation is very skimpy in this area of configuring the DSPs!!! ============================================================================== Phillip Ferraro WorldNet Access, Inc pferraro@wna-linknet.com Onslow County's PREMIER InterNet Service Voice (910) 346-0835 824 Gumbranch Square, Suite R3 FAX (910) 455-1933 Jacksonville, Nc 28540-6269 ==============================================================================
Subject: Re: (usr-tc) Office Connect....Doesn't
From: Paul M. Oster <devious@minot.com>
Date: 1999-06-26 10:45:39
What are you using for authentication? I dont really buy it, but it might be worth experimenting with something else for example, try adding the user to the ARCS or Netservers, if it works, its something with the auth program, if not, its something else that is flakey (the OC's)... have you tried calling 3com about it? You'll have to leave a message and get a call back about them (wonderfull support there 3com)... and make 'em conference you with a TC tech too... Paul M. Oster <devious@minot.com> http://www.minot.com/ Magic Internet Services (701) 838-1265 Minots FIRST Internet Connection -=**=--=**=--=**=--=**=--=**=--=**=--=**=--=**=--=**=- "I might not agree with what you have to say but I will defend, to my death, your right to say it." - Voltaire On Fri, 25 Jun 1999, Greg Owens wrote: > I wish!!!!!.....These OC's were donated by the Gates Center to several rural > libraries in our area as a grant. They will not allow me to even touch any > of the setting on them much less upgrade the code. They say they have a unit > that is logging into a ISP running 3Com equipment with no problem. I was > hoping that I might have over looked something since it doesn't even appear > to attempt log on....They have told me it is my authentication program. I > don't by that.......Any other suggestions???????? > -----Original Message----- > From: Paul M. Oster <devious@minot.com> > To: usr-tc@lists.xmission.com <usr-tc@lists.xmission.com> > Date: Friday, June 25, 1999 9:28 AM > Subject: Re: (usr-tc) Office Connect....Doesn't > > > > > > > > Hrm... I had a similar problem... upgrade the code on the OC... I had a > >OCRDA do the same thing. > > > >Paul M. Oster <devious@minot.com> http://www.minot.com/ > >Magic Internet Services (701) 838-1265 > >Minots FIRST Internet Connection > > > >-=**=--=**=--=**=--=**=--=**=--=**=--=**=--=**=--=**=- > > > >"I might not agree with what you have to say but I will defend, to > >my death, your right to say it." - Voltaire > > > >On Thu, 24 Jun 1999, Greg Owens wrote: > > > >> Need some advice here. It appears (according to the people at 3Com) that > our > >> system is the only one in the world that a brand new 3Com Office Connect > box > >> will not connect with. I have a company that is attempting to use 5 of > these > >> through out their organization and none will connect (They are just using > it > >> as a analog 56k dial up connection). The people with 3Com can't even get > one > >> to log in with us. We have upgraded all our Hyper equipment and DSP cards > to > >> latest codes (No Help) I attempted to capture a ppp session with it but > >> never received anything from the office connect box to capture. We use > >> CT-1's if it matters. Anyone have any suggestions? Is there something I > need > >> to have enabled that I might not? They are using a different provider > right > >> now but will switch to us if we can get this to work. Any help would be > >> greatly appreciated. Thanks in advance > >> Greg Owens > >> Magnolia Internet Services > >> http://www.magnolia-net.com > >> > >> > >> - > >> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > >> with "unsubscribe usr-tc" in the body of the message. > >> For information on digests or retrieving files and old messages send > >> "help" to the same address. Do not use quotes in your message. > >> > > > > > >- > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >
Subject: (usr-tc) Connection errors
From: K Mitchell <mitch@keyconn.net>
Date: 1999-06-26 13:31:21
Using NT4/SP4 w/ 3Com S&A Server 6.0.90 for authentication. I started having problems last week after a new tech messed with some S&A Server settings in the RADIUS Clients fields. After some time with 3Com support, service was restored, but a new problem has sprouted up. A number of customers are now unable to log on, usually getting a "Check your password" error, although the password has been verified to be correct. Some of these have worked fine after deleting their account in S&A Server and adding it again, others continue having problems. The only thing showing up in the S&A Server Events log is a security breach from the ARC IP address. Current code on the chassis is; ARC 4.1.59-6 DSP 1.2.60 NMC 6.1.17 I've re-entered the secret in both instances of port 1645 in the RADIUS Clients section of S&A, as well as through the ARC console. Any ideas? Thanks, Kirk -- Kirk Mitchell-General Manager mitch@keyconn.net Keystone Connect Unlock Your World Altoona, PA 814-941-5000 http://www.keyconn.net
Subject: (usr-tc) Modem call failure reason
From: Paul Farber <farber@admin.f-tech.net>
Date: 1999-06-27 06:06:54
hello all Been trapping the call failure reason of 6 DSP cards and the connect fail reason is ALWAYS = 0. I looked in the "Modem Disconnect and Fail to Connect Reason Reference" and 0 is not listed. It starts a 1. Is this a bug? Or am I in the wrong doc's? there is a note before the table starts about increasing the value by 1 in the syslog.. which would make 0=1 and 1=dtrDrop. BUT the dtrDrop note says it only applies to the RS-232 NIC interface.. I have DSP/Pri's. enterprises.usr.nas.mdm.mdmCs.mdmCsTable.mdmCsEntry.mdmCsConnectFailReason.1 = 0 Paul D. Farber II Farber Technology Ph. 570-628-5303 Fax 570-628-5545 farber@admin.f-tech.net
Subject: (usr-tc) Problem with 1.2.37 (fwd)
From: Brian <signal@shreve.net>
Date: 1999-06-28 15:51:19
I posted the below message a little while back, I can't believe no one else is seeing isdn second channel problems with 1.2.37? What code versions are you all running? How about that 2.x stuff, are their any major issues with that? I would go back to 1.2.43 but that munged password problem is more than I want to deal with. Brian Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881) ---------- Forwarded message ---------- Reply-To: usr-tc@lists.xmission.com I have been having a very hard time getting connects, especially dual channel between Pipeline P50 (6.0.10) and the USR TC with 1.2.37. Does anyone know if an issue exists? I think someone at 3com should try a dual channel connection to a chassis running 1.2.37/4.1.59 -6. We are running with: enable ppp offloading disable ppp receive_accm I tried with ppp offloading disabled, and although at first it seemed to work (5 2-channel connects in a row), it no longer does. I dialed in 50 times for good measure, and only got dual channel 2 times. The P50 is set for perm switched. But it would appear that when only 1 of the 2 channels fails, it does not persistantly try to connect, anyone know how to acheive that on a p50? Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881) - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.
Subject: (usr-tc) NOTICE - EdgeServer Pro v2.5 Release (posting complete)
From: William Brien <william_brien@mw.3com.com>
Date: 1999-06-28 17:14:34
(notice forwarded from 3Com TotalControl mailing list at totalcontrol@totalservice.nsd.usr.com - subscription information listed below) 3Com Customers, 3Com would like to announce the release of EdgeServer Pro v2.5 on the TotalService website at: http://totalservice.3com.com/ The Software Compatibility Matrix on TotalService will be updated later this week to reflect compatibility with other releases of code. PLEASE READ THE RELEASE NOTES BEFORE UPGRADING ANY EDGESERVER VERSIONS TO VERSION 2.5. Important information is documented within the Release Notes to assure a smooth upgrade to EdgeServer version 2.5, and certain steps are CRITICAL to a successful installation. This EdgeServer code release has been tested and verified with HiPerDSP code version 1.2.37, with a maximum of seven spans at one time. Once compatible code becomes available on the 2.0.x tree for HiPerDSP, notice will be sent out to CSO and code will be posted to TotalService, and this restriction on the total number of spans will be removed. Span support is also dependent on the amount of system resources. As a general rule, 3 spans can run per 64 MB RAM, but this rule is dependent on what protocols are in use, and what other functions the EdgeServer Pro is performing. Download of this code requires a valid service contract. If you would like to purchase a service contract, please contact your local reseller of 3Com services for more information. To locate your local Value Added Reseller, as well as 3Com sales offices, please go to: http://www.3com.com/products/shop/where2buy_2.html If there are any questions or concerns regarding this System Release, please contact 3Com Technical Support toll-free at 1-800-231-8770. If you are calling from an area not handled by this number, the TotalService website has contact information for other countries and regions. Please go to the TotalService website and click on 'Contacting Tech Support' for more information. Thank you, Will Brien Customer Service Product Planning William_Brien@3com.com (3Com User Forum information available at http://totalservice.3com.com/cgi-bin/w3com/start?totalservice+forumlink )
Subject: (usr-tc) Connection errors
From: K Mitchell <mitch@keyconn.net>
Date: 1999-06-28 18:51:18
Using NT4/SP4 w/ 3Com S&A Server 6.0.90 for authentication. I started having problems last week after a new tech here messed with some S&A Server settings in the RADIUS Clients fields. After some time with 3Com support, service was restored, but a new problem has sprouted up. A number of customers are now unable to log on, usually getting a "Check your password" error, although the password has been verified to be correct. Some of these have worked fine after deleting their account in S&A Server and adding it again, others continue having problems. The only thing showing up in the S&A Server Events log is a security breach from the ARC IP address. Current code on the chassis is; ARC 4.1.59-6 DSP 1.2.60 NMC 6.1.17 I've re-entered the secret in both instances of port 1645 in the RADIUS Clients section of S&A, as well as through the ARC console. Any ideas? Thanks, Kirk -- Kirk Mitchell-General Manager mitch@keyconn.net Keystone Connect Unlock Your World Altoona, PA 814-941-5000 http://www.keyconn.net
Subject: (usr-tc) Old problem -- New fix???? Dead air
From: Terry Kennedy <terry@olypen.com>
Date: 1999-06-29 09:05:29
Dsp's running any code ( at least all that I have tried ) keep giving grief. When the racks are close to being filled, ie.. when we don't have that many modems left that are on hook, customers get dead air. This has been discussed before I know. And round robin hunting helps if you have spare modems. But when things get busy -- dead air. The next call will usually go fine. Am I right to think that the phone company is resetting the lines before the modem can reset? If so what's the fix here? I really don't buy the "have a bunch of spare modems in the hunt group fix" Althogh I'm sure this work, I should be able to use what I have, reliably... Anybody? Any clues?
Subject: (usr-tc) Idle timeouts
From: Randy Cosby <dcosby@infowest.com>
Date: 1999-06-29 11:21:40
I'm getting complaints from our users from time-to-time about disconnects during downloads, usually after around 20 minutes. Guess what? Our idle-timeout is set to 20 minutes. Does the HiperARC start the idle timer after each connection, or does it start when there is no activity on any connections? The small bit of evidence I have so far seems to indicate the HiperARC, much like Windows 95 has a problem with idle times not being reset by activity, but only with new connections. I'll research it further. Anyone else seeing similar behavior?
Subject: (usr-tc) FS: Dual PRI/T1 card
From: C Thompson <cthompson@wingnet.net>
Date: 1999-06-29 11:22:42
Just curious if anyone out there is interested in purchasing a Dual PRI/T1 card set. If so, please send offers by e-mail. Craig Thompson WingNET Internet Services, P.O. Box 3000 // Cleveland, TN 37320-3000 423-559-LINK (v) 423-559-5444 (f) http://www.wingnet.net Never wrestle with a pig. You both get dirty, and the pig likes it.
Subject: (usr-tc) FS: Dual PRI/T1 card
From: C Thompson <cthompson@wingnet.net>
Date: 1999-06-29 11:22:42
Just curious if anyone out there is interested in purchasing a Dual PRI/T1 card set. If so, please send offers by e-mail. Craig Thompson WingNET Internet Services, P.O. Box 3000 // Cleveland, TN 37320-3000 423-559-LINK (v) 423-559-5444 (f) http://www.wingnet.net Never wrestle with a pig. You both get dirty, and the pig likes it.
Subject: Re: (usr-tc) Idle timeouts
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1999-06-29 13:34:15
Thus spake Randy Cosby >I'm getting complaints from our users from time-to-time about disconnects >during downloads, usually after around 20 minutes. Guess what? Our >idle-timeout is set to 20 minutes. >Does the HiperARC start the idle timer after each connection, or does it >start when there is no activity on any connections? The small bit of >evidence I have so far seems to indicate the HiperARC, much like Windows 95 >has a problem with idle times not being reset by activity, but only with new >connections. I'll research it further. Anyone else seeing similar >behavior? If, by "connection" you mean an end to end TCP connection, no, it doesn't/shouldn't have anything to do with the idle timer on the Arc. The Arc just sees IP packets coming across the connection to the best of my knowledge...it doesn't have any knowledge of whether those IP packets are TCP SYN, ACK, RST, or whatever packets, so it would have no way of knowing if there has been a new TCP connection started up or not. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456
Subject: RE: (usr-tc) How to check Bandwidth/HiperArc
From: Jason Cropper <jason@clearsail.net>
Date: 1999-06-29 14:36:52
Yeah, getting a customer's bandwidth usage into MRTG would be excellent! Jason > -----Original Message----- > From: owner-usr-tc@lists.xmission.com > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of John Verreault > Sent: Tuesday, June 29, 1999 13:48 > To: usr-tc@lists.xmission.com > Subject: (usr-tc) How to check Bandwidth/HiperArc > > > How can I check the instantaneous bandwidth used by a connection on a > HiperArc Card. > > Is there an equivalent to a show interface on a cisco? > > Thanks > John > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >
Subject: Re: (usr-tc) How to check Bandwidth/HiperArc
From: Jason W. <jwatkins@iland.net>
Date: 1999-06-29 14:44:55
You could use 'show int slot:?/mod:? counters' It will give you this type of output. INTERFACE slot:2/mod:1 COUNTERS INPUT COUNTERS Octets: 43597902 Ucast: 728289 MultiCast: 0 BroadCast: 0 Discards: 150 Errors: 0 Unknown Prot: 0 OUTPUT COUNTERS Octets: 360550476 Ucast: 783604 MultiCast: 0 BroadCast: 0 Discards: 0 Errors: 0 Out QLen: 0 Hope this helps. ***************************************** Jason Watkins jwatkins@iland.net I-Land NOC Tech, Q2 Admin http://www.iland.net ***************************************** Fast, Dependable Access! ***************************************** ----- Original Message ----- Sent: Tuesday, June 29, 1999 1:47 PM > How can I check the instantaneous bandwidth used by a connection on a > HiperArc Card. > > Is there an equivalent to a show interface on a cisco? > > Thanks > John > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >
Subject: (usr-tc) How to check Bandwidth/HiperArc
From: John Verreault <verreaul@aei.ca>
Date: 1999-06-29 14:47:47
How can I check the instantaneous bandwidth used by a connection on a HiperArc Card. Is there an equivalent to a show interface on a cisco? Thanks John
Subject: (usr-tc) Totally-No-Service
From: Brian <signal@shreve.net>
Date: 1999-06-29 15:00:33
Is anyone getting "no service" from "totalservice.usr.com"? I login, it shows the TCS 3.5 code as UNLOCKED, and yet trying to get the files just gives error. If I try to ftp directly in, I notice it shows no permissions for me to get the files, despite the fact that via the web it's shown unlocked................. I am trying to get 2.0.81 hdm code and 6.1.17 16MB nmc code. Brian Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)
Subject: Re: (usr-tc) How to check Bandwidth/HiperArc
From: Jason W. <jwatkins@iland.net>
Date: 1999-06-29 15:22:21
You could use MRTG to graph the specific interfaces... Here is an example from running MRTG's cfgmaker utility on one of our HiPer Chassis Target[hiper-chassis.1513]: 1513:community@hiper-chassis MaxBytes[hiper-chassis.1513]: 3900 Title[hiper-chassis.1513]: hiper-chassis (): GWC Modem Driver PageTop[hiper-chassis.1513]: <H1>Traffic Analysis for GWC Modem Driver </H1> <TABLE> <TR><TD>System:</TD><TD>hiper-chassis in Sedalia</TD></TR> <TR><TD>Maintainer:</TD><TD>Jason Watkins NOC</TD></TR> <TR><TD>Interface:</TD><TD>GWC Modem Driver (1513)</TD></TR> <TR><TD>IP:</TD><TD> ()</TD></TR> <TR><TD>Max Speed:</TD> <TD>3900.0 Bytes/s (rs232)</TD></TR> </TABLE> You can get MRTG from http://ee-staff.ethz.ch/~oetiker/webtools/mrtg/mrtg.html Hope this helps. ***************************************** Jason Watkins jwatkins@iland.net I-Land NOC Tech, Q2 Admin http://www.iland.net ***************************************** Fast, Dependable Access! ***************************************** ----- Original Message ----- Sent: Tuesday, June 29, 1999 3:10 PM > Thanks, > > But I would like to be able to get an average over time 5,15,30 minutes or > current (instantaneous) usage as opposed to a total. > > john > > > -----Original Message----- > > From: owner-usr-tc@lists.xmission.com > > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Jason W. > > Sent: Tuesday, June 29, 1999 3:45 PM > > To: usr-tc@lists.xmission.com > > Subject: Re: (usr-tc) How to check Bandwidth/HiperArc > > > > > > You could use 'show int slot:?/mod:? counters' > > It will give you this type of output. > > > > INTERFACE slot:2/mod:1 COUNTERS > > INPUT COUNTERS > > Octets: 43597902 > > Ucast: 728289 > > MultiCast: 0 > > BroadCast: 0 > > Discards: 150 > > Errors: 0 > > Unknown Prot: 0 > > OUTPUT COUNTERS > > Octets: 360550476 > > Ucast: 783604 > > MultiCast: 0 > > BroadCast: 0 > > Discards: 0 > > Errors: 0 > > Out QLen: 0 > > > > Hope this helps. > > > > ***************************************** > > Jason Watkins jwatkins@iland.net > > I-Land NOC Tech, Q2 Admin > > http://www.iland.net > > ***************************************** > > Fast, Dependable Access! > > ***************************************** > > > > > > ----- Original Message ----- > > From: John Verreault <verreaul@aei.ca> > > To: <usr-tc@lists.xmission.com> > > Sent: Tuesday, June 29, 1999 1:47 PM > > Subject: (usr-tc) How to check Bandwidth/HiperArc > > > > > > > How can I check the instantaneous bandwidth used by a connection on a > > > HiperArc Card. > > > > > > Is there an equivalent to a show interface on a cisco? > > > > > > Thanks > > > John > > > > > > > > > - > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > with "unsubscribe usr-tc" in the body of the message. > > > For information on digests or retrieving files and old messages send > > > "help" to the same address. Do not use quotes in your message. > > > > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >
Subject: RE: (usr-tc) How to check Bandwidth/HiperArc
From: John Verreault <verreaul@aei.ca>
Date: 1999-06-29 16:10:17
Thanks, But I would like to be able to get an average over time 5,15,30 minutes or current (instantaneous) usage as opposed to a total. john > -----Original Message----- > From: owner-usr-tc@lists.xmission.com > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Jason W. > Sent: Tuesday, June 29, 1999 3:45 PM > To: usr-tc@lists.xmission.com > Subject: Re: (usr-tc) How to check Bandwidth/HiperArc > > > You could use 'show int slot:?/mod:? counters' > It will give you this type of output. > > INTERFACE slot:2/mod:1 COUNTERS > INPUT COUNTERS > Octets: 43597902 > Ucast: 728289 > MultiCast: 0 > BroadCast: 0 > Discards: 150 > Errors: 0 > Unknown Prot: 0 > OUTPUT COUNTERS > Octets: 360550476 > Ucast: 783604 > MultiCast: 0 > BroadCast: 0 > Discards: 0 > Errors: 0 > Out QLen: 0 > > Hope this helps. > > ***************************************** > Jason Watkins jwatkins@iland.net > I-Land NOC Tech, Q2 Admin > http://www.iland.net > ***************************************** > Fast, Dependable Access! > ***************************************** > > > ----- Original Message ----- > From: John Verreault <verreaul@aei.ca> > To: <usr-tc@lists.xmission.com> > Sent: Tuesday, June 29, 1999 1:47 PM > Subject: (usr-tc) How to check Bandwidth/HiperArc > > > > How can I check the instantaneous bandwidth used by a connection on a > > HiperArc Card. > > > > Is there an equivalent to a show interface on a cisco? > > > > Thanks > > John > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >
Subject: (usr-tc) Some HDM warnings
From: Brian <signal@shreve.net>
Date: 1999-06-29 21:08:14
I have done alot of testing with hdm code here, and just wanting to post some warnings to the list about some 1.2.x code: 1.2.43 - corrupts last char of PAP passwords, with no pattern that I can see. happens at random, but happens enough (we see hundreds every few days). Users will complain of having to dial multiple times before they get on. Its hard to chase this down, 3com even had trouble for more than a month with this one. Trust me, it exists, its evil. 1.2.37 - Serious MPP issues. I am not sure why but the bundles just get fscked up. I am not talking about MPIP alone here, I am talking PPP bundles in general. *very* reproducable with Ascend P50 and latest 6.1.x code (no stac compression). Also have seen this on Netgear RT328's. Once again an evil bug. 1.2.37 does not have the password corruption bug of 1.2.43. 2.0.81 in initial testing here, seems to not have either bugs. Still looking for what it may have. I would be interested in hearing any issues anyone has seen with 2.0.81. Also, FWIW, we have found 4.1.59-6 to be very stable arc code, and would definitly recommend anyone to get on that code if you are having problems. 4.0.x code had some nasty memory leaks, and their were some serious problems in many of the 4.1.x releases as well. Just my 2 cents. Brian Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)
Subject: Re: (usr-tc) Merit Radius (livingston 2.1 with USR)
From: Peter Evans <peter@gol.com>
Date: 1999-06-30 00:58:46
Ricky Beam (jfbeam@bluetopia.net) wrote: > On Sun, 20 Jun 1999, Peter Evans wrote: > >> Wed Jun 16 14:32:09 1999: generate26: USR attribute 0 unknown > >> Wed Jun 16 14:32:09 1999: gen_valpairs: non-encapsulated vendor specific > >> attribute Vendor-Specific=vUSR-0000902300000015 > > This is caused by USR/3com not putting in a (IMHO redundant) > > length field as per the RFC in question. I had this problem > > a while back. > Actually, strictly speaking, USR didn't break the RFC. It's "vendor specific" > which means they can put what ever they want to in there. RFC suggests > putting a standard attribute within the data of the vendor specific attribute. > You'll notice their vendor attribute numbers are 16 bit -- and left space > for full 32 bit numbers. (They don't need to specify a size as everything > after the attribute number is data.) ah. must re-read the rfc. havent looked at it since I last hacked the radius code ... same lame-o fix works fine in the release version of livingston radius 2.1 (running on freebsd 2.blef) all I need to do now is get the latest VSA list and zoom! P -- My words, my mail, my meaning. "Linux is only free if your time has no value"
Subject: (usr-tc) Access to NMC
From: Scot Desort <scot@njaccess.net>
Date: 1999-06-30 08:38:54
I am new to the TC platform. I have a HiperARC and NMC in the chassis. I pre-configured the equipment on my local network, and when I was complete, I changed all of the ethernet interface addresses to the network where my dialup is located. Well, I must have messed something up with the NMC -- I cannot connect to it in any manner. I can connect to the HiperARC just fine. This equipment is located in a remote location, so getting to it with a laptop is difficult. Can I connect, in some way, to the NMC _through_ the Hiperarc? Do they communicate in any way where I can check/change the IP address assigned to NMC while telnetted into the Hiperarc?? Or, am I goning to have to make a trip out there to console into the NMC to change the IP? Thx ...Scot
Subject: Re: (usr-tc) Access to NMC
From: Brian <signal@shreve.net>
Date: 1999-06-30 09:05:59
On Wed, 30 Jun 1999, Scot Desort wrote: > I am new to the TC platform. I have a HiperARC and NMC in the chassis. I > pre-configured the equipment on my local network, and when I was complete, I > changed all of the ethernet interface addresses to the network where my > dialup is located. > > Well, I must have messed something up with the NMC -- I cannot connect to it > in any manner. I can connect to the HiperARC just fine. This equipment is > located in a remote location, so getting to it with a laptop is difficult. > > Can I connect, in some way, to the NMC _through_ the Hiperarc? Do they > communicate in any way where I can check/change the IP address assigned to > NMC while telnetted into the Hiperarc?? Or, am I goning to have to make a > trip out there to console into the NMC to change the IP? If you cannot ping the nmc, then you are S.O.L., make your trip and bring a console cable. Brian > > Thx > > ...Scot > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)
Subject: Re: (usr-tc) Access to NMC
From: Brian <signal@shreve.net>
Date: 1999-06-30 09:05:59
On Wed, 30 Jun 1999, Scot Desort wrote: > I am new to the TC platform. I have a HiperARC and NMC in the chassis. I > pre-configured the equipment on my local network, and when I was complete, I > changed all of the ethernet interface addresses to the network where my > dialup is located. > > Well, I must have messed something up with the NMC -- I cannot connect to it > in any manner. I can connect to the HiperARC just fine. This equipment is > located in a remote location, so getting to it with a laptop is difficult. > > Can I connect, in some way, to the NMC _through_ the Hiperarc? Do they > communicate in any way where I can check/change the IP address assigned to > NMC while telnetted into the Hiperarc?? Or, am I goning to have to make a > trip out there to console into the NMC to change the IP? If you cannot ping the nmc, then you are S.O.L., make your trip and bring a console cable. Brian > > Thx > > ...Scot > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)
Subject: (usr-tc) FS: 002106-0 HiPer DSP cards set of 4, Only $12,000
From: Greg Genge <greg@dynavar.com>
Date: 1999-06-30 10:26:31
These are 2106-0 Hiper DSP Cards, warranty, latest code. Call me at 403-571-5003 for details or email greg@dynavar.com. We can deliver anywhere in US or Canada. $12,000 gets you 4 cards. Must take 4 at a time. No resellers please. End users only. Limited quantities available. Regards, Greg Genge Gregory F. Genge, President, Dynavar Networking, Inc. Toll Free 877-Dynavar (Canada and US) (403) 571-5000 Main, 5003 Direct, 5005 Fax, http://www.dynavar.com #300, 1550 - 5th Street S.W., Calgary, Alberta, Canada, T2R-1K3 Ascend, 3Com (USRobotics), Alteon, Cisco, Lucent (Livingston), WatchGuard, Cacheflow, Foundry, Breezecom, Redback Networks, Shiva, Adtran, Compatible, Microcom (Compaq), Garrett, Sonic, Cobalt.
Subject: RE: (usr-tc) Access to NMC
From: Steve Valiunas <steve_valiunas@mw.3com.com>
Date: 1999-06-30 13:36:35
If you were using TCM to change the IP info then you had to "save UI to EEPROM", not just save to NVRAM. Steve "Scot Desort" <scot@njaccess.net> on 06/30/99 01:10:56 PM Please respond to usr-tc@lists.xmission.com Sent by: "Scot Desort" <scot@njaccess.net> cc: (Steve Valiunas/MW/US/3Com) Thanks Brian. I had a feeling that was the case. I KNOW I changed the IP address using TCM and saved the changes. I don't know why it's not even answering a ping. ...Scot > -----Original Message----- > From: owner-usr-tc@lists.xmission.com > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Brian > Sent: Wednesday, June 30, 1999 10:06 AM > To: usr-tc@lists.xmission.com > Cc: usr-tc@xmission.com > Subject: Re: (usr-tc) Access to NMC > > > On Wed, 30 Jun 1999, Scot Desort wrote: > > > I am new to the TC platform. I have a HiperARC and NMC in the chassis. I > > pre-configured the equipment on my local network, and when I > was complete, I > > changed all of the ethernet interface addresses to the network where my > > dialup is located. > > > > Well, I must have messed something up with the NMC -- I cannot > connect to it > > in any manner. I can connect to the HiperARC just fine. This > equipment is > > located in a remote location, so getting to it with a laptop is > difficult. > > > > Can I connect, in some way, to the NMC _through_ the Hiperarc? Do they > > communicate in any way where I can check/change the IP address > assigned to > > NMC while telnetted into the Hiperarc?? Or, am I goning to have > to make a > > trip out there to console into the NMC to change the IP? > > If you cannot ping the nmc, then you are S.O.L., make your trip and bring > a console cable. > > Brian > > > > > > Thx > > > > ...Scot > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > ----------------------------------------------------- > Brian Feeny (BF304) signal@shreve.net > 318-222-2638 x 109 http://www.shreve.net/~signal > Network Administrator ShreveNet Inc. (ASN 11881) > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.
Subject: RE: (usr-tc) Access to NMC
From: Scot Desort <scot@njaccess.net>
Date: 1999-06-30 14:10:56
Thanks Brian. I had a feeling that was the case. I KNOW I changed the IP address using TCM and saved the changes. I don't know why it's not even answering a ping. ...Scot > -----Original Message----- > From: owner-usr-tc@lists.xmission.com > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Brian > Sent: Wednesday, June 30, 1999 10:06 AM > To: usr-tc@lists.xmission.com > Cc: usr-tc@xmission.com > Subject: Re: (usr-tc) Access to NMC > > > On Wed, 30 Jun 1999, Scot Desort wrote: > > > I am new to the TC platform. I have a HiperARC and NMC in the chassis. I > > pre-configured the equipment on my local network, and when I > was complete, I > > changed all of the ethernet interface addresses to the network where my > > dialup is located. > > > > Well, I must have messed something up with the NMC -- I cannot > connect to it > > in any manner. I can connect to the HiperARC just fine. This > equipment is > > located in a remote location, so getting to it with a laptop is > difficult. > > > > Can I connect, in some way, to the NMC _through_ the Hiperarc? Do they > > communicate in any way where I can check/change the IP address > assigned to > > NMC while telnetted into the Hiperarc?? Or, am I goning to have > to make a > > trip out there to console into the NMC to change the IP? > > If you cannot ping the nmc, then you are S.O.L., make your trip and bring > a console cable. > > Brian > > > > > > Thx > > > > ...Scot > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > ----------------------------------------------------- > Brian Feeny (BF304) signal@shreve.net > 318-222-2638 x 109 http://www.shreve.net/~signal > Network Administrator ShreveNet Inc. (ASN 11881) > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >
Subject: Re: (usr-tc) Access to NMC
From: Ahmed Saeed <ahmed.saeed@widener.edu>
Date: 1999-06-30 15:37:08
Scot, When you say that you can not connect to the nmc is it via tcm, wan port, or just ping? In any case, the hiper arc enables you to configure the snmp settings. But there is no way of direct telnetting into the hyper arc and then getting a prompt for the nmc- this functionality does exist with the hdm's. Also, if you can not connect via snmp only, check the community strings. Ahmed On Wed, 30 Jun 1999, Scot Desort wrote: > I am new to the TC platform. I have a HiperARC and NMC in the chassis. I > pre-configured the equipment on my local network, and when I was complete, I > changed all of the ethernet interface addresses to the network where my > dialup is located. > > Well, I must have messed something up with the NMC -- I cannot connect to it > in any manner. I can connect to the HiperARC just fine. This equipment is > located in a remote location, so getting to it with a laptop is difficult. > > Can I connect, in some way, to the NMC _through_ the Hiperarc? Do they > communicate in any way where I can check/change the IP address assigned to > NMC while telnetted into the Hiperarc?? Or, am I goning to have to make a > trip out there to console into the NMC to change the IP? > > Thx > > ...Scot > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >
Subject: Re: (usr-tc) Access to NMC
From: Ahmed Saeed <ahmed.saeed@widener.edu>
Date: 1999-06-30 15:37:08
Scot, When you say that you can not connect to the nmc is it via tcm, wan port, or just ping? In any case, the hiper arc enables you to configure the snmp settings. But there is no way of direct telnetting into the hyper arc and then getting a prompt for the nmc- this functionality does exist with the hdm's. Also, if you can not connect via snmp only, check the community strings. Ahmed On Wed, 30 Jun 1999, Scot Desort wrote: > I am new to the TC platform. I have a HiperARC and NMC in the chassis. I > pre-configured the equipment on my local network, and when I was complete, I > changed all of the ethernet interface addresses to the network where my > dialup is located. > > Well, I must have messed something up with the NMC -- I cannot connect to it > in any manner. I can connect to the HiperARC just fine. This equipment is > located in a remote location, so getting to it with a laptop is difficult. > > Can I connect, in some way, to the NMC _through_ the Hiperarc? Do they > communicate in any way where I can check/change the IP address assigned to > NMC while telnetted into the Hiperarc?? Or, am I goning to have to make a > trip out there to console into the NMC to change the IP? > > Thx > > ...Scot > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >
Subject: (usr-tc) FS: 3COM 002092-0 HiPer DSP cards set of 4, Only $12,000
From: Greg Genge <greg@dynavar.com>
Date: 1999-06-30 17:18:51
These are 2092-0 Hiper DSP Cards, warranty, latest code. Call me at 403-571-5003 for details or email greg@dynavar.com. We can deliver anywhere in US or Canada. $12,000 gets you 4 cards and 96 ports of Brand New in package Modems. Must take 4 at a time. No resellers please. End users only. Limited quantities available. Regards, Greg Genge Gregory F. Genge, President, Dynavar Networking, Inc. Toll Free 877-Dynavar (Canada and US) (403) 571-5000 Main, 5003 Direct, 5005 Fax, http://www.dynavar.com #300, 1550 - 5th Street S.W., Calgary, Alberta, Canada, T2R-1K3 Ascend, 3Com (USRobotics), Alteon, Cisco, Lucent (Livingston), WatchGuard, Cacheflow, Foundry, Breezecom, Redback Networks, Shiva, Adtran, Compatible, Microcom (Compaq), Garrett, Sonic, Cobalt.
Subject: (usr-tc) Global Village, iMac modems
From: Michael DeMan <michael@prf.org>
Date: 1999-06-30 17:42:16
Hi, We're having some awful problems with iMacs and Global Village modems connecting. Some seem to be okay and others get 24,000 and 26,400 connects. This is subscriber line problems since they can get into AOL and others at high speed. Are there any settings on our Hiper DSP units that we can fiddle with to help get these connect speed numbers up and more reliable? Thanks, - Mike
Subject: RE: (usr-tc) Access to NMC
From: Mike Andrews <mandrews@termfrost.org>
Date: 1999-06-30 18:20:03
You're not supposed to be able to telnet to an NMC. The only way to get to the command prompt is via the console port. (And like you said, if you can't ping it, that's the only way into it.) About all they speak is SNMP. You could hook the NMC's console port to, say, the aux port of a Cisco and set it up to telnet to that, though -- that's what we do for the (few) times we actually need the menu interface for anything. Mike Andrews (MA12) -=-=- VP & Sysadmin, Digital Crescent, Frankfort KY mandrews@dcr.net -=- mandrews@termfrost.org -=- http://www.termfrost.org "If you're not part of the solution.... you're part of the precipitate." On Wed, 30 Jun 1999, Scot Desort wrote: > Cannot connect via any remote measure -- telnet or tcm. Won't answer a ping. > > Steve hit it on the head -- I did not select save to eeprom... > > > -----Original Message----- > > From: owner-usr-tc@lists.xmission.com > > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Ahmed Saeed > > Sent: Wednesday, June 30, 1999 3:37 PM > > To: usr-tc@lists.xmission.com > > Cc: usr-tc@xmission.com > > Subject: Re: (usr-tc) Access to NMC > > > > > > Scot, > > When you say that you can not connect to the nmc is it via tcm, wan port, > > or just ping? > > In any case, the hiper arc enables you to configure the snmp settings. > > But there is no way of direct telnetting into the hyper arc and then > > getting a prompt for the nmc- this functionality does exist with the > > hdm's. > > > > Also, if you can not connect via snmp only, check the community strings. > > > > > > Ahmed
Subject: RE: (usr-tc) Access to NMC
From: Scot Desort <scot@njaccess.net>
Date: 1999-06-30 18:20:10
Cannot connect via any remote measure -- telnet or tcm. Won't answer a ping. Steve hit it on the head -- I did not select save to eeprom... > -----Original Message----- > From: owner-usr-tc@lists.xmission.com > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Ahmed Saeed > Sent: Wednesday, June 30, 1999 3:37 PM > To: usr-tc@lists.xmission.com > Cc: usr-tc@xmission.com > Subject: Re: (usr-tc) Access to NMC > > > Scot, > When you say that you can not connect to the nmc is it via tcm, wan port, > or just ping? > In any case, the hiper arc enables you to configure the snmp settings. > But there is no way of direct telnetting into the hyper arc and then > getting a prompt for the nmc- this functionality does exist with the > hdm's. > > Also, if you can not connect via snmp only, check the community strings. > > > Ahmed >
Subject: RE: (usr-tc) Access to NMC
From: Brian <signal@shreve.net>
Date: 1999-06-30 21:19:48
> You could hook the NMC's console port to, say, the aux port of a Cisco and > set it up to telnet to that, though -- that's what we do for the (few) > times we actually need the menu interface for anything. Hmm, can't you hook the nmc console port to a port on the arc/netserver and do this as well? > > > Mike Andrews (MA12) -=-=- VP & Sysadmin, Digital Crescent, Frankfort KY > mandrews@dcr.net -=- mandrews@termfrost.org -=- http://www.termfrost.org > "If you're not part of the solution.... you're part of the precipitate." > > > On Wed, 30 Jun 1999, Scot Desort wrote: > > > Cannot connect via any remote measure -- telnet or tcm. Won't answer a ping. > > > > Steve hit it on the head -- I did not select save to eeprom... > > > > > -----Original Message----- > > > From: owner-usr-tc@lists.xmission.com > > > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Ahmed Saeed > > > Sent: Wednesday, June 30, 1999 3:37 PM > > > To: usr-tc@lists.xmission.com > > > Cc: usr-tc@xmission.com > > > Subject: Re: (usr-tc) Access to NMC > > > > > > > > > Scot, > > > When you say that you can not connect to the nmc is it via tcm, wan port, > > > or just ping? > > > In any case, the hiper arc enables you to configure the snmp settings. > > > But there is no way of direct telnetting into the hyper arc and then > > > getting a prompt for the nmc- this functionality does exist with the > > > hdm's. > > > > > > Also, if you can not connect via snmp only, check the community strings. > > > > > > > > > Ahmed > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)
Subject: (usr-tc) hdm passwd
From: Brian <signal@shreve.net>
Date: 1999-06-30 21:38:06
after changing the hdm password from the cli, how do you save it? or is it saved automatically? Brian Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)
Subject: RE: (usr-tc) Access to NMC
From: Blake Fithen <fithen@networksplus.com>
Date: 1999-07-01 00:38:57
I seem to always have this exact problem. I never made the time to diagnose the problem but to fix it I usually save to NVRAM on the NMC console menu, reset the NMC, then everything is OK. BEFORE resetting the NMC from the console menu I can't ping the NMC from anywhere but the ARC command line. After I reset - no problems. I can depend on this behavior with every new NMC or when wiping a chassis clean and starting over. blake > -----Original Message----- > From: Ahmed Saeed [mailto:Ahmed.Saeed@widener.edu] > Sent: Wednesday, June 30, 1999 2:37 PM > To: usr-tc@lists.xmission.com > Cc: usr-tc@xmission.com > Subject: Re: (usr-tc) Access to NMC > > > Scot, > When you say that you can not connect to the nmc is it via > tcm, wan port, > or just ping? > In any case, the hiper arc enables you to configure the snmp > settings. > But there is no way of direct telnetting into the hyper arc and then > getting a prompt for the nmc- this functionality does exist with the > hdm's. > > Also, if you can not connect via snmp only, check the > community strings. > > > Ahmed > > On Wed, 30 Jun 1999, Scot Desort wrote: > > > I am new to the TC platform. I have a HiperARC and NMC in > the chassis. I > > pre-configured the equipment on my local network, and when > I was complete, I > > changed all of the ethernet interface addresses to the > network where my > > dialup is located. > > > > Well, I must have messed something up with the NMC -- I > cannot connect to it > > in any manner. I can connect to the HiperARC just fine. > This equipment is > > located in a remote location, so getting to it with a > laptop is difficult. > > > > Can I connect, in some way, to the NMC _through_ the > Hiperarc? Do they > > communicate in any way where I can check/change the IP > address assigned to > > NMC while telnetted into the Hiperarc?? Or, am I goning to > have to make a > > trip out there to console into the NMC to change the IP? > > > > Thx > > > > ...Scot > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old > messages send > > "help" to the same address. Do not use quotes in your message. > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >
Subject: RE: (usr-tc) Access to NMC
From: Blake Fithen <fithen@networksplus.com>
Date: 1999-07-01 00:38:57
I seem to always have this exact problem. I never made the time to diagnose the problem but to fix it I usually save to NVRAM on the NMC console menu, reset the NMC, then everything is OK. BEFORE resetting the NMC from the console menu I can't ping the NMC from anywhere but the ARC command line. After I reset - no problems. I can depend on this behavior with every new NMC or when wiping a chassis clean and starting over. blake > -----Original Message----- > From: Ahmed Saeed [mailto:Ahmed.Saeed@widener.edu] > Sent: Wednesday, June 30, 1999 2:37 PM > To: usr-tc@lists.xmission.com > Cc: usr-tc@xmission.com > Subject: Re: (usr-tc) Access to NMC > > > Scot, > When you say that you can not connect to the nmc is it via > tcm, wan port, > or just ping? > In any case, the hiper arc enables you to configure the snmp > settings. > But there is no way of direct telnetting into the hyper arc and then > getting a prompt for the nmc- this functionality does exist with the > hdm's. > > Also, if you can not connect via snmp only, check the > community strings. > > > Ahmed > > On Wed, 30 Jun 1999, Scot Desort wrote: > > > I am new to the TC platform. I have a HiperARC and NMC in > the chassis. I > > pre-configured the equipment on my local network, and when > I was complete, I > > changed all of the ethernet interface addresses to the > network where my > > dialup is located. > > > > Well, I must have messed something up with the NMC -- I > cannot connect to it > > in any manner. I can connect to the HiperARC just fine. > This equipment is > > located in a remote location, so getting to it with a > laptop is difficult. > > > > Can I connect, in some way, to the NMC _through_ the > Hiperarc? Do they > > communicate in any way where I can check/change the IP > address assigned to > > NMC while telnetted into the Hiperarc?? Or, am I goning to > have to make a > > trip out there to console into the NMC to change the IP? > > > > Thx > > > > ...Scot > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old > messages send > > "help" to the same address. Do not use quotes in your message. > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >
« May 1999July 1999 »
USR Total Control Mailing List Archive · Messages from 1995–2001 · Generated from archived data