Saturday, April 18, 2009
Friday, April 17, 2009
Qualys Inc - Final Round
How to check for the dependencies of a package?
SSH connection for the first time - Trusted Host ?
How to do it without prompting for a password
How SSH will store the keys at server side? How to add user ?
SSH as a root without password ?
md5 length and which algorithm it uses? how do u do it linux / windows
regex ! every time !!!!
How to fetch a name called any name containing patel from a text file
^[a-z]patel$
what is ^ and what is $
$ENV variable
CPAN and Object Oriented Perl
/etc/password content ?
where rpm packages are installed
how to add remove and force the older version of rpm package
nmap and nessus..how to give range and os fingerprinting option?
Version of each OS ?
Tuesday, April 14, 2009
Monday, April 13, 2009
Qualys Inc - QA Intern interview questions
how to check if rpm package is installed or not?
How to install and uninstall module?
how to check the bootscreen text?
how software gets installed in linux, windows..etc
how to edit the registry entry in windows using gui
Networking
Socket programming apis
TCP Connection establishment and close
Socket APIs
traceroute ? how it works and whatis the meaning of stars ???
path MTU ...what is the purpose ?
TCP header format , flags, every thing
Port numbers again and again
Sliding window algorithm n how to solve the problem if rx is dropping the packet (manually set the limit)
Security related
SQL injection - every single time.....
IP Governance
How to test Nessus
Programming
Sudo code of sniffer
Perl - regular expression
text substitution
fatching text and all that stuff...
Friday, April 3, 2009
Sunday, March 29, 2009
Twitter interview questions - Operation Engineer-Search
How to check the files been created within last hour
How to check the largest file in the directory
How to do recursive copy?
How to scp to multiple machine
What is a command for storing the output of tcpdump in ASCII format
Difference between du and df
ssh on different port
what is find ?
Perl : How to find the most repeated IP address from the Textfile
Friday, March 27, 2009
Difference between du and df
df - free disk space.
In some cases it is possible that there is a difference between the outcome of df and du.
In 99.9% of the cases this is caused by a lock on the file system. Meaning, if an application opens a file or files and an other application deletes these files while they are opened they will still be calculated by df.
The df command calculates this by looking at the inode table and the inode table has not yet released those files, meaning that, according to the inode table, the files are still using space on the disk.
Generally the solution is to stop/start the process that has a lock on those non existing files and the results returned by df and du will be the same again.
Tuesday, January 20, 2009
Windows Wireless Troubleshooting
1. Click Start, right-click My Computer, and then click Properties. The Windows operating system, the build number, and the latest installed service pack are listed under System on the General tab. Write down this information.
2. Write down the vendor of your wireless network adaptor and the model number.
3. Right-click the wireless network connection in the Network Connections folder, and then click Properties.
4. On the General tab, click Configure, and then click the Driver tab. Write down the following information for the driver:
* Version
* Date
* Provider
5. See the documentation that was supplied with your wireless access point to obtain the following information:
* Wireless access point vendor
* Model number of the wireless modem
* Wireless access point firmware version
6. If you used a wireless configuration tool to configure your wireless settings instead of using Windows XP, write down the tool name and the tool version number.
7. Write down the type of wireless network to which you are trying to connect. For example, you may be connecting to a private network at work, to a home network, or to a public wireless network.
8. Write down the settings that are configured for your wireless connection and for your wireless access point. For example, write down authentication and encryption settings.
The information that you have collected will help the PSS support engineer to identify the cause of the problem.
Sometimes, PSS support engineers must view log files that record the activity of Windows components. To collect the log files, follow these steps:
1. On the Windows XP desktop, click Start, click Run, type cmd, and then click OK.
2. At the command prompt, type netsh ras set tra * ena, and then press ENTER. This command enables tracing.
3. Restart your computer.
4. Note the time, and then reproduce your wireless problem. Write down how long it took you to reproduce the problem.
5. Move to the %windir%\Tracing folder. This folder should contain the following files:
Wzctrace.log
Eapol.log
Rastls.log
Wzcdlg.log
Xmlprovi.log
Netman.log
Netshell.log
Have these log files ready to send to PSS for analysis together with the time that it took you to reproduce the problem.
6. Click Start, click Run, type cmd, and then click OK.
7. To disable tracing, type netsh ras set tra * dis, and then press ENTER.
8. Restart your computer.
If your problem relates to the user interface, such as to a dialog box, obtain a screen shot of the user interface item. For example, if something looks incorrect in the View Available Networks dialog box, capture a screen shot of the dialog box that you can send to PSS. To do this, follow these steps:
1. Switch to the user interface that is incorrect, and then press ALT+PRINT SCREEN. This command copies the active window to the Clipboard.
2. Paste the screen shot into an e-mail message. You can also paste the screen shot into Paint, save the image as a file, and attach the file to an e-mail message.
PSS may also require status information for the Wireless Zero Configuration component or for the Wireless Configuration services. To obtain this status, follow these steps:
1. On the Windows desktop, click Start, click Run, type cmd, and then click OK.
2. At the command prompt, type sc query wzcsvc, and then press ENTER.
3. Capture a screen shot of the command output.
Sunday, January 18, 2009
Network Troubleshooting script
# Network testing script v 1.0
# (c) 2005 Javier Fernandez-Sanguino
#
# This script will test your system's network configuration using basic
# tests and providing both information (INFO messages), warnings (WARN)
# and possible errors (ERR messages) by checking:
# - Interface status
# - Availability of configured routers, including the default route
# - Proper host resolution, including DNS checks
# - Proper network connectivity (the remote host can be configured, see
# below)
#
# The script does not need special privileges to run as it does not
# do any system change. It also will not fix the errors by itself.
#
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program; if not, write to the Free Software
# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
#
# You can also find a copy of the GNU General Public License at
# http://www.gnu.org/licenses/licenses.html#TOCLGPL
#
# TODO
# - Works only on Linux, can this be generalised for other UNIX systems
# (probably not unless rewritten in C)
# - Does not check for errors properly, use -e and test intensively
# so that expected errors are trapped
# (specially for tools that are not available, like netcat)
# - If the tools are localised to languages != english the script might
# break
# - Ask 'host' maintainer to implement error codes as done with
# dlint
# - Should be able to check if DNS server is in the same network, if
# it doesn't answer to pings, check ARP in that case.
# - DHCP checks?
# - Other internal services tests? (LDAP if using pam...)
# - Generate summary of errors in the end (pretty report?)
# - Check if packets are being dropped by local firewall? (use dmesg
# and look for our tests)
# - Support wireless interfaces? (use iwconfig)
# - Check other TODOs inline in the code
# BEGIN configuration
# Configure to your needs, these values will be used when
# checking DNS and Internet connectivity
# DNS name to resolve
CHECK_HOST=www.debian.org
CHECK_IP_ADRESS=194.109.137.218
# Web server to check for
CHECK_WEB_HOST=www.debian.org
CHECK_WEB_PORT=80
export CHECK_HOST CHECK_IP_ADRESS CHECK_WEB_HOST CHECK_WEB_PORT
# END configuration
# Extract the interface of our default route
defaultif=`netstat -nr |grep ^0.0.0.0 | awk '{print $8}' | head -1`
defaultroutes=`netstat -nr |grep ^0.0.0.0 | wc -l`
if [ -z "$defaultif" ] ; then
defaultif=none
echo "WARN: This system does not have a default route"
elif [ "$defaultroutes" -gt 1 ] ; then
echo "WARN: This system has more than one default route"
else
echo "INFO: This system has exactly one default route"
fi
# Check loopback
check_local () {
# Is there a loopback interface?
if [ -n "`ip link show lo`" ] ; then
# OK, can we ping localhost
if ! check_host localhost 1; then
# Check 127.0.0.1 instead (not everybody uses this IP address however,
# although its the one commonly used)
if ! check_host 127.0.0.1 1; then
echo "ERR: Cannot ping localhost (127.0.0.1), loopback is broken in this system"
else
echo "ERR: Localhost is not answering but 127.0.0.1, check /etc/hosts and verify localhost points to 127.0.0.1"
fi
else
echo "INFO: Loopback interface is working properly"
fi
else
echo "ERR: There is no loopback interface in this system"
status=1
fi
status=0
return $status
}
# Check network interfaces
check_if () {
ifname=$1
status=0
[ -z "$ifname" ] && return 1
# Find IP addresses for $ifname
inetaddr=`ip addr show $ifname | grep inet | awk '{print $2}'`
if [ -z "$inetaddr" ] ; then
echo "WARN: The $ifname interface does not have an IP address assigned"
status=1
else
# TODO: WARN if more than 2 IP addresses?
echo $inetaddr | while read ipaddr; do
echo "INFO: The $ifname interface has IP address $ipaddr assigned"
done
fi
# Lookup TX and RX statistics
# TODO: This is done using ifconfig but could use /proc/net/dev for
# more readibility or, better, 'netstat -i'
txpkts=`ifconfig $ifname | awk '/RX packets/ { print $2 }' |sed 's/.*://'`
rxpkts=`ifconfig $ifname | awk '/RX packets/ { print $2 }' |sed 's/.*://'`
txerrors=`ifconfig $ifname | awk '/TX packets/ { print $3 }' |sed 's/.*://'`
rxerrors=`ifconfig $ifname | awk '/RX packets/ { print $3 }' |sed 's/.*://'`
# TODO: Check also frames and collisions, to detect faulty cables
# or network devices (cheap hubs)
if [ "$txpkts" -eq 0 ] && [ "$rxpkts" -eq 0 ] ; then
echo "ERR: The $ifname interface has not tx or rx any packets. Link down?"
status=1
elif [ "$txpkts" -eq 0 ]; then
echo "WARN: The $ifname interface has not transmitted any packets."
elif [ "$rxpkts" -eq 0 ] ; then
echo "WARN: The $ifname interface has not received any packets."
else
echo "INFO: The $ifname interface has tx and rx packets."
fi
# TODO: It should be best if there was a comparison with tx/rx packets.
# a few errors are not uncommon if the card has been running for a long
# time. It would be better if a relative comparison was done (i.e.
# less than 1% ok, more than 20% warning, over 80% major issue, etc.)
if [ "$txerrors" -ne 0 ]; then
echo "WARN: The $ifname interface has tx errors."
fi
if [ "$rxerrors" -ne 0 ]; then
echo "WARN: The $ifname interface has rx errors."
fi
return $status
}
check_netif () {
status=0
ip link show | egrep '^[[:digit:]]' |
while read ifnumber ifname status extra; do
ifname=`echo $ifname |sed -e 's/:$//'`
if [ -z "`echo $status | grep UP\>`" ] ; then
if [ "$ifname" = "$defaultif" ] ; then
echo "ERR: The $ifname interface that is associated with your defualt route is down!"
status=1
elif [ "$ifname" = "lo" ] ; then
echo "ERR: Your lo inteface is down, this might cause issues with local applications (but not necessarily with network connectivity)"
else
echo "WARN: The $ifname interface is down"
fi
else
# Check network routes associated with this interface
echo "INFO: The $ifname interface is up"
check_if $ifname
check_netroute $ifname
fi
done
return $status
}
check_netroute () {
ifname=$1
[ -z "$ifname" ] && return 1
netstat -nr | grep "${ifname}$" |
while read network gw netmask flags mss window irtt iface; do
# For each gw that is not the default one, ping it
if [ "$gw" != "0.0.0.0" ] ; then
if ! check_router $gw ; then
echo "ERR: The default route is not available since the default router is unreachable"
fi
fi
done
}
check_router () {
# Checks if a router is up
router=$1
[ -z "$router" ] && return 1
status=0
# First ping the router, if it does not answer then check arp tables and
# see if we have an arp. We use 5 packets since it is in our local network.
ping -q -c 5 "$router" >/dev/null 2>&1
if [ "$?" -ne 0 ]; then
echo "WARN: Router $router does not answer to ICMP pings"
# Router does not answer, check arp
routerarp=`arp -n | grep "^$router" | grep -v incomplete`
if [ -z "$routerarp" ] ; then
echo "ERR: We cannot retrieve a MAC address for router $router"
status=1
fi
fi
if [ "$status" -eq 0 ] ; then
echo "INFO: The router $router is reachable"
fi
return $status
}
check_host () {
# Check if a host is reachable
# TODO:
# - if the host is in our local network (no route needs to be used) then
# check ARP availability
# - if the host is not on our local network then check if we have a route
# for it
host=$1
[ -z "$host" ] && return 1
# Use 10 packets as we expect this to be outside of our network
COUNT=10
[ -n "$2" ] && COUNT=$2
status=0
ping -q -c $COUNT "$host" >/dev/null 2>&1
if [ "$?" -ne 0 ]; then
echo "WARN: Host $host does not answer to ICMP pings"
status=1
else
echo "INFO: Host $host answers to ICMP pings"
fi
return $status
}
check_dns () {
# Check the nameservers defined in /etc/resolv.conf
status=1
nsfound=0
nsok=0
tempfile=`mktemp tmptestnet.XXXXXX` || { echo "ERR: Cannot create temporary file! Aborting! " >&2 ; exit 1; }
trap " [ -f \"$tempfile\" ] && /bin/rm -f -- \"$tempfile\"" 0 1 2 3 13 15
cat /etc/resolv.conf |grep nameserver |
awk '/nameserver/ { for (i=2;i<=NF;i++) { print $i ; } }' >$tempfile
for nameserver in `cat $tempfile`; do
nsfound=$(( $nsfound + 1 ))
echo "INFO: This system is configured to use nameserver $nameserver"
check_host $nameserver 5
if check_ns $nameserver ; then
nsok=$(( $nsok +1 ))
else
status=$?
fi
done
#Could also do:
#nsfound=`wc -l $tempfile | awk '{print $1}'`
/bin/rm -f -- "$tempfile"
trap 0 1 2 3 13 15
if [ "$nsfound" -eq 0 ] ; then
echo "ERR: The system does not have any nameserver configured"
else
if [ "$status" -ne 0 ] ; then
if [ "$nsfound" -eq 1 ] ; then
echo -e "ERR: There is one nameserver configured for this system but it does not work properly"
else
echo "ERR: There are $nsfound nameservers configured for this system and none of them works properly"
fi
else
if [ "$nsfound" -eq 1 ] ; then
echo "INFO: The nameserver configured for this system works properly"
else
echo "INFO: There are $nsfound nameservers is configured for this system and $nsok are working properly"
fi
fi
fi
return $status
}
check_ns () {
# Check the nameserver using host
# TODO: use nslookup?
# nslookup $CHECK_HOST -$nameserver
nameserver=$1
[ -z "$nameserver" ] && return 1
status=1
CHECK_RESULT="$CHECK_HOST .* $CHECK_IP_ADDRESS"
# Using dnscheck:
dnscheck=`host -t A $CHECK_HOST $nameserver 2>&1 | tail -1`
if [ -n "`echo $dnscheck |grep NXDOMAIN`" ] ; then
echo "ERR: Dns server $nameserver does not resolv properly"
elif [ -n "`echo $dnscheck | grep \"timed out\"`" ] ; then
echo "ERR: Dns server $nameserver is not available"
elif [ -z "`echo $dnscheck | egrep \"$CHECK_RESULT\"`" ] ; then
echo "WARN: Dns server $nameserver did not return the expected result for $CHECK_HOST"
else
echo "INFO: Dns server $nameserver resolved correctly $CHECK_HOST"
status=0
fi
# Using dlint
# dlint $CHECK_HOST @$nameserver >/dev/null 2>&1
# if [ $? -eq 2 ] ; then
# echo "ERR: Dns server $nameserver does not resolv properly"
# elif [ $? -ne 0 ]; then
# echo "ERR: Unexpected error when testing $nameserver"
# else
# echo "INFO: Dns server $nameserver resolved correctly $CHECK_HOST"
# status=0
# fi
return $status
}
check_conn () {
# Checks network connectivity
if ! check_host $CHECK_WEB_HOST >/dev/null ; then
echo "WARN: System does not seem to reach Internet host $CHECK_WEB_HOST through ICMP"
else
echo "INFO: System can reach Internet host $CHECK_WEB_HOST"
fi
# Check web access, using nc
echo -e "HEAD / HTTP/1.0\n\n" |nc $CHECK_WEB_HOST $CHECK_WEB_PORT >/dev/null 2>&1
if [ $? -ne 0 ] ; then
echo "WARN: Cannot access web server at Internet host $CHECK_WEB_HOST"
else
echo "INFO: System can access web server at Internet host $CHECK_WEB_HOST"
fi
}
# TODO: checks could be conditioned, i.e. if there is no proper
# interface setup don't bother with DNS and don't do some Inet checks
# if DNS is not setup properly
check_local
check_netif
check_dns
check_conn
exit 0
Wireless Troubleshooting guide can also be scripted
http://www.ubuntugeek.com/how-to-troubleshoot-wireless-network-connection-in-ubuntu.html
Wireless Troubleshooting
The first critical step is to ensure that your wireless device is recognized by your system. There are a variety of methods to verify that your system did this successfully. Here are some methods:
*
The “dmesg” command can quite often contain detailed messages indicating that the wirelss devices was properly detected.
*
If the card is an ISA card, you are usually out of luck.
*
If the card is a PCI card (miniPCI/miniPCI Express/PCI Express), you need to use the command “lspci” to display the card identification strings.
*
If the hardware is a USB dongle, you need to use the command “lsusb” to display the dongle identification strings. In some case, “lsusb” doesn't work (for example if usbfs is not mounted), and you can get the identification strings from the kernel log using “dmesg” (or in /var/log/messages).
*
If the card is a Cardbus card (32 bits Pcmcia), and if you are using kernel 2.6.X or kernel 2.4.X with the kernel Pcmcia subsystem, you need to use the command “lspci” to display the card identification strings. If the card is a Cardbus card (32 bits Pcmcia), and if you are using an older kernel with the standalone Pcmcia subsystem, you need to use the command “cardctl ident” display the card identification strings. Try both and see what comes out.
*
If the card is a true Pcmcia card (16 bits), and if you are using kernel 2.6.14 or later, you need to use the command “pccardctl ident” to display the card identification strings. If the card is a true Pcmcia card (16 bits), and if you are using an older kernel, you need to use the command “cardctl ident” display the card identification strings. Note that cardmgr will also write some identification strings in the message logs (/var/log/daemon.log) that may be different from the real card identification strings.
Needless to say, if your wireless device is not detected by your system, you will have to investigate and correct the problem.
Modprobe
Start by running “modprobe
View iwconfig output
Run the “iwconfig” command and look for wireless devices. Based on the driver, look for an appropriately named interface such as ath0, rausb0, etc. The presence indicates that at least the driver is loaded. The absence likely means it did not. This at least gives you a starting point on the problem solving.
A common problem is that your system has both ieee80211 and mac80211 versions of the drivers. Having wmaster0 typically indicates you are using the new mac80211 drivers. Having wifi0 or eth0 typically means you are using the older (legacy) ieee80211 drivers. Having both wmaster0 and wifi0/eth0 (as well as weird interface names like wlan0_rename) might indicate a udev problem. Based on what which ones you really want, you may have to blacklist or move one or more drivers.
View dmesg output
Run the “dmesg” command and look for errors relating to your wireless device. At a minimum there should be some messages relating to your device loading and the module initializing it. If there are no messages or errors, you will have to investigate and correct the problem.
See the next entry of a problem commonly seen: “unknown symbol”.
"unknown symbol" error
When loading the driver kernel module you get a “unknown symbol” error message for one more field names. Sometimes you will see this in the dmesg output as well. This is caused by module you are loading not being matching the kernel version you are running.
First, determine which kernel you are running with “uname -r”. Then use your package manager to determine if you have kernels, kernel headers or kernel development packages that are older.
If you use the RPM package manager then “rpm -qa | grep kernel”. So if you get something like:
kernel-headers-2.6.24.4-64.fc8
kernel-2.6.24.4-64.fc8
kernel-devel-2.6.24.4-64.fc8
kernel-headers-2.6.24.1-15.fc8
kernel-2.6.24.1-15.fc8
kernel-devel-2.6.24.1-15.fc8
In the example above, there are kernel headers and a kernel development package that match the kernel we are running. If you are missing them, the use yum or equivalent on your distribution to install them such as:
yum -y install kernel-headers
yum -y install kernel-devel
Lets assume that “uname -r” returned “2.6.24.4-64.fc8” then all the 2.6.24.1-15 ones are old and need to be removed. So you remove all the old ones:
rpm -e 2.6.24.4-64.fc8
rpm -e kernel-2.6.24.1-15.fc8
rpm -e kernel-devel-2.6.24.1-15.fc8
Also change to ”/lib/modules” and do a directory listing and remove any directory referring to old kernel versions.
Once you are finished, you can do ”“rpm -qa | grep kernel” and confirm everything looks good. At this point, recompile your wireless drivers and reboot the system.
View lsmod output
Run the “lsmod” command can be used to see the loaded modules. Confirm that the kernel module for your wireless device is actually loaded. If it is not loaded, you will have to investigate and correct the problem.
Sometimes other modules conflict with the one you are trying to run. See blacklisting below. Additionally, conflicting modules can be moved out of the module tree. If you do this, run “depmod -ae” afterwards.
View modinfo output
Run “modinfo
Blacklisting
A common problem on newer kernels is that the new mac80211 version of the driver gets loaded instead of the older legacy driver, or vice versa. If that is the case, then you need to blacklist the wrong modules by editing /etc/modprobe.d/blacklist. First, determine the broken module names and add them to the blacklist file as “blacklist
Specifically for madwifi-ng, do a locate or find for ath5k.ko. If ath5k.ko exists then add “blacklist ath5k” to /etc/modprobe.d/blacklist and reboot. Same for the other way around: if you want to load ath5k, but madwifi-ng gets loaded instead, add “blacklist ath_pci” to /etc/modprobe.d/blacklist.
Reload Driver
Although it is not very “scientific”, sometimes simply unloading then reloading the driver will get it working. This is done with the rmmod and modprobe commands.
For b43 and b43legacy, it might also be necessary to reload the underlying SSB module. Similarly, rt2x00 and p54 might need reloading of the common modules (p54common, rt2x00lib, rt2x00usb, rt2x00pci). Sometimes (especially with mac80211 drivers), reloading the stack (for example, modules “cfg80211” and “mac80211”) might do the trick.
Thursday, December 4, 2008
Wireless Modes exposed
Each 802.11a/b/g device can operate in one of four possible modes:
1. Master mode (also called AP or infrastructure mode) is used to create a service that looks like a traditional access point. The wireless card creates a network with a specified name (called the SSID) and channel, and offers network services on it. While in master mode, wireless cards manage all communications related to the network (authenticating wireless clients, handling channel contention, repeating packets, etc.) Wireless cards in master mode can only communicate with cards that are associated with it in managed mode.
2. Managed mode is sometimes also referred to as client mode. Wireless cards in managed mode will join a network created by a master, and will automatically change their channel to match it. They then present any necessary credentials to the master, and if those credentials are accepted, they are said to be associated with the master. Managed mode cards do not communicate with each other directly, and will only communicate with an associated master.
3. Ad-hoc mode creates a multipoint-to-multipoint network where there is no single master node or AP. In ad-hoc mode, each wireless card communicates directly with its neighbors. Nodes must be in range of each other to communicate, and must agree on a network name and channel.
4. Monitor mode is used by some tools (such as Kismet, chapter six) to passively listen to all radio traffic on a given channel. When in monitor mode, wireless cards transmit no data. This is useful for analyzing problems on a wireless link or observing spectrum usage in the local area. Monitor mode is not used for normal communications.
5. B only mode
6. G only mode
7. B/G mode
Access Point Modes
The only configuration mode of an access point that is compliant with the 802.11 standard is known as root mode. The main purpose of an AP is to serve as a portal to a distribution system. The normal default setting of an access point is root mode, which allows the AP to transfer data back and forth between the DS and the 802.11 wireless medium. The default root configuration of an AP allows it to operate as part of a basic service set (BSS). There are, however, other nonstandard modes in which an AP may be configured.
1)Bridge mode The AP is converted into a wireless bridge.
2)Workgroup Bridge mode The AP is transformed into a workgroup bridge.
3)Repeater mode The AP performs as a repeater access point.
4)Scanner mode The access point radio is converted into a sensor radio allowing the access point to integrate into a wireless intrusion detection system (WIDS) architecture.
Client Modes
1) Infrastructure mode (which consists of BSS and ESS)
2) Ad-hoc mode
Sequence of functions while Packet Transmission
CPU FUNCTION
0 -> sostream_direct
0 -> mcopyinuio
0 -> allocb_cred
0 -> allocb
0 -> kmem_cache_alloc
0 -> kmem_cache_alloc_debug
0 -> verify_and_copy_pattern
0 <- verify_and_copy_pattern
0 -> dblk_constructor
0 -> kmem_cache_alloc
0 -> kmem_cache_alloc_debug
0 -> verify_and_copy_pattern
0 <- verify_and_copy_pattern
0 -> getpcstack
0 <- getpcstack
0 -> kmem_log_enter
0 <- kmem_log_enter
0 <- kmem_cache_alloc_debug
0 <- kmem_cache_alloc
0 <- dblk_constructor
0 -> getpcstack
0 <- getpcstack
0 -> kmem_log_enter
0 <- kmem_log_enter
0 <- kmem_cache_alloc_debug
0 <- kmem_cache_alloc
0 <- allocb
0 -> crhold
0 <- crhold
0 <- allocb_cred
0 -> uiomove
0 -> xcopyin_nta
0 <- xcopyin_nta
0 <- uiomove
0 <- mcopyinuio
0 -> tcp_wput
0 -> msgdsize
0 <- msgdsize
0 -> mutex_owned
0 <- mutex_owned
0 -> conn_trace_ref
0 -> mutex_owned
0 <- mutex_owned
0 -> getpcstack
0 <- getpcstack
0 <- conn_trace_ref
0 <- tcp_wput
0 -> squeue_enter
0 -> servicing_interrupt
0 <- servicing_interrupt
0 -> mutex_owned
0 <- mutex_owned
0 -> tcp_output
0 -> tcp_timeout
0 -> conn_trace_ref
0 -> mutex_owned
0 <- mutex_owned
0 -> getpcstack
0 <- getpcstack
0 <- conn_trace_ref
0 -> timeout
0 <- timeout
0 -> timeout_common
0 -> mutex_owned
0 <- mutex_owned
0 <- timeout_common
0 <- tcp_timeout
0 -> dupb
0 -> kmem_cache_alloc
0 -> kmem_cache_alloc_debug
0 -> verify_and_copy_pattern
0 <- verify_and_copy_pattern
0 -> getpcstack
0 <- getpcstack
0 -> kmem_log_enter
0 <- kmem_log_enter
0 <- kmem_cache_alloc_debug
0 <- kmem_cache_alloc
0 <- dupb
0 <- tcp_output
0 -> tcp_send_data
0 -> ire_trace_ref
0 -> th_trace_ire_lookup
0 -> mutex_owned
0 <- mutex_owned
0 <- th_trace_ire_lookup
0 -> kmem_zalloc
0 -> kmem_cache_alloc
0 -> kmem_cache_alloc_debug
0 -> verify_and_copy_pattern
0 <- verify_and_copy_pattern
0 -> getpcstack
0 <- getpcstack
0 -> kmem_log_enter
0 <- kmem_log_enter
0 <- kmem_cache_alloc_debug
0 <- kmem_cache_alloc
0 <- kmem_zalloc
0 -> th_trace_rrecord
0 -> getpcstack
0 <- getpcstack
0 <- th_trace_rrecord
0 <- ire_trace_ref
0 -> ire_to_ill
0 <- ire_to_ill
0 -> putnext
0 -> mutex_owned
0 <- mutex_owned
0 -> mutex_owned
0 <- mutex_owned
0 -> ce_wput
For Packet reception:
And the output looks like this:
0 -> ce_intr
0 -> ddi_get_devstate
0 <- ddi_get_devstate
0 -> pci_dma_sync
0 -> ddi_get_instance
0 <- ddi_get_instance
0 -> ddi_get_soft_state
0 <- ddi_get_soft_state
0 -> ddi_driver_name
0 -> ddi_driver_major
0 <- ddi_driver_major
0 -> ddi_major_to_name
0 <- ddi_major_to_name
0 -> mod_major_to_name
0 <- mod_major_to_name
0 <- ddi_driver_name
0 -> ddi_get_instance
0 <- ddi_get_instance
0 -> pci_debug
0 <- pci_debug
0 -> pci_debug
0 <- pci_debug
0 -> pci_debug
0 <- pci_debug
0 -> pci_pbm_dma_sync
0 <- pci_pbm_dma_sync
0 <- pci_dma_sync
0 -> ce_dupb
0 -> desballoc
0 <- desballoc
0 -> gesballoc
0 -> kmem_cache_alloc
0 -> kmem_cache_alloc_debug
0 -> verify_and_copy_pattern
0 <- verify_and_copy_pattern
0 -> dblk_esb_constructor
0 -> kmem_cache_alloc
0 -> kmem_cache_alloc_debug
0 -> verify_and_copy_pattern
0 <- verify_and_copy_pattern
0 -> getpcstack
0 <- getpcstack
0 -> kmem_log_enter
0 <- kmem_log_enter
0 <- kmem_cache_alloc_debug
0 <- kmem_cache_alloc
0 <- dblk_esb_constructor
0 -> getpcstack
0 <- getpcstack
0 -> kmem_log_enter
0 <- kmem_log_enter
0 <- kmem_cache_alloc_debug
0 <- kmem_cache_alloc
0 <- gesballoc
0 <- ce_dupb
0 -> dvma_sync
0 <- dvma_sync
0 -> pci_fdvma_sync
0 -> pci_debug
0 <- pci_debug
0 <- pci_fdvma_sync
0 -> pci_dma_sync
0 -> ddi_get_instance
0 <- ddi_get_instance
0 -> ddi_get_soft_state
0 <- ddi_get_soft_state
0 -> ddi_driver_name
0 -> ddi_driver_major
0 <- ddi_driver_major
0 -> ddi_major_to_name
0 <- ddi_major_to_name
0 -> mod_major_to_name
0 <- mod_major_to_name
0 <- ddi_driver_name
0 -> ddi_get_instance
0 <- ddi_get_instance
0 -> pci_debug
0 <- pci_debug
0 -> pci_debug
0 <- pci_debug
0 -> pci_debug
0 <- pci_debug
0 -> pci_pbm_dma_sync
0 <- pci_pbm_dma_sync
0 <- pci_dma_sync
0 -> hcksum_assoc
0 <- hcksum_assoc
0 -> canputnext
0 <- canputnext
0 -> putnext
0 -> mutex_owned
0 <- mutex_owned
0 -> mutex_owned
0 <- mutex_owned
0 -> ip_rput
0 <- ip_rput
0 -> ip_input
0 -> ire_cache_lookup
0 -> ire_trace_ref
0 -> th_trace_ire_lookup
0 -> mutex_owned
0 <- mutex_owned
0 <- th_trace_ire_lookup
0 -> kmem_zalloc
0 -> kmem_cache_alloc
0 -> kmem_cache_alloc_debug
0 -> verify_and_copy_pattern
0 <- verify_and_copy_pattern
0 -> getpcstack
0 <- getpcstack
0 -> kmem_log_enter
0 <- kmem_log_enter
0 <- kmem_cache_alloc_debug
0 <- kmem_cache_alloc
0 <- kmem_zalloc
0 -> th_trace_rrecord
0 -> getpcstack
0 <- getpcstack
0 <- th_trace_rrecord
0 <- ire_trace_ref
0 <- ire_cache_lookup
0 -> ip_tcp_input
0 -> ipcl_classify_v4
0 -> conn_trace_ref
0 -> mutex_owned
0 <- mutex_owned
0 -> getpcstack
0 <- getpcstack
0 <- conn_trace_ref
0 <- ipcl_classify_v4
0 <- ip_tcp_input
0 -> ire_refrele
0 -> ire_untrace_ref
0 -> th_trace_ire_lookup
0 -> mutex_owned
0 <- mutex_owned
0 <- th_trace_ire_lookup
0 -> th_trace_rrecord
0 -> getpcstack
0 <- getpcstack
0 <- th_trace_rrecord
0 -> ire_trace_free
0 <- ire_trace_free
0 -> kmem_free
0 <- kmem_free
0 -> kmem_cache_free
0 -> kmem_cache_free_debug
0 -> kmem_log_enter
0 <- kmem_log_enter
0 -> getpcstack
0 <- getpcstack
0 -> kmem_log_enter
0 <- kmem_log_enter
0 -> copy_pattern
0 <- copy_pattern
0 <- kmem_cache_free_debug
0 <- kmem_cache_free
0 <- ire_untrace_ref
0 <- ire_refrele
0 -> squeue_enter_chain
0 -> servicing_interrupt
0 <- servicing_interrupt
0 -> mutex_owned
0 <- mutex_owned
0 -> tcp_input
0 <- tcp_input
0 -> tcp_rput_data
0 -> tcp_find_pktinfo
0 <- tcp_find_pktinfo
0 -> tcp_process_options
0 -> tcp_parse_options
0 <- tcp_parse_options
0 -> tcp_mss_set
0 <- tcp_mss_set
0 -> tcp_maxpsz_set
0 -> setmaxps
0 -> claimstr
0 <- claimstr
0 -> strqset
0 -> mutex_owned
0 <- mutex_owned
0 <- strqset
0 -> releasestr
0 -> cv_broadcast
0 <- cv_broadcast
0 <- releasestr
0 <- setmaxps
0 -> mi_set_sth_maxblk
0 -> allocb
0 -> kmem_cache_alloc
0 -> kmem_cache_alloc_debug
0 -> verify_and_copy_pattern
0 <- verify_and_copy_pattern
0 -> dblk_constructor
0 -> kmem_cache_alloc
0 -> kmem_cache_alloc_debug
0 -> verify_and_copy_pattern
0 <- verify_and_copy_pattern
0 -> getpcstack
0 <- getpcstack
0 -> kmem_log_enter
0 <- kmem_log_enter
0 <- kmem_cache_alloc_debug
0 <- kmem_cache_alloc
0 <- dblk_constructor
0 -> getpcstack
0 <- getpcstack
0 -> kmem_log_enter
0 <- kmem_log_enter
0 <- kmem_cache_alloc_debug
0 <- kmem_cache_alloc
0 <- allocb
0 -> putnext
0 -> mutex_owned
0 <- mutex_owned
0 -> mutex_owned
0 <- mutex_owned
0 -> strrput
Post Owed to: http://blogs.sun.com/amehta/entry/journey_of_a_network_packet
Friday, November 14, 2008
Multicast Example programs
Sender Program
/*
* sender.c -- multicasts "hello, world!" to a multicast group once a second
*
* Antony Courtney, 25/11/94
*/
#include
#include
#include
#include
#include
#include
#include
#define HELLO_PORT 12345
#define HELLO_GROUP "225.0.0.37"
main(int argc, char *argv[])
{
struct sockaddr_in addr;
int fd, cnt;
struct ip_mreq mreq;
char *message="Hello, World!";
/* create what looks like an ordinary UDP socket */
if ((fd=socket(AF_INET,SOCK_DGRAM,0)) < 0) {
perror("socket");
exit(1);
}
/* set up destination address */
memset(&addr,0,sizeof(addr));
addr.sin_family=AF_INET;
addr.sin_addr.s_addr=inet_addr(HELLO_GROUP);
addr.sin_port=htons(HELLO_PORT);
/* now just sendto() our destination! */
while (1) {
if (sendto(fd,message,sizeof(message),0,(struct sockaddr *) &addr,
sizeof(addr)) < 0) {
perror("sendto");
exit(1);
}
sleep(1);
}
}
Listener Program
/*
* listener.c -- joins a multicast group and echoes all data it receives from
* the group to its stdout...
*
* Antony Courtney, 25/11/94
* Modified by: Frédéric Bastien (25/03/04)
* to compile without warning and work correctly
*/
#include
#include
#include
#include
#include
#include
#include
#define HELLO_PORT 12345
#define HELLO_GROUP "225.0.0.37"
#define MSGBUFSIZE 256
main(int argc, char *argv[])
{
struct sockaddr_in addr;
int fd, nbytes,addrlen;
struct ip_mreq mreq;
char msgbuf[MSGBUFSIZE];
u_int yes=1; /*** MODIFICATION TO ORIGINAL */
/* create what looks like an ordinary UDP socket */
if ((fd=socket(AF_INET,SOCK_DGRAM,0)) < 0) {
perror("socket");
exit(1);
}
/**** MODIFICATION TO ORIGINAL */
/* allow multiple sockets to use the same PORT number */
if (setsockopt(fd,SOL_SOCKET,SO_REUSEADDR,&yes,sizeof(yes)) < 0) {
perror("Reusing ADDR failed");
exit(1);
}
/*** END OF MODIFICATION TO ORIGINAL */
/* set up destination address */
memset(&addr,0,sizeof(addr));
addr.sin_family=AF_INET;
addr.sin_addr.s_addr=htonl(INADDR_ANY); /* N.B.: differs from sender */
addr.sin_port=htons(HELLO_PORT);
/* bind to receive address */
if (bind(fd,(struct sockaddr *) &addr,sizeof(addr)) < 0) {
perror("bind");
exit(1);
}
/* use setsockopt() to request that the kernel join a multicast group */
mreq.imr_multiaddr.s_addr=inet_addr(HELLO_GROUP);
mreq.imr_interface.s_addr=htonl(INADDR_ANY);
if (setsockopt(fd,IPPROTO_IP,IP_ADD_MEMBERSHIP,&mreq,sizeof(mreq)) < 0) {
perror("setsockopt");
exit(1);
}
/* now just enter a read-print loop */
while (1) {
addrlen=sizeof(addr);
if ((nbytes=recvfrom(fd,msgbuf,MSGBUFSIZE,0,
(struct sockaddr *) &addr,&addrlen)) < 0) {
perror("recvfrom");
exit(1);
}
puts(message);
}
}
Saturday, November 1, 2008
Rule of 2 NICs on same Host
Different subnet NICs are used in scenarios of packet forwarding and routing.
NIC teaming will provide fault tolerance and load balancing capabilities.
Tuesday, October 28, 2008
Interesting Networking Interview Questions
2) What is the difference between Network Address translation and Packet Forwarding?
3) Is it possible to implement anyone out of congestion control or reliable data transfer algorithms in UDP protocol?
4) Can I say in wireless, presentation and sessions layer are in between data link layer and network layer?
5) Is there a protocol at the Physical Layer in Ethernet Based networks? How do ethernet devices with different speed and technology communicate?
OR
A link means device + transmission medium.
How is link failure detected?
6) Question about watchdog_timeo (net_device member variable) & tran_start?
Netfilter and Iptables demystified
It has two major components:
1) Netfilter component which hooks into stack and performs actions
2) Iptable component which defines a strcuture for rules. Netfilter reads these rules to perform action. Iptables also provides user an interface to configure these rules in form of a utility (also) called iptables.
Netfilter component has 5 hooks into the networking stack so that it can examine following packets
1) Incoming
2) Outgoing
3) Fowarding
4) Pre-routing
5) Post-routing
Though the first 3 are more used, last two are not behind while implementing a NAT (network address translation router using linux box) gateway or router. The difference being they require re-write of packet.
A detailed example of using iptables is given at the following link:
http://searchenterpriselinux.techtarget.com/tip/0,289483,sid39_gci1114110,00.html
Saturday, October 18, 2008
Why Wireles doesn't use just CSMA/CD?
2) Beacuse of hidden node probem
Laptop-A - AP - Laptop-B
In above scenario medium between Laptop A and Access Point will be busy when they are communicatiing but Laptop B might not be aware of such a scenario. Thus, it becomes difficult to detect that medium is busy.
In wired networks the whole medium goes high. in the form of Voltage in wire rising to peek high or peek low.
Thus they use 4 defense tech. to avoid collision
1) NAV (Network allocation vector) using RTS/CTS- also called Virtual carrier sensing
2) IFS (Interframe Spacing)
3) Random Backoff
4) Physical carrier sensing (CS of CSMA)
How 4 defense tech work in tandom:
http://osa.inria.fr/wiki/Developments/MACLayer
Wednesday, October 15, 2008
Problems faced in High speed packet capture
With todays fast networks packet capture has become a problem.
The problem is two fold, first the packets have to be captured, and second there must be spare cpu cycles for analyzing the packets.
The tool of the trade is the pcap library which provides a unified interface to packet capture. It presents the same API on every OS while it is highly customized on the machine side.
The problem is that pcap performance is not very performant. Especially in problem cases when denial of service attacks happen pcap is not able to capture the traffic because it does not deliver the necessary performance.
There are specialized cards available for packet capture but they do not have pulic APIs and are very expensive.
Lucas tests have shown that normal Linux packet capture is really the worst among Linux (0.2%) , FreeBSD (34%) and Windows (68%).
There have been various attempts to improve this, but even the best solutions were only able to capture (11.7%) of the traffic in the worst case.
In essence this mean using Linux for packet capture is a very bad idea. FreeBSD is better by almost a magnitude.
Lucas idea was to create a special package capture architecture for Linux by providing a new socket type Socket Packet Ring (PF_RING). PF_RING provides a ring buffer in memory for each socket. The application can then read from the ring buffer with mmap. The socket has facilities to record the fact that it had to overwrite a packet in the ring before it was read. This decouples the application from the kernel and improves performance substantially. This implementation is network driver neutral and quite fast (47%) still a bit slower than FreeBSD and still over 50% of the traffic lost in the worst case.
The interesting thing at that point was that the CPU was running at 30% in that situation and loosing 50% of the traffic. Luca found that disabling and enabling the interrupts in the kernel were preventing it from going into packet capturing mode fast enough. The rtirq patch was able to solve this last problem. Luca ended up with a System that was as fast as FreeBSD in capturing packets but with much more CPU to spare.
This solution is about twice as fast as commercial netflow capturing probe selling for much higher prices than the hardware cost for running Lucas solution.
Luca has been investigating ways to further improve performance and found that Gigabit Ethernet drivers on Linux could be programmed much more efficiently by exploiting the cards local packet buffers. A second issue is that Linux does memory allocation and de-allocation whenever it reads from the network card which takes a long time.
Luca has published his work in a project called nCap which provides a accelerated variant of libpcap that lets you recompile your old libpcap applications to reach much better speed.
In an attempt to further improve performance Luca has created a custom gigabit Ethernet card driver that programs the Ethernet card to make its traffic data available directly in the computers memory, freeing the CPU totally from this task, letting it work on traffic analysis exclusively. Luca calls this new method 'straight capture'. This method gives you traffic capture at device speed. With the limitation that only one application per card.
Monday, October 13, 2008
Difference - Promiscuous vs. Monitor Mode (Wireless Context)
Promiscuous mode allows you to view all wireless packets on a network to which you have associated. The need to associate means that you must have some measn of authenticating yourself with an access point. In promiscuous mode, you will not see packets until you have associated. Not all wireless drivers support promiscuous mode.
One important difference is Promiscuous mode does, indeed, tell the card to process all frames, (i.e. remove 802.11 frame headers ) including those not destined for it.
But, monitor mode tells the card to pass along the frames intact (with 802.11 headers) and not present plain 'ol Ethernet frames to the host.
Reason
In monitor mode the SSID filter mentioned above is disabed and all packets of all SSID's from the currently selected channel are captured.
Even in promiscuous mode, an 802.11 adapter will only supply packets to the host of the SSID the adapter has joined. Although it can receive, at the radio level, packets on other SSID's, it will not forward them to the host.
So in order to capture all traffic that the adapter can receive, the adapter must be put into "monitor mode", sometimes called "rfmon mode". In this mode, the driver will not make the adapter a member of any service set, so it won't support sending any traffic and will only supply received packets to a packet capture mechanism, not to the networking stack. This means that the machine will not be able to use that adapter for network traffic; if it doesn't have any other network adapters, it will not be able to:
* resolve addresses to host names using a network protocol such as DNS;
* save packets to a file on a network file server;
etc..
Monitor mode is not supported by WinPcap, and thus not by Wireshark or TShark, on Windows.
It is supported, for at least some interfaces, on some versions of Linux, FreeBSD, and NetBSD.
Command to put Wireless card in monitor mode on linux (Use sudo in front, if not in root login)
ifconfig wlan0 down
iwconfig wlan0 mode monitor
ifconfig wlan0 up
Sunday, October 12, 2008
Why Wireless frames are not seen in WIreshark/Ethereal in Windows?
Not too much convincing but here is what I have got.
Without any interaction, capturing on WLAN's may only capture user data packets with "fake" Ethernet headers. In this case you won't see any 802.11 management or control packets at all and the 802.11 packet headers are "translated" by the network driver to "fake" Ethernet packet headers.
A 802.11 LAN uses a "broadcast medium", much like (the mostly obsolete shared) Ethernet. Compared to Ethernet, the 802.11 network is even much "broader", as the transmitted packets are not limited by the cable medium. That's one of the reasons why the 802.11 network adapters have two additional mechanisms to ignore unwanted packets at the receiving side: channels and SSID's.
Conclusion: the packets you'll be capturing with default settings might be modified and only a limited amount of the packets transmitted through the WLAN.
Now, changing the 802.11 capture modes is very platform/network adapter/driver/libpcap dependent and might not be possible at all (Windows is very limited here).
Unfortunately, most of the device drivers for wireless 802.11 NICs
(particularly for Windows operating systems) don’t provide the hooks to capture/copy
received 802.11 frames for use in Wireshark
The Windows Network Driver Interface Specification (NDIS) API does not support any extensions for wireless monitor mode in most versions of Windows. Starting with NDIS 6 in Windows Vista, it is possible to enable monitor mode.[1] NDIS 6 supports exposing 802.11 frames to the upper protocol levels;[2] with previous versions of NDIS only fake Ethernet frames translated from the 802.11 data frames can be exposed to the upper protocol levels.
Linux's interfaces for 802.11 drivers support monitor mode and many drivers offer that support.[3] FreeBSD, NetBSD, OpenBSD, and DragonFly BSD also provide an interface for 802.11 drivers that supports monitor mode, and many drivers for those operating systems support monitor mode as well.
In versions of Windows prior to Windows Vista, some packet sniffer applications such as Wildpackets' OmniPeek provide their own device drivers to support monitor mode.