Friday, 9 October 2015

Linux DHCP Server won't reply to DHCP clients in Routing mode to DHCP relayed clients



Problem  Description:

Setup :

 192.168.7.1          192.168.7.2----10.1.1.1            10.1.1.2   ---- 110.1.1.1           
Win DHCP Server 1 ---Linux DHCP Server 2------Linux DHCP relay -------Win XP DHCP client PC
                                               Routing mode             Routing mode

Config :

Win DHCP Server 1 : IP address 192.168.7.1

Linux DHCP Server 2 : 192.168.7.2 , 10.1.1.1 ( As its in routing mode)

Linux DHCP relay : 10.1.1.2 , 110.1.1.1

Win XP DHCP Client : Has to get IP from DHCP servers.


Config/ Observations 1:

1) DHCP server 1 is disabled, now only one server is present in the network.

2) In DHCP relay the DHCP server is mentioned as 10.1.1.1 and client interface as 110.1.1.1

3) On DHCP server in the config file (dhcpd.conf) subnet is defined for 110.1.1.1 network, make a note that this subnet is not part of the subnet on which server is runnning ( server is running on 192.168.7.2 and 10.1.1.1.)

4) Start DHCP client on windows PC, the DHCP discover can be seen on Linux DHCP Server , but it is not replying to the discover.As i know, if the subnets configured are not of the same subnet as one of its interfaces the DHCP server will not reply. So this is expected behavior. ( Correct me if I am wrong , i am trying to find supporting links, will update on this also)


 Config/ Observations 2:


1) Now start Windows DHCP Server 2 and on DHCP relay configure the DHCP server as 192.168.7.1 and  client interface as 110.1.1.1

2) Again run "ipconfig/release" and "ipconfig /renew" on the WIndows DHCP client PC.

3) On Linux PC forwarding is enabled and it is forwarding the "unicast DHCP DISCOVER"  packet to the Windows Server.

4) Now suddenly both Linux DHCP Server starts working and it start replying along with the Windows DHCP server. Both the servers are replying for the intended subnets (110.1.1.1) , even though the DHCP discover packet is not intended for the Linux server.

Question:

The question is why the Linux server is replying now? As it is supposed to reply only to the connected interfaces IP subnets.

I am still trying to find answers, if you have any comments/ideas let me know in comments.

Keep Researching !

Tuesday, 28 July 2015

Command to generate multicast traffic using Iperf


Server Device:
Iperf –B 240.10.10.10 –us

Client Device:
Iperf –B <ServerDeviceIP> -uc 240.10.10.10 –b 10M –t 120



Tables in IPtables

IPtables

Tables in IPtables :
filter: This is the default table (if no -t option is passed).
        Built in chains
  • INPUT (for packets destined to local sockets), 
  • FORWARD (for packets being routed through the box),
  • OUTPUT (for locally-generated packets).

nat: This table is consulted when a packet that creates a new connection is encountered.
          Built in chains
  • PREROUTING (for altering packets as soon as they come in),
  • OUTPUT (for altering locally-generated packets before routing),
  • POSTROUTING (for altering packets as they are about to go out).

mangle: This table is used for specialized packet alteration.

Until kernel 2.4.17  it had two built-in chains:
  • PREROUTING (for altering incoming packets before routing)
  • OUTPUT (for altering locally-generated packets before routing).

Since kernel 2.4.18, three other built-in chains are also supported: 

  • INPUT (for packets coming into the box itself), 
  • FORWARD (for altering packets being routed through the box)
  • POSTROUTING (for altering packets as they are about to go out).

raw:
This table is used mainly for configuring exemptions from connection tracking in combination with the NOTRACK target.
 It registers at the netfilter hooks with higher priority and is thus called before ip_conntrack, or any other IP tables.

 It provides the following built-in chains:

  • PREROUTING (for packets arriving via any network interface)
  •  OUTPUT (for packets generated by local processes)

