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

For FTP TCP data path (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

Multicast Example programs

Multicast Example Program


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);
}
}

Rule of 2 NICs on same Host

If you want two (or more) NICs on one machine to work smoothly you HAVE to do nic bonding(teaming) or put each nic into a different subnet.

Different subnet NICs are used in scenarios of packet forwarding and routing.

NIC teaming will provide fault tolerance and load balancing capabilities.

Interesting Networking Interview Questions

1) How can you make sure the remote interface(NIC) is up if the firewall is blocking your icmp requests and you have no other access to the system.

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

Well netfilter is a linux module(dynamically loadable lump of code in kernel, as linux is monolith kernel) and a framework that hooks into network stack to facilitate processing of packets.

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

Why Wireles doesn't use just CSMA/CD?

1)It is difficult (or, more to the point, expensive) to build physical carrier-sensing hardware(802.11 radios) for RF-based media, because transceivers can transmit and receive simultaneously only if they incorporate expensive electronics. I mean the radios with those capabilities are very expensive.

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

Problems faced in High speed packet capture

Extract from a presentation by Luca "ntop" Deri

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.

Difference - Promiscuous vs. Monitor Mode (Wireless Context)

Monitor mode (RFMON) enables a wireless nic to capture packets without associating with an access point or ad-hoc network. This is desireable in that you can choose to "monitor" a specific channel, and you need never transmit any packets. In fact transmiting is sometimes not possible while in monitor mode (driver dependent). Another aspect of monitor mode is that the NIC does not care whether the CRC values are correct for packets captured in monitor mode, so some packets that you see may in fact be corrupted. Monitor mode only applies to wireless networks, while promiscuous mode can be used on both wired and wireless networks. Monitor mode is one of the six modes that 802.11 wireless cards can operate in: Master (acting as an access point), Managed (client, also known as station), Ad-hoc, Mesh, Repeater, and Monitor mode.

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

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.

Active Sniffing vs. Passive Sniffing

Passive: No packet is generated by the tool. It just sits there and captures all the packets.

Active sniffers on the other hand do generate some spoofed packets as well as capture the authentic packets. E.g. Malicious ethernet packets generated using libnet will force the switch to learn, in a spanning tree algorithm, that the Machine with MAC address X (X being the address used by the Active sniffer) is located on that specific port.

All of the AirPcap adapters can operate in a completely passive mode. This means that they can capture the traffic on a channel without associating with an access point, or interacting with any other wireless device.

Blocking(Synchronous) vs Non Blocking(Async) Sockets

In summary, there are three general approaches that can be taken when building an application with the control in regard to blocking or non-blocking sockets:
1) Use a blocking (synchronous) socket. In this mode, the program will not resume execution until the socket operation has completed. Blocking sockets in 16-bit application will allow it to be re-entered at a different point, and 32-bit applications will stop responding to user actions. This can lead to complex interactions (and difficult debugging) if there are multiple active controls in use by the application.
2)Use a non-blocking (asynchronous) socket, which allows your application to respond to events. For example, when the remote system writes data to the socket, a Read event is generated for the control. Your application can respond by reading the data from the socket, and perhaps send some data back, depending on the context of the data received.
3)Use a combination of blocking and non-blocking socket operations. The ability to switch between blocking and non-blocking modes "on the fly" provides a powerful and convenient way to perform socket operations. Note that the warning regarding blocking sockets also applies here.

If you decide to use non-blocking sockets in your application, it’s important to keep in mind that you must check the return value from every read and write operation, since it is possible that you may not be able to send or receive all of the specified data. Frequently, developers encounter problems when they write a program that assumes a given number of bytes can always be written to, or read from, the socket. In many cases, the program works as expected when developed and tested on a local area network, but fails unpredictably when the program is released to a user that has a slower network connection (such as a serial dial-up connection to the Internet). By always checking the return values of these operations, you insure that your program will work correctly, regardless of the speed or configuration of the network.

collision diameter

The CSMA/CD protocol does not allow a node to start transmitting while the wire is being used by another node (that is the carrier-sense part). However, it is possible for two nodes to start transmitting at almost the same time. The result is that the two transmissions interfere with each other and neither transmission can be properly received. The period during which a collision can occur is the time from when a node starts to transmit to when the signal actually arrives at all other nodes on the wire. This time depends on the physical distance between the furthest nodes on the wire. If this distance is too long, a node might finish transmitting a frame before it arrives at all nodes on the wire. This would make it possible for a collision to occur that the transmitting node would not detect. In order to prevent this from happening, the physical span of a shared-media Ethernet network is limited. This distance is known as the collision diameter; it is a function of the time necessary to transmit the shortest possible Ethernet frame (64 bytes). The collision diameter of a traditional Ethernet operating at 10Mbps is about two kilometers, which is plenty for most local area networks. However, the collision diameter shrinks at faster data rates, since the time it takes to transmit a frame is less. The collision diameter for Fast Ethernet, which operates at 100Mbps, is 200 meters—a limit that can be constraining in a large building. (The collision diameter for Gigabit Ethernet would be 20 meters, but because this distance is so ridiculously short, Gigabit Ethernet does not use CSMA/CD.)

