netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Prism / Hostap Bridge Problems...
       [not found] <41B9B6E9.7010600@novolab.de>
@ 2004-12-10 15:46 ` Brande
  2004-12-11  4:16   ` Jouni Malinen
  2004-12-13 18:48   ` Stephen Hemminger
  0 siblings, 2 replies; 3+ messages in thread
From: Brande @ 2004-12-10 15:46 UTC (permalink / raw)
  To: Brande; +Cc: netdev, linux-net

Hi all,

maybe there is someone who can help...

Problem:

I have a meshcube (www.meshcube.org) with two prim 2.5 mini-pci WLAN 
cards...
wlan0 should connect as client (managed mode) to a normal access point 
which is connected to the internet.
wlan1 should work as accesspoint (master mode).
I would like to bridge between wlan0 and wlan1 so that I can connect 
with my Laptop Client2 to the AccessPoint on wlan1 and go, through the 
wlan0 client connection to the normal AccessPoint, to the internet...

So here is the hardware setup:

Internet ----- AccessPoint (192.168.0.1) -------- CLient/AP Bridge 
(192.168.0.100 (2 cards in one box))                                  
|                                                  |    
                     Laptop Client 1                            my 
Laptop CLient 2
                     (192.168.0.33)                               
(192.168.0.117)

The data of the WLAN devices:

hostap_diag wlan0
Host AP driver diagnostics information for 'wlan0'

NICID: id=0x8013 v1.0.0 (PRISM II (2.5) Mini-PCI (SST parallel flash))
PRIID: id=0x0015 v1.1.1
STAID: id=0x001f v1.7.4 (station firmware)agnostics information for 'wlan0'

hostap_diag wlan1
Host AP driver diagnostics information for 'wlan1'

NICID: id=0x8013 v1.0.0 (PRISM II (2.5) Mini-PCI (SST parallel flash))
PRIID: id=0x0015 v1.1.1
STAID: id=0x001f v1.7.4 (station firmware)agnostics information for 'wlan0'

I have written the following bridge script:

ETHER0=wlan0
ETHER1=wlan1
BRIDGE=br0
BRIDGEIP=192.168.0.100
BRIDGEGW=192.168.0.1
BRIDGENM=255.255.255.0
BRIDGESTP=off           ### must be "on" with more then one bridge

### stop configure ###


echo -n "stopping firewall: "

  iptables -F
  iptables -F -t nat
  iptables -P INPUT ACCEPT
  iptables -P FORWARD ACCEPT
  iptables -P OUTPUT ACCEPT

  echo "*** network is insecure now *** "

echo "done."


case "$1" in

   start)
       echo "Starting service bridge br0"
       echo "Bridge IP will be: $BRIDGEIP"
               ifconfig $ETHER0 promisc up
               ifconfig $ETHER1 promisc up
               sleep 2
       brctl addbr $BRIDGE
       brctl setbridgeprio $BRIDGE 0
               ifconfig $ETHER0 0.0.0.0
               ifconfig $ETHER1 0.0.0.0
       brctl addif $BRIDGE $ETHER0
       brctl addif $BRIDGE $ETHER1
       #brctl stp $BRIDGE $BRIDGESTP
       #brctl sethello $BRIDGE 1
       #brctl setmaxage $BRIDGE 4
       #brctl setfd $BRIDGE 4
               echo "1" > /proc/sys/net/ipv4/ip_forward               
           # I know it's not really neccessary
               ifconfig $BRIDGE $BRIDGEIP netmask $BRIDGENM up   # but 
it was a test
               route add default gw $BRIDGEGW $BRIDGE
       echo -e "Bridge needs 30 sec. to learn table!\n(depends on kernel 
version...)\n"
       ;;


If I start the script the bridge goes up and I can ping the bridge 
(192.168.0.100) from outside with the Laptop Client 1. I can also ping 
my Laptop Client2 from outside but from my Laptop Client2 I can not ping 
the gateway behind the bridge (192.168.0.1) or the Laptop Client1 but I 
can ping the bridge interface from my Laptop Client2 which is connected 
to the WLAN1 AccessPoint in the bridge...

With tcpdump I can see that the there is an arp request from my Laptop 
Client2 on the bridge interface to see who has 192.168.0.1 if I try to 
ping e.g. 192.168.0.1 but I get no reply from the bridge. On my Laptop I 
get the message "Host unreachable".
Looks like that the AccessPoint or the Client in the bridge, the MAC 
address within the arp request from my Laptop Client1 to the one of the 
correspondig interfaces inside the bridge replaced and that that is the 
reason while I can't receive the answer to my arp request. Might this be 
possible? And if - do you know a solution to solve that problem? Or do 
you have another solution with the same effect but without wds please;)


Thanks for your time,
   have fun,
      Brande

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Prism / Hostap Bridge Problems...
  2004-12-10 15:46 ` Prism / Hostap Bridge Problems Brande