Ref : http://linux.die.net/man/8/iptables

Monday, 30 March 2015

How to configure Freeradius server as Radius Proxy/ Relay

Setup :

FreeRadius Server (Linux PC1)---------------------Linux PC2 -----------------------------------AP ----------Users
10.1.1.1 /24                                  10.1.1.2/24            10.2.1.2/24              10.2.1.1/24



Details:

1) The users are authenticated from Free radius server.

2) The Linux PC 2acts as Router with IP forwarding enabled.

3) On Linux PC 2 Radius proxy or the Radius relay is to be enabled so that it forwards the requests to/from users.

4) Free radius is installed in both Linux PC , one to act as relay and another as server.

Configuration on Free radius server

1) Users in users.conf
2) The Linux PC 2 as radius client to be defined in clients.conf
3) Start radius server

radiusd -X


Configuration on Linux PC 2:

Modify below lines in proxy.conf


1)    # virtual_server = foo   --> Change to ->         virtual_server = 10.1.1.1

2) Comment below lines

realm LOCAL {
    #  If we do not specify a server pool, the realm is LOCAL, and
    #  requests are not proxied to it.
}

to

#realm LOCAL {
    #  If we do not specify a server pool, the realm is LOCAL, and
    #  requests are not proxied to it.
#}

3) Uncomment below lines and give ip address of the Radius server

#realm DEFAULT {
#    authhost    = radius.company.com:1600
#    accthost    = radius.company.com:1601
#    secret        = testing123
#}

to

realm DEFAULT {
    authhost    = 10.1.1.1
    accthost    = 10.1.1.1
    secret        = testing123
}

4) The secret between Radius server and this relay is "testing123".

5) Start the server which should act as relay.

radiusd -X


Configuration on AP
For AP the Radius server is the immediate server i.e. here relay 10.2.1.2
User

Once users are defined properly in Linux PC 1, and setup is done, the users should get authenticated.

Saturday, 28 March 2015

Creating Custom Attributes-Roles in Microsoft LDAP server

Configuring Custom Attributes/ Roles on the external LDAP server

  • Open the Management console on the Active Directory installed server and complete the following steps..
  • Select Start > Run.
  • Type mmc and press Enter.
  • Select File > Add/Remove Snap-in.
  • Click Add.
  • Select Active Directory Schema from the Available standalone snap-ins list and click Add.
  • Click Close..
Right-click the Attributes folder (Console Root/Active Directory Schema/ Attributes) and select New > Attribute.

Create the New Custom attribute by completing the following steps.
  •      Enter TestNew in the Common Name field.
  •      Enter TestNew in the LDAP Display Name field.
  •      Enter a unique object identifier in the Unique x500 Object ID field.
  •      Enter a description of the attribute in the Description field.
  •      Select Case Insensitive String in the Syntax list.
  •      Click OK.

Close the Management console.


Configuring authorization details on the external LDAP server
  • Open the ADSI Edit dialog box on the Active Directory installed server.
  • Select Start > Run.
  • Type adsiedit.msc and press Enter.
  • Right-click CN=User_Name in the CN=Users directory and select Properties.
  • Where User_Name is the name of the user you created in "Creating an AD user account".
  • Select TestNew in the Attributes list and click Edit.
  • Add desired parameters

Close the ADSI Edit dialog box.

Note : Unique x500 Object ID can be generated using Microsoft OID generator script explained in previous post.

Generate OID for Windows Server Custom Class and Attributes

Generate OID using below script

1) copy the script to notepad and name it as oidgen.vbs 
2) Open command prompt in Windows 7 or 8 and type below command
cscript cscript oidgen.vbs

3) Copy the generated OID and assign prefix for custom class and attributes.


Ref:
http://security.stackexchange.com/questions/26516/what-oid-issuance-policies-are-appropriate-for-smartcard-and-browser-certificate/26518#26518


Friday, 27 March 2015