Network Testing - Abstract Thinking

Creating a Network Test Plan

To prepare a plan to test the network. The plan defines the scope, approach, criteria, schedule, responsibilities, resources, and procedures.

Define Objectives

Define the objectives of the test by identifying the areas of the network to be tested including:

· Volume Testing. Ensures that the network operates smoothly when subjected to production volumes of data over long periods of time.

· Stress Testing. Ensures that the network operates smoothly when subjected to the maximum load expected in production, all at one time. A good rule of thumb is to subject the network to 25 percent more data and processing than is expected during peak loads.

· Recovery Testing. Ensures that backup and recovery procedures are working properly.

· Security Testing. Verifies that the network meets the security requirements.

· Performance Testing. Verifies that performance criteria are met (e.g., response times).

Define Acceptance Criteria

For each test objective, define the criteria for successful completion. For example:

· All expected results are achieved on the initial run.

· All severe, and high priority faults are corrected and the associated test(s) rerun successfully.

· A documented plan is put in place specifying how and when outstanding low and medium priority faults will be resolved.

Define Schedule

Identify the high-level activities and tasks together with expected start and completion dates.

Define Responsibilities

Identify the individuals who will be involved in the test and their roles and responsibilities.

Define Resources

Identify the staff, hardware, and software requirements. Confirm that the Network Deployment Plan has accounted for these requirements and resolve any differences.

Define Procedures

Define the procedures to be followed in preparing the test cases, preparing test scripts, preparing the test environment, conducting tests, and verifying test results.

Tips and Hints

Document any assumptions made while preparing the plan.

Plan to use automated test tools wherever possible to significantly reduce the testing effort and duration. Automated test tools can be used to generate and apply an adequate number of transactions to facilitate stress and performance testing.

PacketFactory Network Security Projects

• dnsa [DNS auditing tool]
• egressor [router config check]
• firewalk [gateway ACL scanner]
• hummingbird [asychronous scanning engine]
• ipgeo [IP geo-targeting lookup tool]
• ISIC [IP stack integrity checker]
• libexploit [generic exploit creation (overflows/format strings) library]
• libnet [network packet assembly/injection library]
• libnids [NIDS E-box library]
• libradiate [802.11b frame assembly/injection library]
• libsf [IP stack fingerprinting library]
• nemesis [command line IP stack]
• ngrep [GNU grep for the network]
• packit [tool to monitor, manipulate, and inject customized IPv4 traffic]
• sentinel [remote promiscuous mode detection tool]
• stephanie [OpeBSD hardening tool]
• zodiac [DNS protocol analyzer]

Networking Company Links

http://www.expand.com/

These guys are really doing some cool stuff in Networking
Just check out the Videos

http://youtube.com/user/ExpandNetworks

http://public.lanl.gov/radiant/jobs.html

Hacking Techniques in Wireless Networks

http://www.cs.wright.edu/~pmateti/InternetSecurity/Lectures/WirelessHacks/Mateti-WirelessHacks.htm

A nice brief overview of most of the terms and tactics for internet security

video tutorials

http://security-freak.net/videos.html

contains video tutorials on
Hacking
worms
Architecture of A Proactive Security Tool
Packet Injection using raw Sockets
Packet Sniffing using Raw sockets.
Basic Socket Programming.

UNIX Socket FAQ

http://www.developerweb.net/forum/index.php

http://www.developerweb.net/forum/archive/index.php/f-62.html
(related to Socket Programming)

Script to apply a patch to NS-2

This script will apply any patch the user wants. Just give URL of the patch when the script asks.