@ 2004-12-11  4:16   ` Jouni Malinen
  2004-12-13 18:48   ` Stephen Hemminger
  1 sibling, 0 replies; 3+ messages in thread
From: Jouni Malinen @ 2004-12-11  4:16 UTC (permalink / raw)
  To: Brande; +Cc: netdev, linux-net

On Fri, Dec 10, 2004 at 04:46:40PM +0100, Brande wrote:

> I have a meshcube (www.meshcube.org) with two prim 2.5 mini-pci WLAN 
> cards...
> wlan0 should connect as client (managed mode) to a normal access point 
> which is connected to the internet.
> wlan1 should work as accesspoint (master mode).
> I would like to bridge between wlan0 and wlan1 so that I can connect 

IEEE 802.11 protocol does not support this kind of configuration. The
card in client mode can only send packet with its own layer 2 MAC
address whereas bridge functionality would require that the other MAC
addresses can also be used as source address. If it is enough to handle
only some IP protocols, Proxy ARP or IP routing could be used to setup
this kind of network. Another option would be to use WDS link between
these APs (assuming the other AP supports WDS) and bridge packet through
it.

-- 
Jouni Malinen                                            PGP id EFC895FA

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Prism / Hostap Bridge Problems...
  2004-12-10 15:46 ` Prism / Hostap Bridge Problems Brande
  2004-12-11  4:16   ` Jouni Malinen
@ 2004-12-13 18:48   ` Stephen Hemminger
  1 sibling, 0 replies; 3+ messages in thread
From: Stephen Hemminger @ 2004-12-13 18:48 UTC (permalink / raw)
  To: Brande; +Cc: Brande, netdev, linux-net

Read the FAQ 
http://bridge.sourceforge.net/faq.html
-------------
It doesn't work with my Wireless card!
This is a known problem, and it is not caused by the bridge code. Many wireless cards don't allow spoofing of the source
address. It is a firmware restriction with some chipsets. You might find some information in the bridge mailing list
archives to help.

Has anyone found a way to get around Wavelan not allowing anything but its own MAC address?
(answer by Michael Renzmann (mrenzmann at compulan.de))

Well, for 99% of computer users there will never be a way to get rid of this. For this function a special firmware is
needed. This firmware can be loaded into the RAM of any WaveLAN card, so it could do its job with bridging. But there is
no documentation on the interface available to the public. The only way to achieve this is to have a full version of the
hcf library which controls every function of the card and also allows accessing the card´s RAM. To get this full version
Lucent wants to know that it will be a financial win for them, also you have to sign an NDA. So be sure that you won´t
most probably get access to this peace of software until Lucent does not change its mind in this (which I doubt never
will happen).

If you urgently need to have a wireless LAN card which is able to bridge, you should use one of those having the prism
chipset onboard (manufactured by Harris Intersil). There are drivers for those cards available at www.linux-wlan.com
(which is the website from Absoval), and I found a mail that says that there is the necessary firmware and an upload
tool available for Linux to the public. If you need additional features of an access point you should also talk to
Absoval.

I still don't understand!!
(answer by Mark S. Mathews (mark at absoval.com))

Bridging Ethernet (v2 or 802.3) is predicated on the ability of a station to transmit frames with a source address (SA)
other than its own. This is possible because Ethernet uses a 'transmit and forget'/stateless transmission model.

This isn't possible with 'normal' 802.11 station cards and software because 802.11 station mode doesn't allow the
transmission of frames with 'someone else's source address. The primary reason is that 802.11 is an acknowledged
protocol. If you transmit a frame with someone else's source address, the ACK will never come back to you. The ACK will
be sent to the station whose source address you used.

There are ways to make it work (that's how I earn a living ;-), but it is not always straightforward and you probably
won't get it right without a pretty solid understanding of 802.11, it's modes, and the frame header format.

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2004-12-13 18:48 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
     [not found] <41B9B6E9.7010600@novolab.de>
2004-12-10 15:46 ` Prism / Hostap Bridge Problems Brande
2004-12-11  4:16   ` Jouni Malinen
2004-12-13 18:48   ` Stephen Hemminger

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).