Tuesday, October 28, 2008
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?
A link means device + transmission medium.
How is link failure detected?
6) Question about watchdog_timeo (net_device member variable) & tran_start?
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
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:
Saturday, October 18, 2008
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:
Wednesday, October 15, 2008
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
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.
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;
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
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. NDIS 6 supports exposing 802.11 frames to the upper protocol levels; 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. 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.
Thursday, October 9, 2008
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.