Monday 8 September 2014

Fedora 20-Wireshark install by yum but not working

For Wireshark to work on Fedora we need two packages wireshark and wireshark-gnome.

Give below commands and it should start working.

yum install wireshark
yum install wireshark-gnome

Thursday 4 September 2014

How to configure PPPoE client on Linux

 
Assuming you have pppoe package installed in PC

Steps:

1)  Run "pppoe-setup"script with default configuration and proper user name and password

2) Verify the user name and password given above is copied into /etc/ppp/pap-secrets

3) run "pppoe-connect"

If server is configured  properly the pppoe link should come up.

Sample pppoe.conf file

#***********************************************************************
#
# pppoe.conf
#
# Configuration file for rp-pppoe.  Edit as appropriate and install in
# /etc/ppp/pppoe.conf
#
# NOTE: This file is used by the pppoe-start, pppoe-stop, pppoe-connect and
#       pppoe-status shell scripts.  It is *not* used in any way by the
#       "pppoe" executable.
#
# Copyright (C) 2000 Roaring Penguin Software Inc.
#
# This file may be distributed under the terms of the GNU General
# Public License.
#
# LIC: GPL
# $Id$
#***********************************************************************

# When you configure a variable, DO NOT leave spaces around the "=" sign.

# Ethernet card connected to DSL modem
ETH='eth2'

# PPPoE user name.  You may have to supply "@provider.com"  Sympatico
# users in Canada do need to include "@sympatico.ca"
# Sympatico uses PAP authentication.  Make sure /etc/ppp/pap-secrets
# contains the right username/password combination.
# For Magma, use xxyyzz@magma.ca
USER='magma'

# Bring link up on demand?  Default is to leave link up all the time.
# If you want the link to come up on demand, set DEMAND to a number indicating
# the idle time after which the link is brought down.
DEMAND=no
#DEMAND=300

# DNS type: SERVER=obtain from server; SPECIFY=use DNS1 and DNS2;
# NOCHANGE=do not adjust.
DNSTYPE=SPECIFY

# Obtain DNS server addresses from the peer (recent versions of pppd only)
# In old config files, this used to be called USEPEERDNS.  Changed to
# PEERDNS for better Red Hat compatibility
PEERDNS=no

DNS1=
DNS2=

# Make the PPPoE connection your default route.  Set to
# DEFAULTROUTE=no if you don't want this.
DEFAULTROUTE=yes

### ONLY TOUCH THE FOLLOWING SETTINGS IF YOU'RE AN EXPERT

# How long pppoe-start waits for a new PPP interface to appear before
# concluding something went wrong.  If you use 0, then pppoe-start
# exits immediately with a successful status and does not wait for the
# link to come up.  Time is in seconds.
#
# WARNING WARNING WARNING:
#
# If you are using rp-pppoe on a physically-inaccessible host, set
# CONNECT_TIMEOUT to 0.  This makes SURE that the machine keeps trying
# to connect forever after pppoe-start is called.  Otherwise, it will
# give out after CONNECT_TIMEOUT seconds and will not attempt to
# connect again, making it impossible to reach.
CONNECT_TIMEOUT=30

# How often in seconds pppoe-start polls to check if link is up
CONNECT_POLL=2

# Specific desired AC Name
ACNAME=

# Specific desired service name
SERVICENAME=

# Character to echo at each poll.  Use PING="" if you don't want
# anything echoed
PING="."

# File where the pppoe-connect script writes its process-ID.
# Three files are actually used:
#   $PIDFILE       contains PID of pppoe-connect script
#   $PIDFILE.pppoe contains PID of pppoe process
#   $PIDFILE.pppd  contains PID of pppd process
CF_BASE=`basename $CONFIG`
PIDFILE="/var/run/$CF_BASE-pppoe.pid"

# Do you want to use synchronous PPP?  "yes" or "no".  "yes" is much
# easier on CPU usage, but may not work for you.  It is safer to use
# "no", but you may want to experiment with "yes".  "yes" is generally
# safe on Linux machines with the n_hdlc line discipline; unsafe on others.
SYNCHRONOUS=no

# Do you want to clamp the MSS?  Here's how to decide:
# - If you have only a SINGLE computer connected to the DSL modem, choose
#   "no".
# - If you have a computer acting as a gateway for a LAN, choose "1412".
#   The setting of 1412 is safe for either setup, but uses slightly more
#   CPU power.
CLAMPMSS=1412
#CLAMPMSS=no

# LCP echo interval and failure count.
LCP_INTERVAL=20
LCP_FAILURE=3

# PPPOE_TIMEOUT should be about 4*LCP_INTERVAL
PPPOE_TIMEOUT=80

# Firewalling: One of NONE, STANDALONE or MASQUERADE
FIREWALL=NONE

# Linux kernel-mode plugin for pppd.  If you want to try the kernel-mode
# plugin, use LINUX_PLUGIN=/etc/ppp/plugins/rp-pppoe.so
LINUX_PLUGIN=

# Any extra arguments to pass to pppoe.  Normally, use a blank string
# like this:
PPPOE_EXTRA=""