How to Run IPerf Traffic on same Computer with two Interfaces


Setup:

           Linux PC/Device -----------Eth1--------|
                                  |                            | Loopback cable
                                   |-------------Eth2------- |

Requirements:

  The Iperf traffic should pass externally from the Ethernet interfaces which are connected using Ethernet cable..

Problem:

We have one interface which is called as loopback interface (lo). When we ping or send traffic to test local interface it is the loopback interface which replies.

Lets say we have three interfaces on Linux PC eth1, eth2 and lo (loopback interface). 

Commands

Ifconfig eth1 10.1.1.1 netmask 255.255.255.0 up
ifconfig eth2 10.2.1.1 netmask 255.255.255.0 up

ifconfig -> Verify loopback interface is up

ping 10.1.1.1 -> Reply will come

ping 10.2.1.1 -> Reply will come

Now disable loopback interface

ifconfig lo down

ping 10.1.1.1 -> Reply will not come

ping 10.2.1.1 -> Reply will not come

So the problem is if the loopback interface is present this interface will reply and the packets will not go from out side the cable or in other words the kernel detects that the destination is a local one, so the traffic is looped back to the machine itself without going through eth1 or eth2.


Solution

Got solution using NAT iptables rules as described in below reference link.


ifconfig eth0 10.50.0.1 netmask 255.255.255.0
ifconfig eth1 10.50.1.1 netmask 255.255.255.0
iptables -t nat -L
iptables -t nat -A POSTROUTING -s 10.50.0.1 -d 10.60.1.1 -j SNAT --to-source 10.60.0.1
iptables -t nat -A PREROUTING -d 10.60.0.1 -j DNAT --to-destination 10.50.0.1
iptables -t nat -A POSTROUTING -s 10.50.1.1 -d 10.60.0.1 -j SNAT --to-source 10.60.1.1
iptables -t nat -A PREROUTING -d 10.60.1.1 -j DNAT --to-destination 10.50.1.1
ip route add 10.60.1.1 dev eth0
arp -i eth0 -s 10.60.1.1 00:22:45:f1:18:53 # eth1's mac address
ip route add 10.60.0.1 dev eth1
arp -i eth1 -s 10.60.0.1 02:22:23:f1:18:52 # eth0's mac address
ping 10.60.1.1

Using above commands it was possible to force the traffic outside the cable.

Once setup is ready, run the Iperf server and client on the PC.

# server
iperf -B 10.50.0.1 -s -u -w 256k -l 1KB &
# client
iperf -B 10.50.1.1 -c 10.60.0.1 -u -b 600M -w 256k -l 1KB -P 10 -t 60

Sunday, 15 March 2015

Steps for Installing Hyper-V on windows 2012 Server

Prerequisite

In BIOS setting -> Performance-> virtualization-> on

Step 1-Add Hyper-V
  1. In Server Manager, on the Manage menu, click Add Roles and Features.

  2. On the Before you begin page, verify that your destination server and network environment are prepared for the role and feature you want to install. Click Next.

  3. On the Select installation type page, select Role-based or feature-based installation and then click Next.

  4. On the Select destination server page, select a server from the server pool and then click Next.

  5. On the Select server roles page, select Hyper-V.

  6. To add the tools that you use to create and manage virtual machines, click Add Features. On the Features page, click Next.

  7. On the Create Virtual Switches page, Virtual Machine Migration page, and Default Stores page, select the appropriate options.

  8. On the Confirm installation selections page, select Restart the destination server automatically if required, and then click Install.

  9. When installation is finished, verify the installation by opening the All Servers page in Server Manager, selecting a server on which you installed Hyper-V, and viewing the Roles and Features tile on the page for the selected server.

Step 2-Install Guest operating system

  1. From Hyper-V Manager, in the Virtual Machines section of the results pane, right-click the name of the virtual machine and click Connect.

  2. The Virtual Machine Connection tool opens.

  3. From the Action menu in the Virtual Machine Connection window, click Start.

  4. The virtual machine starts, searches the startup devices, and loads the installation package.

  5. Proceed through the installation.


