Windows:

To capture the entire screen, press your PrintScreen key on the keyboard. You can then open a Word Document or Microsoft Paint and choose Edit > Paste, or try pressing Control-V

To capture a single window, press Alt-PrintScreen. You can then paste this into Word or Paint also (Outlook works as well if you have it).

To capture a part of the screen in Windows 7, click on the Start Menu, then Programs, then Accessories, then Snipping Tool. If you use this frequently, right click on Snipping Tool and choose Pin to Start Menu. With the snipping tool, click the New button, and then select the area of your screen you would like to capture. You can then save this using the File menu in Snipping Tool.

Macintosh OSX:

The easiest one to remember (since remembering all the different key shortcuts can be a bother, especially if you switch between Mac and Windows frequently), is Command-Shift-4. This will allow you to select an area of the screen, and it will automatically save it to your desktop (typically). You can then do whatever you like with it (upload it to your blog, Facebook, Flickr, Picasa, WordPress or other), or insert it into a document.

PHP Freelancer

This is what an iMac looks like with the lcd screen removed.  Visible are the fans, hard drive, RAM memory slots and other innards

PHP Freelancer

Reposted form supportforums.cisco.com

How to properly and safely collect debugs on an IOS router

Prepared By Steve Holl, CCIE#22739

Purpose

Is running debugs safe to do on production routers?

I don’t think I need this; I debug to a syslog server.

Why can’t I just log to the monitor with ‘terminal monitor’?

Recommended configuration

What do these commands do?

How do I run these debugs?

What debugs should I be running?

How do I collect the debugs?

How do I disable debugs?

What do I do if the router is too busy, and I can’t pull debugs for an issue before the log overwrites itself?

Purpose:

It is quite often that someone is concerned about running debugs on a production gateway, thinking that it may cause performance impact. The purpose of this document is to de-mystify and clarify these conceptions.

If you don’t want to understand the concepts and want to just know what  commands to enter, just use the ‘Recommended Configuration’ section  below.

Is running debugs safe to do on production routers?

Debugs can be run safely in almost all environments where voice runs on an IOS router.  That being said, due diligence is recommended when turning debugs on in production, so keep an eye on ‘show processor cpu history’ when enabling debugs one-at-a-time to ensure there is minimal impact

To prove the point that it is safe to run IOS debugs in production with this recommended configuration, I am able to run ‘debug all’ (yes, that’s every debug IOS is capable of running) in my lab on a CME with 300 registered phones and only bring the CPU impact up by 40%, when default rate limiting and queuing are enabled.  I’d never recommend enabling ‘debug all’ in any real-life circumstance since the majority of the messages will be rate limited and dropped before being logged, but it demonstrates how effective disabling the console/monitor and rate/queue limiting allow for verbose debugs to run stable on a busy router.  Typically only 10-20% CPU overhead is needed for even the most verbose debugs.

I don’t think I need this; I debug to a syslog server.

In my experience, 80% of the time I receive debugs from a syslog server, they contain dropped messages and render an accurate analysis impossible; one can observe this behavior when sequence numbers are enabled on the IOS side.  This is because syslog is UDP by default, and the messages usually end up being rate-limited heavily.  There are ways to debug to the syslog more reliably (use TCP for syslog, or Reliable Delivery and Filtering via BEEP) but those concepts are outside the scope of this document.

Why can’t I just log to the monitor with ‘terminal monitor’?

We want to debug to the log to prevent any debug messages which are sent in bursts from being dropped.  For example, an H.245 debug may have 40-50 lines of debugs all arriving at the same millisecond, and is usually too fast for the monitor to print out and large chuncks of the debug output will end up missing from the screen output.  By logging to the buffer, we eliminate scenarios where the terminal monitor would have dropped messges.

Recommended Configuration:

Router(config)# service sequence-numbers
Router(config)# service timestamps debug datetime localtime msec
Router(config)# logging buffered 10000000 debug
Router(config)# no logging console
Router(config)# no logging monitor

