this is a test post from the official s60 word client
test post
February 12th, 2010HTTP Error Codes
November 7th, 2008If 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
Juniper IVE LDAP and AD
August 19th, 2008Tips 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.
NAT-T
August 1st, 2008Troubleshooting Juniper Netscreen VPNS
July 30th, 2008http://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 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
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
Netscreen Route Based VPN vs Policy Based VPNs
July 30th, 2008Route-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.
Juniper LKG file
July 29th, 2008NSRP Config Sync
July 29th, 2008exec 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.
NSRP Counters
July 28th, 2008get 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
One Hundred Pushups in 6 weeks
July 16th, 2008This 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.