# Downloading the requested patch
cd ~/.
cd ns-2
mkdir tempPatch
cd tempPatch
echo "Give the URL of patch. I will download and patch it for you."
read ans
sudo wget $ans
dir1="$HOME/ns-2/tempPatch/"
dir2=$HOME/ns-2/ns-allinone-2.31/ns-2.31/
file=$dir1/*
cp $file $dir2
cd $dir2


# Applying the patch
make clean
patch -p1 < $file
rm -rf $HOME/ns-2/tempPatch
sudo make
sudo make install

Auto install script Network Simulator NS-2

This scripts installs the AllinOne package of NS,NAM,TCL,TK. Please take note that these packages get installed in a specific account. If another user wants to get access to these packages he will have to add the environment variables given below in his ~/.bashrc file.

Enjoy!


echo "This script installs NS-2 on Debian Linux(Need to be root)"
cd ~/.
mkdir ns-2
cd ns-2
wget http://nchc.dl.sourceforge.net/sourceforge/nsnam/ns-allinone-2.31.tar.gz
tar -xzvf ns-allinone-2.31.tar.gz
cd ns-allinone-2.31/
sudo apt-get -y install build-essential autoconf automake libxmu-dev
echo "This command may generate some errors, and if it does, restart your computer and uncomment the step giving in script"
# Uncomment the following command
# sudo apt-get install -f build-essential libxt-dev lins-2.31bxt6 libsm-dev libsm6 libice-dev libice6 libxmu-dev
#
./install
echo "If the script meshes up your environment variables then restore the backup file"
cp ~/.bashrc ~/.bashrc.bak_by_ns2

# Inserting paths in environment file.
echo "# LD_LIBRARY_PATH" >> ~/.bashrc
echo "OTCL_LIB=$HOME/ns-2/ns-allinone-2.31/otcl-1.13" >> ~/.bashrc
echo "NS2_LIB=$HOME/ns-2/ns-allinone-2.31/lib" >> ~/.bashrc
echo "X11_LIB=/usr/X11R6/lib" >> ~/.bashrc
echo "USR_LOCAL_LIB=/usr/local/lib" >> ~/.bashrc
echo "export LD_LIBRARY_PATH=\$LD_LIBRARY_PATH:\$OTCL_LIB:$NS2_LIB:\$X11_LIB:\$USR_LOCAL_LIB" >> ~/.bashrc


echo "# TCL_LIBRARY" >> ~/.bashrc
echo "TCL_LIB=$HOME/ns-2/ns-allinone-2.31/tcl8.4.14/library" >> ~/.bashrc
echo "USR_LIB=/usr/lib" >> ~/.bashrc
echo "export TCL_LIBRARY=\$TCL_LIB:\$USR_LIB" >> ~/.bashrc


echo "# PATH" >> ~/.bashrc
echo "XGRAPH=$HOME/ns-2/ns-allinone-2.31/bin:$HOME/ns-2/ns-allinone-2.31/tcl8.4.14/unix:$HOME/ns-2/ns-allinone-2.31/tk8.4.14/unix" >> ~/.bashrc
echo "NS=$HOME/ns-2/ns-allinone-2.31/ns-2.31/" >> ~/.bashrc
echo "NAM=$HOME/ns-2/ns-allinone-2.31/nam-1.13/" >> ~/.bashrc
echo "PATH=\$PATH:\$XGRAPH:\$NS:\$NAM" >> ~/.bashrc

# Immediatly taking effect
source ~/.bashrc

# Validating installation
echo "Press Enter to Validate Installation(time consuming) or press CTR-C"
read
cd ns-2.31
./validate

Brainstorming - TCP ideas

1) self stabilizing parameters/values
e.g. Increased initial window.

Use: A server operating system (e.g VMware's ESX server) might be deployed in networks of different speed thus it would be efficient if the TCP IP stack can set its parameters depending on network speed and usual network traffic.


2) Dynamically switching between different congestion avoidance algorithms.

Use: laptops which roam in networks of different throughput. Different congestion avoidance are effective in different networks thus to find the optimum algorithm for that specific network. e.g. it should switch to TCP Hybla when using wireless interface and to HS-TCP when it is connected to wired link.
Another parameter to change congestion avoidance can be network bandwidth

3) Connection based - congestion avoidance algorithm based on tracert or hop count

It is very unfair to server a client in china as compared to client sitting in CA, which is the same place where the server is located. TCP hybla suggestion an avoidance algorithm which is not based on RTT e.g A client using virtual machine running in california from india should use TCP Hybla and a client sitting in same building should use TCP westwood.

4) congestion avoidance algorithm based on the type of traffic. E.g. calculate the behavior of window as a function of type of data. Large file, chat application, etc (not sure how this can be done)

5) Initial window size probing using ICMP or UDP protocol.
(An approach equivalent to Autotuning with Autobuf has been shown to improve file transfer speeds (goodput), and is therefore an extremely useful tool for speeding up large file transfers.)

Script to make your debian box a network weapon

apt-get -y install wireshark
apt-get -y install bmon
apt-get -y install iperf
apt-get -y install netperf
apt-get -y install gnuplot
apt-get -y install wireshark
apt-get -y install nmap
apt-get -y install nessus
apt-get -y install traceroute

-y means it will take yes as default for installing all packages.

PS: dont forget to make the file executable.
chmod 700 filename

First post

Bla bla bla.........