Router(config)# default logging rate-limit

Router(config)# default logging queue-limit

Router(config)# voice iec syslog

<Enable debugs, then wait for issue to occur.>

…

<Enable session capture to txt file in terminal program.>

Router# terminal length 0

Router# show logging

What do these commands do?

Now we will run down through each of these commands and explain how they behave, since scenarios may dictate some deviation from this template.

service timestamps debug datetime localtime msec- Ensures that local router time is written to all debugs, with millisecond accuracy.  This is useful for finding calls based on time.  Generally speaking, millisecond times allow for you to group debug lines into logical related events when two lines occur within the same millisecond.

logging buffered 10000000 debug- Tells the router to send debugs to its local buffer log in system memory.  The buffer size is set in bytes, and is 10 MB here.  The size of the buffer which you may need depends upon call volume, duration of time the buffer needs to store, system memory still available (leverage ‘show memory statistic history’ and ‘show memory summary’ for this)

no logging console- By default, the router sends debugs to the console.  In IOS, the console has the highest priority out of any process.  It also runs at very slow speeds (commonly 9600bps).  Due to this, if debugs are sent to the router faster than the console speed, it can starve console input, and/or cause the CPU to go to 100%.

To alleviate this behavior, when running any debugs in IOS, it is imperative that sending debugs to the console is disabled by entering this command

no logging monitor- This command prevents the router from sending debugs in real-time to the router’s VTY (telnet/SSH) session.  Since we will be pulling debugs reactively, we don’t want anything to scroll in real-time.  Also, the terminal monitor has a habit of dropping messages if they arrive in bursts, like most voice debugs do.

default logging rate-limit- By default, the router does rate limit messages.  This is usually recommended to be left on to ensure router stability.  If a TAC engineer suspects that the router is dropping debugs before they make it to the router’s logging buffer, they may ask this to be increased to a larger value or disabled.  Note that changing this in environments with high traffic volume may cause CPU instability, since it will ensure every debug message makes it to the logging buffer.

default logging queue-limit- By default, the router does queue messages, as well.  There is a finite amount of memory the router will store in queue while waiting to be written to the logging buffer.  This is usually recommended to be left on to ensure router stability.  If a TAC engineer suspects that the router is dropping debugs before they make it to the router’s logging buffer, they may ask this to be increased to a larger value or disabled.  Note that changing this in busy environments may cause CPU instability for the same reasons as mentioned previously.

service sequence-numbers- This command writes the sequence number of the debug in the line.  This is useful (essentially required) when sending to a syslog server,  to identify if any debug messages to the syslog server have been  dropped in the network.  The sequence number will be the first item in  the debug, before the timestamp and actual message.  Note that this is  different from the timestamp/sequence number may write on the syslog log  files, if applicable.

001033:  *Apr 27 14:29:25.867: %IPPHONE-6-REG_ALARM: NAME=SEP000A10000075  Load=P00308000500 Parms=Status/IPaddr  Last=CM-closed-TCP

Note that sequence numbers are written after

rate-limiting, so they won’t be useful to identify if IOS is dropping debugs before writing them to the buffer log.

voice iec syslog- This command prints out extra information in scenarios where the router is the origin of a disconnect.  This is specific to voice, and is useful to TAC engineers.

%VOICE_IEC-3-GW: C SCRIPTS: Internal Error (Incompatible protocols): IEC=1.1.47.11.23.0 on callID 31102

The ouput can be decoded with:

Router# show voice iec description 1.1.47.11.23.0

IEC Version: 1
Entity: 1 (Gateway)
Category: 47 (no resource (47))
Subsystem: 11 (C SCRIPTS)
Error: 23 (Incompatible protocols)
Diagnostic Code: 0

How do I run these debugs?

