Raw ethernet socket - Networking

This is a discussion on Raw ethernet socket - Networking ; Hi all, I've got the following scenario Access Point (AP) connected to rest of the nework Mobile Node (MN) connected to AP through a WiFi 802.11g link AP is Master mode MN is Managed mode AP plus MN create a ...

+ Reply to Thread
Results 1 to 2 of 2

Thread: Raw ethernet socket

  1. Raw ethernet socket

    Hi all,
    I've got the following scenario

    Access Point (AP) connected to rest of the nework
    Mobile Node (MN) connected to AP through a WiFi 802.11g link

    AP is Master mode
    MN is Managed mode

    AP plus MN create a subnet (defined by themselves only)

    On both AP and MN a process is running which opens a raw ethernet
    socket; I just fill the Header Source, Destination and Type Options of
    the packet and send it; everything works fine, the parsing is working
    and when I receive a request packet on the AP it replies with response
    to MN and viceversa in a symmetric way

    Everything messes up when I try the same with broadcast destination
    option (FF:FF:FF:FF:FF:FF): when I try this the result is Asymmetric
    and as I send one request from MN, I can se 3 of them on the log
    created by my process on the AP. Then of course I get 3 replies on the
    MN.
    Do you have any clue why this is happening?

    I want to give a couple of hints that maybe could help:
    1) when I read the packets received in the AP through Ethereal I try
    to read them both from the interface ath0 and from the device wifi0
    and I get different results, like in the process of forwarding the
    packet from the hardware device to its interface a new request is
    created.
    2) ethereal on MN and AP reads different number of packets (promisquus
    mode or not)
    -----
    What I think is some sort of repeater inside the AP which clone the
    packet and queue the clones in the stack for some reasons... if you
    have any clue please let me know! Thank you!


  2. Re: Raw ethernet socket

    InuY4sha wrote:
    > Hi all,
    > I've got the following scenario
    >
    > Access Point (AP) connected to rest of the nework
    > Mobile Node (MN) connected to AP through a WiFi 802.11g link
    >
    > AP is Master mode
    > MN is Managed mode
    >
    > AP plus MN create a subnet (defined by themselves only)
    >
    > On both AP and MN a process is running which opens a raw ethernet
    > socket; I just fill the Header Source, Destination and Type Options of
    > the packet and send it; everything works fine, the parsing is working
    > and when I receive a request packet on the AP it replies with response
    > to MN and viceversa in a symmetric way
    >
    > Everything messes up when I try the same with broadcast destination
    > option (FF:FF:FF:FF:FF:FF): when I try this the result is Asymmetric
    > and as I send one request from MN, I can se 3 of them on the log
    > created by my process on the AP. Then of course I get 3 replies on the
    > MN.
    > Do you have any clue why this is happening?
    >
    > I want to give a couple of hints that maybe could help:
    > 1) when I read the packets received in the AP through Ethereal I try
    > to read them both from the interface ath0 and from the device wifi0
    > and I get different results, like in the process of forwarding the
    > packet from the hardware device to its interface a new request is
    > created.
    > 2) ethereal on MN and AP reads different number of packets (promisquus
    > mode or not)
    > -----
    > What I think is some sort of repeater inside the AP which clone the
    > packet and queue the clones in the stack for some reasons... if you
    > have any clue please let me know! Thank you!
    >


    There are two options: either the MN sends it three times (for some
    reason) and thus the packet is send three times over the air. Or as you
    suggest, it is only sent once over the air but is duplicated on the AP.
    You can use a wireless sniffer to pinpoint the cause.

    If your AP has wired interfaces, you can try sending the broadcast
    packet to a wired interface. This may be easier to debug using a third
    host and a hub. You may/may not see the same behaviour.

+ Reply to Thread