# Rumour has it that "Citizen's Communications" with a 3Com
# HomeConnect DSL Modem DualLink requires these extra options:
# PPPOE_EXTRA="-f 3c12:3c13 -S ISP"

# Any extra arguments to pass to pppd.  Normally, use a blank string
# like this:
PPPD_EXTRA=" noauth "


########## DON'T CHANGE BELOW UNLESS YOU KNOW WHAT YOU ARE DOING
# If you wish to COMPLETELY overrride the pppd invocation:
# Example:
# OVERRIDE_PPPD_COMMAND="pppd call dsl"

# If you want pppoe-connect to exit when connection drops:
# RETRY_ON_FAILURE=no

Wireless client mode , can it work in bridge with Ethernet ?

Lets say we have below setup :


   PC1----Eth0-- (Linux-1)----Wifi client ~~~~~~~Wifi AP------(Linux-2)---Eth0--PC2


Setup details:

1) Linux-1 and Linux-2 are two devices with each having wireless interface and an ethernet interface.

2) Linux-1 wireless interface is defined as client and Linux-2 wireless interface as  AP

3) Create bridge in Linux devices and add both the interface to the bridge. For L-1 it is Client and eth0 and L-2 its AP interface and eth0.

4) Ping from PC1 to PC2 -> will it be successful , all ip address are in same subnet.

Note : Wifi client and Wifi AP are just wireless interfaces on which mode is configured as Client and AP with proper Bandwidth, channel etc to make wireless link between the two interfaces.

Refer below links and see if you can find any answer for this question.

 http://wiki.openwrt.org/doc/howto/clientmode
http://wiki.mikrotik.com/wiki/Manual:Wireless_Station_Modes

Answer:


Explanation-1 :

The 802.11 standard only uses three MAC addresses for frames transmitted between the Access Point and the Station. Frames transmitted from the Station to the AP don't include the ethernet source MAC of the requesting host and response frames are missing the destination ethernet MAC to address the target host behind the client bridge.
  1. Bridged Host sends a packet to the Target host
  2. Frame is relayed via the W-LAN Client and the MAC address of the transmitting wireless adapter is used as source MAC, the sending ethernet MAC is discarded
  3. W-LAN AP receives the frame and redirects it to the Target
  4. Target receives the frame and generates a response
  5. Target responds to the received frame using the (wrong) source MAC as destination
  6. W-LAN AP relays the frame to the W-LAN Client with the given destination MAC
  7. W-LAN Client receives the frame and assumes it is the final destination since it's wireless MAC is used in the frame, the packet is not forwarded
  8. Bridged Host never sees a response frame since the W-LAN Client became the destination, no connection is possible
 Explanation-2:

Historically 802.11 AP devices were supposed to be able to bridge frames between wired network segment and wireless, but station device was not supposed to do L2 bridging.

Consider the following network:
[X]---[AP]-(     )-[STA]---[Y]
 
where X-to-AP and STA-to-Y are Ethernet links, but AP-to-STA are connected using wireless. According to 802.11, AP can transparently bridge traffic between X and STA, but it is not possible to bridge traffic between AP and Y, or X and Y.
802.11 standard specifies that frames between station and AP device must be transmitted in so called 3 address frame format, meaning that header of frame contains 3 MAC addresses. Frame transmitted from AP to station has the following addresses:
  • destination address - address of station device, also radio receiver address
  • radio transmitter address - address of AP
  • source address - address of originator of particular frame
Frame transmitted from station to AP has the following addresses:
  • radio receiver address - address of AP
  • source address - address of station device, also radio transmitter address
  • destination address
Considering that every frame must include radio transmitter and receiver address, it is clear that 3 address frame format is not suitable for transparent L2 bridging over station, because station can not send frame with source address different from its address - e.g. frame from Y, and at the same time AP can not format frame in a way that would include address of Y.

Analysis:

As per above explanation it is clear that we cannot bridge the station device.

Solution:

  For this to work, both the client and the AP need to transmit 4-address frames, containing both source and destination MAC addresses.

"iwpriv ath0 wds 1"

From Madwifi Documentation 

# create and configure AP interface
wlanconfig ath0 create wlandev wifi0 wlanmode ap
iwconfig ath0 essid "my_ap_essid" channel <X>

# create first WDS interface, tell about WDS partner, enable WDS mode
wlanconfig wdsath10 create wlandev wifi0 wlanmode wds
iwpriv wdsath10 wds_add <mac_address_of_wds_partner_1>
iwpriv wdsath10 wds 1

# create second WDS interface, tell about WDS partner, enable WDS mode
wlanconfig wdsath11 create wlandev wifi0 wlanmode wds
iwpriv wdsath11 wds_add <mac_address_of_wds_partner_2>
iwpriv wdsath11 wds 1

# bring all interfaces up
# NOTE: Bringing up the AP interface first is important at this time
ifconfig ath0 up
ifconfig wdsath10 up
ifconfig wdsath11 up

# create the bridge and enslave all needed interfaces
brctl addbr br0
brctl addif br0 ath0
brctl addif br0 wdsath10
brctl addif br0 wdsath11

# bring up the bridge
ifconfig br0 up
}}}