Once you have the debugs setup, enable the relevant debugs which have been requested to you by the TAC engineer, CSC member, or via the Multiservice Voice Debug Lookup tool.

What debugs should I be running?

While we are talking about how to collect debugs, you may wonder what debugs you should collect to troubleshoot your call issues.  We have a very useful tool to assist you with this, called the Multiservice Voice Debug Lookup.

Personally, here is what I like to collect as a starting point for the common call failures across IOS gateways:

H.323

debug voip ccapi inout

debug h225 asn1

debug h245 asn1

debug cch323 all

debug ip tcp transaction

SIP

debug voip ccapi inout

debug ccsip messages

debug voip rtp session named-event

MGCP

debug voip ccapi inout

debug mgcp packet

debug ip tcp transaction

<Be sure to enable appropriate POTS debugs, too.>

ISDN

debug voip ccapi inout

debug isdn q931

Analog or Non-ISDN POTS

debug voip ccapi inout

debug vpm signal

How do I collect the debugs?

Once you have the buffer configured and debugs enabled, it will write all output to the buffer.  The buffer is a rolling buffer, so when you reach the limit of the defined buffer size, then the oldest information at the top of the buffer is removed to make way for the newest information to be added at the bottom of the log.

After the issue occurs, issue ‘terminal length 0′ to prevent having to hit <enter> or <space> every page.  Then, issue ‘show logging’ and the current buffer content will dump to the screen.  Telnet is preferred over console connections due to faster transmission capability.  Ideally, have your terminal application that runs on your desktop configured to log all of this session’s terminal output to a local .txt file.  My favorite applications for this are PuTTy or SecureCRT.  Mac’s Terminal application handles large buffers very well, and select all/copy/paste into notepad after the log is dumped to the screen work best for me there.

How do I disable debugs?

After debugs have been collected for an issue, you can disable them all with:

Router# undebug al

This isn’t necessary, but if you want to restore synchronous logging to the console and VTY sessions, enable them again with:

Router(config)# logging console
Router(config)# logging monitor

What do I do if the router is too busy, and I can’t pull debugs for an issue before the log overwrites itself?

There are some advanced techniques we have in TAC by using TCL and EEM to leverage this issue, if necessary.  Consult TAC if you feel this step is necessary.

PHP Freelancer

reposted from Wired.com

HTC Edge, World’s First Quad-Core Android Phone, Revealed

Mike is a Wired.com staff writer covering Google and the mobile beat. He’s written on a number of different tech topics, from startups to social media. Check out his Google+ profile here.
Follow @mj_isaac and @GadgetLab on Twitter.

PHP Freelancer

This will sometimes occur after software updates, if you do not reboot your computer semi-regularly,
or if one or more VPN dependent services on your computer have stopped responding.

Possible Solution:
Try typing one of the following lines into Terminal (depending on your version of OSX, one of these may or may not work on your computer):

sudo /System/Library/StartupItems/CiscoVPN/CiscoVPN restart

sudo kextload /System/Library/Extensions/CiscoVPN.kext

sudo SystemStarter restart CiscoVPN
If the problem persists, try running a Disk Permissions Repair next.
Go to Applications > Utilities > Disk Utility, select your Macintosh HD, choose the First Aid tab, and click the Repair Disk Permissions button in that window.

If this still does not solve your problem, and if you have the original installer or disk image .dmg file, try uninstalling and re-installing the VPN Client.
You may need to (carefully) delete Cisco VPN app from /Applications/ as well as related files and folders inside of /Library/Application Support/, /Library/LaunchDaemons/, /Library/LaunchAgents/, /Library/Preferences/, /Library/Caches/ as well as the previous folders inside of /Users/username/Library/Application Support/, etc…

PHP Freelancer

on the Cisco.com website and in their help files, that my blood pressure surely rises considerably. I decided to make a short write-up explaining how to change the number of rings before a call will go to voicemail. It is actually measured by a timer in seconds, rather than a number of rings specifically.