How to change Postgres Admin Password ?

Reference: http://www.homebrewandtechnology.com/blog/graphicallychangepostgresadminpassword


 ===========================================================

To do this using command prompt. It is good to know that in windows there will be 2 account. One is postgres windows user account. The other is database admin account. Which is also called postgres.

 

  • Edit E:\PostgreSQL\9.1\pg_hba.conf and set the localhost method to trust instead of md5.  Do not forget to save.
  • Use the usual Windows way to reset the password of windows user account.
  • Open up a command prompt and use runas to open another command prompt as postgres user.
  • open up Services manager and restart postgresql service. There might be need to update the postgres user account password setting in the service property at this step.
  • Now running psql will not ask any password.
  • Use the following sql to set the user password

ALTER USER Postgres WITH PASSWORD '<newpassword>'

  • Revert the pg_hba.conf localhost method back to md5 .
  • Restart postgresql service in Services manager.
======================================================

Batch File for Remote shutdown and Wake on Demand using Wake on LAN

For long weekends  or public holiday's its good that all the desktops were shutdown. The below method uses Windows Remote shutdown feature and Wake-On-Lan features to remotely shutdown the desktops and power it on whenever required.


Settings to do on Target PC


1. Turn on the target PC.
2. Open run->secpol.mnc
3.In Security settings, Expand "Local Polices->User rights assignment"
4.Double click on "Force shutdown from a remote system properties".
5.Click on Add user (test) and group
6.click on object types, select "built in security principles and users" and click OK
7.Goto advanced -> find now ->select administrator, everyone, required user (eg:test) and click OK.
8. Click Apply and then OK.
9. Close the window.

Open Port 445: Open TCP port 445 on target computer

1.Goto start->settings->control panel->security centre.
2. Open windows firewall -> Exceptions Tab.
3.Select the following line "File Sharing and printers" and press ok.
4. If this line is missing click on Add port ->choose TCP port 445.
5. Then got to start->settings-control panel->system.
6. Select the remote tab; check the "Allow users to connect remotely to this computer".

Settings to do on Control PC


1.Turn on main PC.
2. Open cmd
3. Use command "net use \\Target PC IP password /user: username 'enter'

Example: net use \\10.10.1.10 test /user: test

Note: IP address used in net use command should be reachable from the main PC.  If that is not reachable then the following error will be shown as net use command output.

 "System error 53 has occurred. The network path was not found".

4. Check the message "The command completed successfully" is shown.
5. Similarly add Target PC IPs.
6. Command "net use" will show you the table containing the Target PC entries.
7. Type "shutdown -i", there opens a remote shutdown dialog box.
8.  Click Add and enter the target ip address. Repeat the same for all IPs.
9. Select the operation "shutdown/restart".
10. Configure the display warning for specific time (sec) before shutdown\restart.
11. Give comments on the Task and click ok.

Wake On LAN

 WakeOnLan, as the name already suggests, is a tool that can boot or wake a computer (on the same local network) by sending a magic packet to the network adapter of the target computer.

 

Prerequisites

1.      All network cards and BIOS are compatible or support the use of Magic Packet.

2.      All PCs should be reachable from main PC, ie from where we are sending magic packet.

3.      All PCs MAC addresses and IP Addresses.

4.      Tool to send magic packet should be installed in main PC.You can download wolcmd from http://www.depicus.com/wake-on-lan/wake-on-lan-cmd.aspx


 To check if your network card is compatible with magic packets:

  • Right click on My Computer and click Manage.
  • Go to Device Manager/Network Cards.
  • Right click on your Network Card then Properties.
  • Search for the following the words: "Magic Packet", "Wake On Magic Packet", "Wake On Lan" or "Wake" - verify that all options related to these words are being activated
  • If you found nothing, you may be required to update the drivers of your Network card

 BIOS

