2

I'm trying to create the followig setup:

                                +----------+
                                |  Wi-Fi   |
                                +----------+
                                     ^
                                     |
                                     |
                                     |
     +------+           +------+     |
     |      |           |      |+----+
     | VoIP |+--------->| Thin |
     |Phone |           |Client|
     +------+ Ethernet  +------+

The Thin Client and the VoIP phone shall have different ip addresses on the same subnet(the wireless one). So far what i've reached is, to make the br0 interface get a valid ip through dhcp, with the following commands

echo 1 > /proc/sys/net/ipv4/ip_forward

ip link set dev wlan0 up
ip link set dev eth0 up

brctl addbr br0
brctl addif br0 wlan0
brctl addif br0 eth0
ip link set dev br0 up

wpa_supplicant -B -b br0 -i wlan0 -c /home/test/my.wpa.conf
dhclient br0

Routing works, and accessing the internet or Windows terminal server from the thin client work as expected. Am i missing something that needs to be configured to the phone get a valid dhcp lease too?

Listening with tcpdump on the eth0(tcpdump -i eth0 -nevvv) i get no traffic at all, and on wlan0 doing nothing than being connected, just stp topology updates.

Other thing: Masquerade/NAT is not an option, because we want to control the phones on the dhcp, with the mac vendor filter and making they act like different hosts to avoid configuring each phone, and managing them just on the VoIP central.

Cheers

  • Is iptables running on the thin client and, if so, what is its rule set? – phil-lavin Mar 25 '13 at 13:28
  • Have you done an ifconfig br0 up? – NickW Mar 25 '13 at 13:29
  • @phil-lavin Iptables is running on an empty ruleset; –  Mar 25 '13 at 13:44
  • @NickW Yes, i forgot to comment that, sorry. The bridge is up and i can use the ThinClient normally to conect through PC-over-ip and rdp. –  Mar 25 '13 at 13:45
  • What about /proc/sys/net/bridge/ are there any bridge-nf files? – NickW Mar 25 '13 at 14:42
  • 1
    BTW, your wireless card can do proxy arp/arp spoofing? The four requirements for proper bridging: 1 `All devices share the same maximum packet size (MTU). The bridge doesn't fragment packets.` 2 `Devices must look like Ethernet. i.e have 6 byte source and destination address.` 3 `Support promiscuous operation. The bridge needs to be able to receive all network traffic, not just traffic destined for its own address.` 4 `Allow source address spoofing. The bridge must be able to send data over network as if it came from another host.` – NickW Mar 25 '13 at 15:18
  • OK. ill need some time to get this spec, since it's a HP Thin Client and we have no information about internals/parts. –  Mar 25 '13 at 19:03
  • And answering your first question: cat /proc/sys/net/bridge/bridge-nf-* returned 1 on all files. Please let me know if you need any additional info –  Mar 25 '13 at 19:27
  • Just to add: 1 - Mtu are exactly the same(1500); 2- The devices are Ethernet like; 3 - All of them have been set to Promisc(ip link set dev XXX promisc on) and all bridge-nf-* files are set to 1. Any other guess? –  Mar 25 '13 at 19:44
  • Edit1: i've set all the bridge-nf-* to 0, and updated the all.proxy_arp to 1. Still, the dhcp requests from the phone are not forwarded through the bridge. –  Mar 25 '13 at 20:39
  • Hmm, those would have been my first choice.. You need to find out if the wireless card can do proxy arp/arp spoofing. The page I got them from said that a good percentage of wireless cards won't as it's something that wireless cards shouldn't do (probably to avoid collisions).. – NickW Mar 26 '13 at 09:59
  • I'd look into some of the solutions offered, I know for a fact that Mikrotik devices can ARP spoof on wireless, so some of the lower cost examples that Micheal suggests are probably a good idea. – NickW Mar 26 '13 at 10:01
  • Well, after some researching and running in circles, i've figured out that this wireless is a Broadcom chip and it uses the `wl` and `lib80211` modules. Could this be the problem? Compile the `nl80211` and newer `wl` module could solve this? –  Apr 03 '13 at 14:05

3 Answers3

1

As it is, this won't work because the wireless access point on the other end will only allow traffic from the authenticated MAC. There's a potential solution here but that won't work for you, since the entire point is that you want different MACs. (note that your ipv4 forwarding is not necessary because you're not at that layer) As I see it your choices are

  1. Modify the configuration of the wifi AP to allow additional MACs (ideally from a whitelist) from authenticated connections. This is probably not going to work.
  2. Use WDS mode - Wireless Distribution mode, Documentation about it here, sample of someone runnning it here
  3. Use "four address" mode - This is the easiest and I believe should work. http://wireless.kernel.org/en/users/Documentation/iw#Using_4-address_for_AP_and_client_mode
  4. encapsulate the connection - create a tunnel tap0 device using openvpn or similar.
Matthew Parslow
  • 56
  • 2
  • Hi Matthew. I'll try the WDS mode and i'll give a feedback here. The number of macs of this AP should not be a problem, since it's a Motorola Access Point and it have a lot of clients connected on it, with any kind of Mac Filtering. Of course that our DHCP have enough leases to distribute on this network :) –  Mar 26 '13 at 10:41
1

Forget this setup and buy a purpose-built device which performs the same function. These Ethernet-wireless LAN client bridge devices (which can be hard to search for since there's no real standard name for the device's function) range from as little as $20 USD on the low end to $1500 or more for a ruggedized industrial grade device. In an office, you probably don't need IP68 protection, though...

Michael Hampton
  • 237,123
  • 42
  • 477
  • 940
  • but AFAIK bridge mode is point to point, and - if I correctly understand nwildner - here is needed point to multipoint. Or maybe am I wrong? – dsznajder Mar 26 '13 at 13:28
  • Nope, these devices put the end device on the same subnet, which accomplishes the goal stated here. – Michael Hampton Mar 26 '13 at 13:46
  • 1
    We have similar devices to connect different geolocated offices and it's departaments. http://www.ubnt.com/download#doc:Rocket:M - They work flawlessly on WDS mode, so, from that hardware that we got the idea to do the same but with our office wireless(Motorola AP's) and the thin clients + VoIP phones ;) And yes, as @MichaelHampton said, they(Ubiquity radios) make both departaments be in the same subnet without the need of a "point-to-point like" connection –  Mar 26 '13 at 14:08
  • Yeah, we have lots of those Rocket M5 on other offices, where some places get about 1 mile of the nearest switch but, this bridge i'm trying to make, we'll use on the office, where other stations/notebooks are already using our wireless lan. –  Sep 12 '13 at 17:20
0

AFAIK it will not be working.
WiFi AP expect single MAC of single client node. So you can find bridge with wifi, but with modification of outgoing mac. (I can imagine that WiFi card can simulate more than one wireless client but I don't know any existing solution for this.)
I think you should reconsider NAT solution or - if it's possible in your environment - set L2 VPN, like OpenVPN, between eth of thin client and some remote wired VPN concentrator via WiFi.
(If you control all AP then maybe WDS or some mesh network is solution, but I don't think so.)

dsznajder
  • 547
  • 4
  • 13
  • Hi dsnajder. I'll try this way if the WiFi bridge do not work. But first, i'll need to answer all the expectation of the bosses, and if this proves to be impossible to reach(bridge configs), i'll reconsider the NAT solution, for sure. :) –  Mar 26 '13 at 11:06
  • It turns out that i had to make a NAT to make this setup works. However, the quality of the sip connections jumped from very good to no quality at all depending on the utilization of the wireless, making this solution inviable. –  Nov 13 '13 at 16:04