test post

February 12th, 2010

this is a test post from the official s60 word client

  • Share/Bookmark

HTTP Error Codes

November 7th, 2008

If you have ever had to troubleshoot an HTTP error code, you know how frustrating the process can be. Oftentimes, these cryptic codes can have multiple meanings and can leave you scratching your head. In my experience, HTTP errors fall into three main categories: problems with the user’s device, problems with the Web server, and connectivity problems. The real key to troubleshooting HTTP problems effectively is to figure out which of these categories the problem falls into. In this series of articles, I will show you how.

HTTP status codes

The key to understanding the problem at hand is to know a little bit about HTTP status codes. Any time a client issues an HTTP request to a Web server, the server returns a response code. These response codes are organized into five categories.

100 Series codes
HTTP status codes ranging from 100 to 199 are informational codes. Running into these codes is a fairly rare occurrence for a couple of reasons. First, if a browser is attempting to access a website and these codes are returned, they are usually not displayed onscreen. They are simply internal codes for the browser’s reference. The other reason these types of codes are fairly rare is that the original HTTP specification did not allow status codes in this range. As such, they are still not widely used.

200 Series codes
Status codes ranging from 200 to 299 are success codes. Again, you will probably never see these codes displayed on screen during a normal Web surfing session. Instead, these codes are used internally by the browser as a way of confirming the success and the current status of a request. Although these codes are not normally displayed, there are troubleshooting tools available that can read them, and like most other HTTP status codes, they can be invaluable in the diagnostic process.

300 Series codes
Status codes in the 300 to 399 range are redirection codes. Essentially, they tell the Web browser that some other action must be performed in order to fulfill the request. Depending on the nature of this action, it may be performed automatically, or it may require additional user input. For example, status code 301 indicates that a particular resource has been permanently moved and that all future calls to the resource should be directed to a specific URL.

400 Series codes
Status codes in the 400 range are considered to be client error codes. These kinds of error codes are often security related. For example, if a client attempts to access a resource that it is not authorized to access, the server will return a status code of 401. Similarly, if the client attempts to access an unauthorized resource, and the client’s authentication status makes no difference to the situation, then the server may return a status code of 403, indicating that access to the resource is forbidden.

400 level error codes can also be returned if the request is malformed or if the client times out. The one 400-level code that is often misleading, though, is 404. Although this code is technically classified as a client side error, it can actually represent an error on either the client or on the server. The error simply indicates that the requested resource was not found. When this error occurs on the client side, it is often an indication of network connectivity problems. At other times, the error may occur because a resource was removed from the server or was renamed.

500 Series codes
500 level status codes represent server errors. For example, if a Web server times out, it will produce a 504 error. Often, though, a 500-level error does not represent a problem with a server but rather with the Web application that is running on the server. For example, my own personal website is coded in ASP, which dynamically generates HTML pages. During the debugging process, there were many times when buggy code caused my Web server to return HTTP status code 500, which is a generic code indicating an internal server error. This code simply means that something went wrong, and HTTP does not know how to deal with it.
 

This information was recieved form the article posted on Search Networking http://searchnetworking.techtarget.com/tip/0,289483,sid7_gci1337654,00.html?track=NL-379&ad=672035&asrc=EM_NLT_4925320&uid=18645

  • Share/Bookmark

Juniper IVE LDAP and AD

August 19th, 2008

Tips for Active Directory LDAP intergration on Juniper IVEOS

Admin DN: CN-Admin,CN=Users,DC=example,dc=com

Password: Password

Finding user entries

Base DN: DC=example,DC=com

Filter: samaccountname=

Determining group membership

Base DN: DC=example,DC=com

Filter: CN=

Member Attribute: memberOf

To enable users to manages passwords you must use an LDAPS connection to your LDAP server.

  • Share/Bookmark

NAT-T

August 1st, 2008

UDP Port 4500 = NAT-T draft 2
UDP Port 500 = NAT-T draft 0

If using NAT-T negotiations then Agressive Mode should be used unless NAT is staitc

used get ike cookie to see the NAT-T Map.

debug ike natt – for debugging NAT-T

  • Share/Bookmark

Troubleshooting Juniper Netscreen VPNS

July 30th, 2008