To check if your BIOS is compatible, follow these steps:

  • Enter the BIOS when you start the computer by pressing ESC, F2, F5, F12 or DEL, depending on your system,
  • Once in the BIOS, go to POWER Options and enable Wake-On-LAN, or any similar option.

 Wake on LAN GUI tool: 

·         Launch the Wake on LAN GUI tool.

·         Provide the MAC address, IP Address, Subnet Mask and port of the target PC.

·         Click on Wake me UP.

 Wake on LAN Command line Tool: 

·         Open command prompt and Go to the directory where this command line tool is present.

·         Issue the following command.

            wolcmd [mac address] [ipaddress] [subnet mask] [port number]

 

 

Batch file wakenow.bat

wolcmd.exe 0007E90E7A66 10.10.10.10  255.0.0.0 9

wolcmd.exe 50E549467AAD 10.10.10.11 255.0.0.0 9

 

Batch file Sleepnow.bat

net use \\10.10.10.10 test /user:test  

shutdown -m \\10.10.10.10 -s -t 1 -c "Going to shutdown.... "

net use \\10.10.10.11 test /user:test

shutdown -m \\10.10.10.11 -s -t 1 -c "Going to shutdown..

 

Thursday, 29 January 2015

How to Enable EAP-PEAP with Radius VLAN Attributes in Free-Radius Server

Issue: We wanted to use EAP-PEAP with Radius VLAN Attributes in Free-Radius Server, it was authenticating with user name and password but VLAN attributes were not seen in Radius-Accept packet.


users.conf



username   Cleartext-Password := "passwd"
           Tunnel-Type = VLAN,
           Tunnel-Medium-Type = IEEE-802,
           Tunnel-Private-Group-Id = "200"
 

Resolution: 

 
We need to enable use_tunneled_reply in peap section of eap.conf 

peap {
default_eap_type = mschapv2
copy_request_to_tunnel = no
use_tunneled_reply = yes
virtual_server = "inner-tunnel"
}
 
Ref: 
 
http://lists.freeradius.org/pipermail/freeradius-users/2009-December/043707.html
 
 

Saturday, 10 January 2015

How ping really works- by George Mays

A very interesting white paper "How ping really works?"  by "George Mays". I recommend all of you to read.

Ref : http://www.galaxyvisions.com/pdf/white-papers/How_does_Ping_Work_Style_1_GV.pdf

=============================================================

Introduction

Ping is a basic Internet program that most of us use daily, but did you ever stop to wonder how it really worked? I don’t know about you, but it bugs me when I do not know how something really works. The purpose of this paper is to resolve any lingering questions you may have about ping and to take your understanding to the next level. If you do not happen to be a programmer, please do not be frightened off! I am not going to tell you how to write your own version of ping; trust me.

I am guessing that you know basically how the TCP/IP ping utility works. It sends an ICMP (Internet Control Message Protocol) Echo Request to a specified interface on the network and, in response, it expects to receive an ICMP Echo Reply. By doing this, the program can test connectivity, gauge response time, and report a variety of errors.

ICMP is a software component of the Internetworking layer of TCP/IP; essentially, it is a companion at thatlevel to IP (Internet Protocol) itself. In fact, ICMP relies on IP for transport across the network. If you observe this sort of network traffic, say on an Ethernet network, then your protocol analyzer would capture an Ethernet frame transporting an IP datagram with an ICMP message inside.

Enter the problem: Since the ping program executes at the Application layer, how does it make ICMP do these tricks? You may recall, if you are a student of TCP/IP, that the Host-to-Host layer is sandwiched between these entities. Is that bypassed? If so, then how? Who is responsible for formatting these messages (Echo Request and Echo Reply)?

