Announcement

Collapse
No announcement yet.

2 wifi ap's at once ?!

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • 2 wifi ap's at once ?!

    this is perhaps just a rumor but it has filtered down to me through the "hacker" grape vine that it is possible to connect to 2 wifi ap's at once on a windows machine. i have some major questions as to how this is possible, as well as how windows acomplishes this. is it puting the card in rf mon and simply useing software to tell the packet types apart or what?! Also, is this atainable on linux, and if not, perhaps me and some of my fellow kind can come up with somthing :P.

  • #2
    Originally posted by Vyrus
    this is perhaps just a rumor but it has filtered down to me through the "hacker" grape vine that it is possible to connect to 2 wifi ap's at once on a windows machine. i have some major questions as to how this is possible, as well as how windows acomplishes this. is it puting the card in rf mon and simply useing software to tell the packet types apart or what?! Also, is this atainable on linux, and if not, perhaps me and some of my fellow kind can come up with somthing :P.
    Some questions:
    Connect or associate?
    "At the same time" using what metric for discrete periods of time?
    "Connect" meaning "receive data" and "at the same time" from more than one Access Point, and/or "send data" to different AP "at the same time" ?
    To two different AP using different [E]SSID and/or different keys?

    I could see multiple wireless NIC where each one can associate at layer 2 to a different AP, but assuming no host-based routing, only one default route.
    I could see Rx of data over multiple channels on the same NIC, but this is generally not association.

    I could envision an application of TDM in a driver to "share" (switch) between AP in serial fashion (this is not really at the same time like a true parallel system would be), and there would be risk for dropped frames and re-transmission unless speed is throttled. It would be hackish if it existed, and probably not have much use except for IntraNet/ExtraNet in addition to Internet use.

    What other purpose or application is there for this that is not solved by existing "roaming" support?

    Comment


    • #3
      The Windows Incarnation

      I ran across this the other day, and I know it doesn't answer your linux questions but thought it to be relevant nevertheless.

      http://research.microsoft.com/netres...fi/default.htm

      Comment


      • #4
        hmm seems that might be where the rumor originated from, and if so it seems that ataining it on linux would require the reverse engenering of the windows service that does it and applying it to a wrapper for linux wifi cards. in short, not somthing i could acomplish :P

        Comment


        • #5
          Though I doubt it would work at this time, a solid foundation exists for it to be developed for linux.

          Kernel options have existed for support to conventional Ethernet and 100BaseT(++) interfaces to support virtualized interfaces to allow multiple IP address binding with dissimilar subnets to the same physical interface.

          In this way, you can ifconfig eth0 and ifconfig eth0:0 and ifconfig eth0:1 and have each "eth0:N" interface (where N is a non-negative integer) have different IP addresses bound to them. These can be on the same subnet, or on dissimilar subnets sharing the same media.

          There could be future support for iwconfig and virtualized wireless interfaces to store association and dhcp/IP-assignment information for each virtual wireless information.

          The missing piece to make this work (assuming it does not yet exist) is software to control switching between interfaces automatically with polling (least desired) or interrupt driven based on packet reception (a bit better) or dynamic based on table lookup with SRC MAC and AP MAC and "etherswitch" software maybe even support for some kind of virtualized VLAN per virtual interface. (Probably fastest, but most complicated.)

          If such a piece were written, and iwcnofig could talk to virtual interfaces (I have not tested this) then I think you would have what you want in Linux land.

          Comment


          • #6
            well perhaps i should qualiffy my previous statement, im sure it could be done but i just ment i dont have the knowlage to do it. my c++ skillz are limtaed as well as my knowlage of osi model network thiory. im sure for sombody who knows what there doing it would be a nice little project but im afraid im a bit to n00bish :P

            Comment


            • #7
              Originally posted by TheCotMan
              Though I doubt it would work at this time, a solid foundation exists for it to be developed for linux.
              While I basically agree with what's been said here so far, I'm wondering if this is a good idea from a radio perspective. It seems as though you're basically creating a type of TDMA access to multiple WiFi networks (i.e., one wireless NIC timesliced between each AP it associates with). Maybe I've missed something here, but this doesn't sound like the best of ideas if throughput's a desirable thing to have.

              Comment


              • #8
                Originally posted by skroo
                While I basically agree with what's been said here so far, I'm wondering if this is a good idea from a radio perspective. It seems as though you're basically creating a type of TDMA access to multiple WiFi networks (i.e., one wireless NIC timesliced between each AP it associates with). Maybe I've missed something here, but this doesn't sound like the best of ideas if throughput's a desirable thing to have.
                Originally posted by TheCotMan
                It would be hackish if it existed, and probably not have much use except for IntraNet/ExtraNet in addition to Internet use.
                :-)

                If the worst solution is used (polling) then there is a huge risk for loss of frames, and speed reduction, and an unreliable, true TDM would exist.

                There may be alternatives that are not so problematic as true time sharing and part of this may depend on hardware, and what kinds of things normally done in hardware can be offloaded to the driver.

                Here is a vaporware example:
                Consider RFMON mode with newer drivers and older Cisco AiroNet 340 cards.
                Have incoming monitoring of frames gathered from the interface in RFMON (wifi0?), and allow a driver or higher layer application to support the 802.11b responses as needed for association as well as table storage of channel src/dst/ap mac as well as which network and IP.

                Rx from several sources is then, not a huge problem, but Tx becomes a problem; how quickly the interface can be switched out of RFMON mode, or how easily the non-wifi0 interface (eth[0-9]:[0-9]) can be used to send out raw, driver manufactured WiFi frames in non-rfmon mode would be an issue to latency and risk for dropped frames?

                If switching is fast enough or not necessary per virtual interface, then Tx at any point in time can be the max for Tx to that "associated" AP at the risk of losing incoming frames from any other channel.

                Such a solution would be a bit clunky, and generally violate the 7 or 5 layer model's intended purpose of modular design and encapsulation, but I think could be made to work.

                It would also push hardware processing to the system, where we could see a whole order of magnitude increase in latency on an unburdened system, and even more when there is a high load average.

                Is it worth it? Heh, my question still is an issue:
                Originally posted by TheCotMan
                It would be hackish if it existed, and probably not have much use except for IntraNet/ExtraNet [Game networks, private LAN, local "unroutable" networks] in addition to Internet use.

                What other purpose or application is there for this that is not solved by existing "roaming" support?

                Comment


                • #9
                  i agree, and as i have stated prevously, im quite sure i am a bit to n00ish to aproch the answer. however, i think the contept is worth it, i can see why this implemnation over 1 wifi card would cause tx and rx errs but even if it meast resorting to 2 wifi cards, one in ad-hoc (of sorts) and one in rfmon, i think it could be a valuble tool. atleast somthing worth investigating

                  Comment


                  • #10
                    Broadcom Supports This - Example of Implementation In an AP

                    It looks like this feature has shown up in an access point as well.

                    Brainslayer from the dd-wrt project (alternative WRT54G Firmware) has figured out a way to make the broadcom radio in the WRT act as multiple SSID's / Access points.

                    Thread url here:
                    http://forum.bsr-clan.de/ftopic3297-0-asc-0.html
                    (low on technical detail; however the source is reputable)

                    Comment


                    • #11
                      well with all this research lying around, i guess i shall have to atempt somthing of the sort :P

                      Comment


                      • #12
                        Originally posted by rusty
                        It looks like this feature has shown up in an access point as well.
                        Hm. OK, not that this isn't sort of an interesting thing to get the hardware to do, but I'm having a hard time seeing the advantages of it. APs and wireless NICs are cheap these days - are the benefits of using this method going to outweigh the shortcomings this introduces, especially when you can spend less than $100 in hardware (assuming both an AP and NIC being required) and achieve the same end result?

                        About the only real advantage I can see is the possible ability to send a single data stream out across multiple networks in chunks, thus making the in-transit traffic harder to intercept in a single stream - but that would be a timing nightmare to get working smoothly in terms of packet reassembly into something meaningful. Hope you've got large and patient buffers on your NICs...

                        Comment


                        • #13
                          well i have a fiew uses in mind but i think with somthing like this, once it becomes practical you will se sevral uses POP up. i think its one of those if you build it it will get used.

                          Comment


                          • #14
                            I dont quite understand how this could work.

                            If the two AP's are on the same channel, then you are going to get large amounts of interference. If the two AP's are on different channels then the client card is going to have to switch between channels VERY quickly.

                            Or am I missing something?

                            Comment


                            • #15
                              If you have two wireless NICs on teo different IP ranges then you can connect to two networks at the same time, though a different channel would be a good idea.

                              Comment

                              Working...
                              X