I was simply trying to find a help document that would show me how to change the amount of time or number of rings before a call is directed to voicemail with Cisco Unity Connection Manager 8 or Cisco Unified CM Administration. In my case I am using System version: 8.0.3.20000-2

When I searched the help files, all I found was a ‘description.’ No place in the description indicated where this setting would be configured. I had to search exhaustively on the internet (Google) and the best I could find was a configuration example for an old version, which fortunately used the same menu and parameter names.

Here is my write-up for anyone else that may wish to adjust this setting. Hopefully they will find my page without having to look for it on the Cisco website….

which is completely TERRIBLE.

TERRIBLE trying to find information.

Really Cisco, you are awful and need to work on making your help documents easier to find.

Here is my write-up:

1. Log into your Unity CM Administration server through the web login http://[your-server-ip-address]

2. Open the System menu and go to Service Parameters

3. Select your Call Manager server from the Server drop-down menu

4. Select Cisco Call Manager (Active) from the Service drop-down menu

4. Scroll down the page and look for Clusterwide Parameters (Feature – Forward)

5. In my case the default setting was 12 (seconds) between the time a call starts ringing and the time it is directed to voicemail. Change this to a different number according to your preferences.

6. Click the Save button at the top or bottom of the page.

According to Cisco’s website (with an older configuration example), you do not need to restart Call Manager for these settings to take effect.

PHP Freelancer

Check it out here on Amazon.com:

PHP Freelancer

Also mentioned is the possibility of adding 4 and 5 finger multi-touch capabilities.
Here is the original article:

Apple Fixing iPhone 4S Battery Problem, Other User Issues

By Daniel Ionescu, PCWorld    Nov 5, 2011 7:47 AM

PHP Freelancer

It’s fairly elaborate and complicated (if that explanation is not redundant).
But I will attempt to distill it down to its basics.

The Short Version:

——————————
The internet is made up of computers and routers.
-Some computers (like yours) retrieve web pages from the internet.
-Other computers (called “web servers”, store these web pages, and send them to your computer when your computer requests them.
-Routers have the job of passing these web pages back and forth from your computer to the one with the website on it. The web server actually stores the page on it’s hard drive, and it sends a temporary copy of the information on that page to your computer when you try to go to it’s website.

The Longer Version:

———————————
Your Computer:
Has an IP address (which is unique* like a postal address, think of a room number, inside of a building at a street number, inside of a city with a zip code inside of a country). Your computer sends and receives data (like a postal letter or postcard) using this IP address. It might look something like 192.168.1.1. All devices that transmit and receive data (almost all) have an IP address (they change sometimes, but they still need to have an address). This address is usually regulated by an organization called IANA. They make the rules regarding what IP addresses everyone is allowed to have, and internet service providers (like Time Warner, Verizon and AT&T) are given the responsibility of assigning individual numbers to individual customers, so that they can get on the internet (like you).

Web Servers:
Also have an IP address. Many times they are fixed addresses that do not change, whereas your computer’s address may change from time to time (the explanation is not important to this topic).

Routers:
If you have ever tinkered much with your computer at home or had internet problems, you might have seen a number like 192.168.1.1 (or something close). Your computer might even have this IP address exactly. *But, if you were to talk to friends of yours, you might discover that their computer has the same IP address. Routers actually must have two IP addresses, since one side of the router connects to your internet service provider or ISP (like Verizon) and the other side of your router connects to your computer. The side that connects to your computer might have the IP address 192.168.1.2, and the side of your router connected to your ISP might have the address 123.123.123.123. Your router does the translating between the two different addresses so that web pages can be sent from your computer to the internet, and from the internet to your computer.

When you try to view a website like Google.com:
1. Your computer contacts a special kind of server called a DNS server and says: I, with the address 123.123.123.123 (just an example), would like Google.com, but I don’t know the IP address of Google.com. The DNS server’s IP address might be 4.2.2.2
2. The DNS server replies: computer with the IP address 123.123.123.123, I am 4.2.2.2, you can find Google.com at 72.14.204.147.
3. Your computer then contacts 72.14.204.147 and says: I, with the IP address 123.123.123.123 would like to view your web page.
4. Google’s web server replies: I, with the IP address 72.14.204.147 am sending my web page’s data to the computer with the IP address 123.123.123.123.
5. Your computer receives this data and knows to interpret it using your web browser, which might be Firefox, Chrome, Internet Explorer or Safari.

So, if you and your friend both have computers with an IP address of 192.168.1.1,
how can two different computers have the same IP address if they are supposed to be unique ?

IANA has two kinds of IP addresses.

One kind of IP address, called a private IP address, is used only inside your home and on your side of your router. This number is actually translated into a different number (that IS actually unique in the world) by your internet router or modem. This is done partly because there would not be enough IP addresses in the world for every device on earth to have a unique “IP version 4″ address. So they re-use some of these numbers. This is exactly like two office buildings, which both have a room 105. The room number 105 is only important inside that building, if you tried to send a postcard from the post office and only included the information ‘Room 105,” it would be impossible for anyone to know where to send it. Your internet router or modem keeps track of this and has a way of knowing which room (or private IP address) to send a web page to. So, for your computer to send and receive data on the internet, your router must be the translator, go-between or proxy.

The second kind of IP address used by IANA is called a public IP address. This address is unique and only one of each address exists on earth (except in some cases which include hacking and spoofing). When your computer requests a web page from a web server, the web server is really sending the page back to your router’s public IP address. Your router keeps track of the fact that your computer’s private IP address asked for that web page at that public IP address, and knows to send it back to your computer, and not another computer connected to your router.

Here is a more complicated, but more specific version of our first scenario:

1. Your computer, at 192.168.1.1 asks to see Google.com
2. Your router takes this request and translates 192.168.1.1 into 123.123.123.123 and asks a DNS server what Google.com’s IP address is.
3. The DNS server replies to your router, Google.com is at 72.14.204.147.
4. Your router asks 72.14.204.147 for it’s web page
5. Google.com at 72.14.204.147 sends the web page data back to your router 123.123.123.123
6. Your router remembers that your computer at 192.168.1.1 asked for Google.com and sends Google.com’s data to 192.168.1.1

Here is an even longer version

————————————————-

Your computer communicates using a few additional numbers in addition to an IP address.
Each computer’s wireless or wired network card has something called a MAC address.
This might look like AB:12:EC:65:34:DF
These numbers are unique, but are only used to send data from one device to the next one in the chain.  So your computer’s MAC address has no significance to Google.com’s web server, only your router is aware of your MAC address and uses it.
There is also a number called a port. Ports are used for a few purposes.

When your computer asks Google.com’s web server for it’s page, it sends its request to 72.14.204.147 destination port 80.
Ports 80 and 443 are designated as world wide web (WWW) traffic (http and https) and are always used for website traffic. Ports are also used in the source address from your computer. When your computer sends a request, it sends this using a source MAC address, a source IP address and a source port. The source port is a randomly generated number, and the destination port depends what kind of data it’s requesting. Web servers always listen for web page requests on ports 80 and 443. They will then send this information back to your computer at the same port your computer sent the request from.

Here is the same scenario at our current level of detail (we will ignore MAC addresses right now):

1. Your computer asks to view Google.com’s website.
Your computer sends a ‘packet’ (a chunk of data that makes up the request for the website) to your router
coming from 192.168.1.1 Port 65100
going to (your router, a.k.a. “default gateway”) 192.168.1.2 Port 80

2. Your router (by proxy) sends this web page request
coming from 123.123.123.123 Port 64501
going to 72.14.204.147 Port 80

3. Google sends a reply
coming from 72.14.204.147 Port 80
going to 123.123.123.123 Port 64501

4. Your router translates this address and forwards this packet to your computer
coming from 192.168.1.2 Port 80
going to 192.168.1.1 Port 65100

If you are really really curious to learn more about how this works, you can study for the CompTIA Network+ exam or the Cisco CCENT exam. If you can pass these exams, then you most likely have a grasp of how packets are sent over the internet.

PHP Freelancer

I spent 5 years during college working as a ‘Product Specialist’ in a large electronics retail chain.  I worked hard to learn what I could about the digital cameras, computers and cellular phones that I sold.  There was a general impression among customers that I knew everything about my products (or that I should have known every detail about my products).

If I was only responsible for selling 5 different cameras and 2 different computers, I probably would have practically complete knowledge of them.

However, there were approximately 50 computers and just as many cameras in my area.  Also, these models would be replaced as often as 4 times per year (sometimes more).  Knowing every detail about all of the products was nearly impossible (and not at all reasonable for the amount of money paid to the employees).

So, with the expectation that we should know everything about everything, some of my coworkers would lie.  If they didn’t know the answer and felt like they might lose credibility with a customer for simply saying “I don’t know the answer to that,” they would make something up.  This happens a lot.  Even more often is the use of very general and vague terms.

Retail salespeople have a tough job, answering questions about products they are barely familiar with (and often cannot afford to buy for themselves and learn more about).  So, I wouldn’t be too hard on them personally.  Their managers have a difficult job as well, covering for employee mistakes and mishaps all day long, trying to appease tough customers who found every product in the store cheaper on the internet someplace who expects the store to sell it for the same price.

Salespeople are very often hired for their mannerisms, personality and appearance.  Actual technical knowledge is generally secondary.

From my experience, I have always been told that retail stores will never be as price-competitive as online stores, due to costs of running a physical building (heating, air conditioning, cleaning, cash registers, property tax, electricity).  Now, this is not to say that an online store (like Amazon.com) doesn’t have warehouses, employees, computer systems, heating and electricity bills…  So, I don’t personally know how the two compare, in terms of operating costs.  But this is what a manager in a retail store will likely tell you.  (But managers will make things up sometimes too, so you might not be able to believe everything you hear in that regard either).

I found an article on Gizmodo.com with the subject: Don’t charge your phone overnight.  The quandary in the article was whether charging your phone every night would shorten the lifespan of the battery, as opposed to waiting till the battery discharges (nearly) completely before plugging it in.  If you have an emergency just as your battery runs out of juice, and before you were going to plug it in, then I suppose you are in an unfortunate situation.

The writer of the article of such a large website would likely be regarded as an expert by a large number of readers.

In the article he does not appear to have any technical knowledge of the engineering behind lithium-ion batteries and cellular phone charging systems.  He states that he used the Motorola product manual and Verizon salespeople as sources for his information.  I know personally, that none of the salespeople I worked with in my store would have known anything about this, other than what their training manuals told them.  We sold Verizon phones and knew as much about them as dedicated Verizon representatives would.  There was very little technical engineering knowledge among the salespeople I worked with and personally knew (nothing against them personally).  The writer of the article updated (at the bottom) that he had provided bad information due to a conflict between the product manual and the salesperson’s provided knowledge.

The moral of the story is, you can’t trust everything you hear, even if the person may be regarded as an expert.

When you research information on the internet (on Google, web forums or other sources), it is best to follow the basic principle of referencing multiple sources.  If they all agree, you might have found your answer, if they don’t agree, then some may be right and some wrong, or they might all be wrong.  It’s always best to do your own research when possible, especially if it’s critical.  If it’s not critical, then it may not be worth worrying about much.

Life is too short to worry about things that aren’t important

reposted article from Gizmodo that was referenced above:

”

Giz Tip: Don’t Charge Your Phone Overnight

PHP Freelancer