More vexingly, when unexpected ICMP responses, other than the customary Echo Reply, result from the Echo Request, how is it that they find their way to the ping program? This last question may seem obvious, but it is not. ICMP messages contain no addressing information that allows the TCP/IP protocol stack to discern the program that is to receive the message. TCP and UDP use port numbers for this purpose. So, how does this work?

Background


The TCP/IP protocol stack is organized as a four-layer model. The lowest layer, commonly called the Network Interface or Network Access layer, is analogous to OSI layers 1 and 2, the Physical and Data Link Control layers. This includes things like media, connectors, signalling, physical addressing, error detection, and managing shared access to the media. For most of us this translates into Ethernet and our cabling system.

How Does Ping Really Work?


The layer above the Network Access layer, the Internetworking layer, is best likened to OSI layer 3, the Network layer. Here we expect to find logical addressing and routing: things that facilitate communication across network boundaries. This is where IP and its addressing mechanisms reside, as does ICMP  ICMP is a necessary component of any TCP/IP implementation. It does not exist to provide information to the higher-layer protocols (like TCP and UDP) so that they may be more reliable. Rather, ICMP provides network diagnostic capabilities and feedback to those responsible for network administration and operation. See RFC  792, if you are really interested.
Above the Internetworking layer is the Host-to-Host layer, which is the counterpart of OSI layer 4, the Transport layer. I like to think that this also includes some of the Session layer (5) functionality as well. This is where we expect to find facilities for reliable end-to-end data exchange, additional error checking, and the means to discriminate one program from another (using port numbers). TCP and UDP reside at this level.  At the top of the stack, the Application or Process layer, we find high-level protocols (like SMTP, HTTP, and FTP)  implemented. This is where applications execute as well. So when you do a ping, the ping program should be perceived to function at this level.

A Minor Mystery

With ICMP operating at the Internetworking layer and the ping program at the Application layer, how is the Host-to-Host layer bypassed? The answer lies in an understanding of what are known as “raw” sockets. Well, for openers, what is a socket, right? Abstractly, a socket is an endpoint to communication, usually
thought to consist of an IP address and port number, which identify a particular host and program, respectively. But a programmer has a slightly different perspective on a socket. From his vantage point, “socket” is a system function that allocates resources that enable the program to interact with the TCP/IP protocol stack beneath. The addressing information is associated with this only after the socket call is made. (Again, if you are interested, this is the role of the “bind” function.) So, take note, it is possible to allocate a socket and not overtly associate any addressing information with it.

There are three commonly encountered types of sockets: stream, datagram, and raw. TCP uses the stream type and UDP uses the datagram type. Raw sockets are used by any application that needs to interact directly with IP, bypassing TCP and UDP in doing so. Customers include routing protocol implementations like routed and
gated (that implement RIP and OSPF). It also includes our friend ping.

There are some special considerations in using raw sockets. Since you are circumventing the facilities of the Host-to-Host layer, you forego the program addressing mechanism, the port numbering scheme. This means that programs that employ raw sockets must sift through all incoming packets presented to them in order to find those packets that are of interest.

What Actually Goes On

When the ping program begins execution, it opens a raw socket sensitive only to ICMP. This means two things:
• On output: the sending of ICMP Echo Requests, the program is required to format the ICMP message. The system will provide the IP header and the Ethernet (usually) header.
• On input: the program must examine all ICMP messages coming in and cull out the items of interest. The expected input is ICMP Echo Replies.

Let us take these things in turn. On the outbound side, the Echo Requests are formatted.
The message type is always the coded value eight (8). The code field always contains zero. The checksum is used for error detection. The ICMP message header and data are included in its computation. The ping program performs this calculation
and fills in the blank. The identification field follows and is supposed to contain the process ID (PID) that uniquely identifies that execution of the ping program to the operating system. On Windows systems, this field contains the constant value 256. Next is the sequence number field, which starts at 0 and is bumped by one  on each Echo Request sent. After these required fields, optional test data will follow. In the ping implementation that I examined (Slackware Linux), this included a timestamp used in the round-trip time calculation upon receipt of the Echo Reply.
As for inbound ICMP messages, ping’s task is a bit more complex. Because ping is using a raw ICMP socket, the program is presented with a copy of all incoming ICMP messages, except for a few special cases like incoming Echo Requests generated by other people pinging us (the latter are handled by the system). This means that ping sees not only the expected Echo Replies when they arrive but also things like Destination Unreachable, Source Quench, and Time Exceeded messages.