http://kb.juniper.net/KB9238 – How to Analyze IKE Phase 1 Messages in the Event Logs
Reference: http://kb.juniper.net/KB9231 – How to Analyze IKE Phase 2 Messages in the Event Logs

debug ike

Used when the VPN is not being established

debug flow basic
Used when traffic is not passing through the firewall
Used to investigate vpn monitor failures
Good to confirm packets are being sent/received

get sa-filter
get ffliter = flow filter
get debug

get event – check vpn monitor messages and negotiation failures.
get route – check the route to the tunnel interface.
get int – check status of tunnel interface.

get ike cookie – used to confirm P1 SA’s
get sa – used to confirm P2 SA’s
get sa
active – used to check tunnels that are in “Active”

see KB6134 for info on how to see in a VPN Tunnel SA is active.

get sa id 0x – get more detailed information about the SA

get sa stat – shows statistics for each SA

clear ike – used to force both P1 and P2 renegotiations, causes a complete tear down of the tunnel.

clear sa 0x – causes tear down of the P2 only.


set sa-fil <ip> – filter for debug ike
debug ike detail
debug auth all – for authentication if being used
set console dbuf
set ff src-ip <ipaddrA> dst-ip <ip-addrB>
ip address of outermost ip header coming into the firewall
set ff src-ip <ipaddrB> dst-ip <ip-addrA> ip address of outermost ip header coming into the firewall
debug flow basic
clear db

<perform problematic activity>
undebug all
get db stream
get session src-ip
get session dst-ip
get counter stat

  • Share/Bookmark

Netscreen Route Based VPN vs Policy Based VPNs

July 30th, 2008

Route-based
Uses routing information to send traffic across VPN
You route your traffic to a tunnel interface.
There is only one IPSec SA per VPN
Proxy-id is 0.0.0.0/0 unless explicitly configured.
It allows dynamic routing protocols to be used via the VPN.
It is limited by number of routes or tunnel interfaces.
It is a good choice for interconnecting large networks.
And is more flexible to configure than Policy Based.

Policy-based
It uses policy information to send traffic.
It uses the “tunnel” action in the policy to route traffic
It has one IPSec SA for each policy.
The Proxy-id is derived from source and destination addresses/ports specified in the policy.
It is not possible to use Dynamic Routing protocols.
It is limited by the number of policies
Juniper say it is a good choice for dial-up VPN clients. However I personally think that route-based vpns are far better for all type of VPN.

See KB4124 for further information on the difference between Route Based and Policy based VPN’s.

get sa active to see the active SA’s on a device. If the PID is -1 then it is a route based vpn.

  • Share/Bookmark

Juniper LKG file

July 29th, 2008

Juniper LKG is also know as the Last-Known-Good File.
The file is created by issuing the the command save config to last-known-good

  • Share/Bookmark

NSRP Config Sync

July 29th, 2008

exec nsrp sync global-config checksum
Check result on console or issue a get log sys

See KB6359 for how to check Active/Passive NSRP Pair configs are in sync.

Get config global of each unit and compare the files.

Also hidden command exec nsrp sync global-config diff this shows the differences line by line.

To synch the config issue exec nsrp sync global-config save (Please note this appends to the existing config on the box you are issuing the command from) it is recommended to unset all before synching.

Issue set nsrp config sync to make sure the config sync is enabled.

Another option is to manually edit the config file in a text editor and then save it to the flash and reset the unit.

See KB6351 for how to synchronise the configuration.

After the save do a reset and answer n if asked to save the configuration.

Issue the checksum again and then a get log sys | in configuration and check the checksum values.

  • Share/Bookmark

NSRP Counters

July 28th, 2008

get nsrp counter protocol

This gives detailed information about the NSRP heartbeat and state changes for each VSD group.

In Normal Conditions hb_tx should equal hb_rx . If not issue a “clear nsrp counter” and check again a few times.

get NSRP counter rto

This give information about the RTO’s. Shows all RTO’s being exchanged between the units in the Cluster.

Look for items in the DROP column and investigate the item referenced.

get nsrp counter packet-fwd

Can be used to check usage of the data link

  • Share/Bookmark

One Hundred Pushups in 6 weeks

July 16th, 2008

This is a handy program that aims to get you from 0 to 100 pushup in 6 weeks by only spending about 30 minutes a week on it.

one hundred push ups

Technorati Tags: , ,

  • Share/Bookmark