ICMP Echo Request
Type (8) Code (0)
Checksum
Identification
Sequence
Test Data

Now think about this for a moment. If you have two copies of the ping program running at the same time, then they are each going to see one another’s Echo Replies and any other “nastygrams” that might show up.
Each instance of the program must identify the messages that are relevant to it. If you guessed that this is what the PID (identification) field is used for then you are absolutely right. How does the Windows flavour of ping accomplish this feat without the PID? You got me. That sounds like a topic for a future article. Let me get back to you on that.
Interestingly, the messages coming in are handed to ping with the IP header still intact. So, the program has access to important things there like the time-to-live (TTL) value and record route information (if the latter option is turned on).

Summary
At this point, you should have a fairly complete understanding of the cycle of processing associated with ping. Let me recapitulate the essential elements:

• As the ping program initializes, it opens a raw ICMP socket so that it can employ IP directly, circumventing TCP and UDP.
• Ping formats an ICMP type 8 message, an Echo Request, and sends it (using the “sendto” function) to  the designated target address. The system provides the IP header and the data link layer envelope.
¶ As ICMP messages are received; ping has the opportunity to examine each packet to pick out those items that are of interest.
• The usual behaviour is to siphon off ICMP type 0 messages, Echo Replies, which have an identification field value that matches the program PID.

Type Codes Description
0/8 0 Echo Reply/Echo Request
3 0-15 Destination Unreachable
4 0 Source Quench
5 0-3 Redirect
9/10 0 Router Advertisement
11 0-1 Time Exceeded
12 0 Parameter Problem
13/14 0 Timestamp Request/Timestamp Reply
17/18 0 Address Mask Request/Address Mask Reply

ICMP Message Types
• Ping uses the timestamp in the data area of the Echo Reply to calculate a round-trip time. It also reports the TTL from the IP header of the reply.
• When things do not work normally, ping may report some of the other ICMP message types that show up in the inbox. This includes things like Destination Unreachable and Time Exceeded messages.

Friday, 2 January 2015

Random question on Wifi- Beacon Interval

Question :

 Suppose Beacon packets are sent at 0, 100, 200,300..In this case if AMPDU has started at 95th ms
and is extended beyond 100ms upto 105 ms.When the next beacon will be sent ? 100ms or 105ms or
will be dropped and wait for next beacon interval?


Answer:


As per IEEE Std802.11-2012, Sec: 10.2.1.4

The AP schedules Beacon frames for transmission every beacon interval, but the Beacon frames
may be delayed if there is traffic at the TBTT.


Beacons frames are scheduled to be transmitted every 1024us. If on the 1024us, the medium is busy,
it is transmitted at the next available transmit opportunity.So the beacon will be transmitted at
105 msec.The next beacon will continue at previous interval i.e at 200 msec, so if we calculate the
beacon interval between the last beacon frame and this beacon frame it will be 95 msec and not 100 msec.

Target Beacon Transmission Time  (TBTT) is the time at which a node (AP or station when in Ad-hoc) must send a beacon. The time difference between two TBTTs is known as the beacon interval. The beacon interval is given in Time Units (TU), each TU represents 1024 microseconds. The beacon interval is typically set to 100 TUs (102400 microseconds, or 102.4 ms) and its length is two bytes.

Ref:

http://wireless.kernel.org/en/developers/Documentation/ieee80211/power-savings

Related Posts Plugin for WordPress, Blogger...