In ''/​etc/​config/​wireless'',​ locate the existing ''​[[doc:​uci:​wireless#​wifi.networks|wifi-iface]]''​ section and change its network option to point to the WAN interface.

In ''/​etc/​config/​wireless'',​ locate the existing ''​[[doc:​uci:​wireless#​wifi.networks|wifi-iface]]''​ section and change its network option to point to the WAN interface.

-

Change the ''​mode''​ option to ''​sta''​ (Station) and alter the [[doc:​uci:​wireless#​wpa.encryption|encryption options]] to match those of the target network.

+

Change the ''​mode''​ option to ''​sta''​ (Station) and alter the SSID and [[doc:​uci:​wireless#​wpa.encryption|encryption options]] to match those of the target network. Channel doesn'​t necessary have to match.

| ''​config '​wifi-device'​ '​wlan0'​

| ''​config '​wifi-device'​ '​wlan0'​

option '​type' ​ '​broadcom'​

option '​type' ​ '​broadcom'​

-

option '​channel' ​ ​**'​9'​**

+

option '​channel' ​ '​9'​

config '​wifi-iface'​

config '​wifi-iface'​

Line 222:

Line 222:

Please not that in this way client router (192.168.2.1) will masquerade everything EXCEPT AP subnet and AP router (192.168.1.1) will handle packets from client subnet to internet and vica-versa. \\

Please not that in this way client router (192.168.2.1) will masquerade everything EXCEPT AP subnet and AP router (192.168.1.1) will handle packets from client subnet to internet and vica-versa. \\

This is double masquerading which works fine especially if you cannot make it work otherwise. Avoid double NATting whenever possible!!

This is double masquerading which works fine especially if you cannot make it work otherwise. Avoid double NATting whenever possible!!

+

+

===== Using routing : an alternative solution =====

+

(assumption:​ you know how to apply the changes)

+

+

==== Scenario description ====

+

There is a router access point (based on openwrt 12.09 final ) and a router wifi client (based on openwrt 12.09 final). The router access point from now on is called WP (wifi provider) and the router wifi client is called WC (wifi client) The diagram of the network is the following:

+

<​file>​

+

Internet <​---wired--->​ WP <​---wireless--->​ WC

+

</​file>​

+

+

The **WP** is creating a lan network, through wireless and lan ports, using the subnet ''​192.168.10.0/​24''​.

The **WC** instead, is using the wireless to connect to the **WP** and to create a second wifi network.

+

In this case the wireless interface is attached to the network ''​wan''​ as ''​sta''​ mode and is attached to the network ''​lan''​ as ''​ap''​ mode, as follows (file ''/​etc/​config/​wireless''​ ):

+

<​file>​

+

config wifi-iface

+

option device ​ ​radio0

+

option network ​ lan

+

option mode ap

+

option ssid '​Second wifi'

+

option encryption ​ psk2

+

option key '​password.2'​

+

+

config wifi-iface

+

option device ​ ​radio0

+

option network ​ wan

+

option mode '​sta'​

+

option ssid '​Master wifi'

+

option encryption ​ psk2

+

option key '​password.1'​

+

</​file>​

+

+

The second network created by the **WC** is using the subnet ''​192.168.11.0/​24''​ and is getting a dhcp IP on the wan interface, as follows:

+

<​file>​

+

config interface '​lan'​

+

option ifname '​eth0'​

+

option type '​bridge'​

+

option proto '​static'​

+

option ipaddr '​192.168.11.1'​

+

option netmask '​255.255.255.0'​

+

​

+

config interface '​wan'​

+

option proto '​dhcp'​

+

option hostname ​ '​WC'​

+

</​file>​

+

+

Now we want that both networks see each other.

+

+

==== Connecting WC lan side to the WP lan side and to the internet ====

+

For the lan side of **WC** there is not so much problem to reach the ''​192.168.10.0/​24''​ provided by the **WP**. Because the latter is seen as wan network, and to reach that network from the lan side of **WC** only the '​classic'​ forwarding lan->wan is needed. This means, in the file ''/​etc/​config/​firewall'',​ that the following rule is needed:

+

<​file>​

+

config forwarding

+

option src lan

+

option dest wan

+

</​file>​

+

+

In this way requests from the **WC** lan side are allowed to reach the **WC** wan side that contains the **WP** lan network.

+

+

But we should not forget about masquerading (explained briefly at least here [[doc:​uci:​network]] ). By default the wan zone has masquerading,​ but this means that when a computer from the **WC** lan side wants to connect to a computer on the **WP** lan side, its ip will be masqueraded. Therefore we should avoid masquerading when a computer on the **WC** lan side wants to reach an IP address in the network ''​192.168.10.0/​24''​ this is done in this way (file ''/​etc/​config/​firewall''​ ):

+

<​file>​

+

config zone

+

option name wan

+

list ​network ​ '​wan'​

+

option input REJECT

+

option output ​ ​ACCEPT

+

option forward ​ REJECT

+

option masq 1

+

#routed bridged wireless network - start

+

option masq_dest ​ '​!192.168.10.1/​24'​

+

list comment '(do not with !)'

+

list comment ' masquerade what is going to the declared subnet(s)'​

+

list comment '​remember that is "​masq_destination"'​

+

#routed bridged wireless network - end

+

option mtu_fix ​ 1

+

</​file>​

+

+

In this way the **WC** lan side is able to reach the **WP** lan side without "​obscuration"​ and the internet side (this with obscuration by masquerading).

+

+

==== Connecting WP lan side to the WC lan side ====

+

First we should enable the possibility that packets coming on

+

the wan side of **WC** could reach the lan side of **WC**. This

+

is done through forwarding (see [[doc:​uci:​firewall]] and [[inbox:​doc:​iptables_and_firewall]] ).

+

+

In particular we want that if a packet coming on the wan side of **WC** has the source in the network

+

''​192.168.10.0/​24''​ then it is allowed to go through the device (that is: coming from an interface and going to another interface decided by routing rules). So on **WC** in ''/​etc/​config/​firewall''​ we add:

+

<​file>​

+

config rule '​forward_from_master_net'​

+

option src wan

+

option dest lan

+

option src_ip ​ '​192.168.10.0/​24'​

+

option proto all

+

option target ​ ​ACCEPT

+

​

+

#this means: if a packet, of whatever protocol, is coming on the wan side from a source in 192.168.10.0/​24

+

# and the routing rules are sending it towards the lan side, let it pass.

+

</​file>​

+

+

Now it is the turn of configuration on **WP**. First **WP** should know that the **WC** is 'a device to ask' about the network ''​192.168.11.0/​24''​ and this means a static routing rule. But a static routing rule requires a gateway that is consistently reachable. Since **WC** is using dhcp on lan, we have to assign a static dhcp on the **WP** side for **WC**. So on **WP** we modifiy ''/​etc/​config/​dhcp''​ adding a reservation for **WC**.

+

<​file>​

+

config host wc

+

option ip ​192.168.10.20

+

option mac '<​mac address>'​

+

</​file>​

+

+

Now (after we applied the changes on both systems) we have the possibility of defining a static route on **WP** in ''/​etc/​config/​network'':​

+

<​file>​

+

config '​route'​ '​to_repeater'​

+

option '​interface'​ '​lan'​

+

option '​target'​ '​192.168.11.0'​

+

option '​netmask'​ '​255.255.255.0'​

+

option '​gateway'​ '​192.168.10.20'​

+

list comment 'to the wifi repeater'​

+

list comment 'as routed wireless client'​

+

list comment 'as exposed in the owrt wiki'

+

</​file>​

+

+

It seems all but it is not. It is a subtle problem of how the networking standards behave (but once you knwo them, it is ok). On the **WP** the command ''​route -n''​ shows this:

+

<​file>​

+

Destination ​ ​Gateway ​ ​Genmask ​ Flags Metric Ref Use Iface

+

...lines...

+

192.168.10.0 ​ 0.0.0.0 ​ ​255.255.255.0 ​ ​U ​ ​0 ​ 0 0 br-lan

+

192.168.11.0 ​ 192.168.10.20 ​ ​255.255.255.0 ​ ​UG ​ 0 0 0 br-lan

+

</​file>​

+

+

So it seems that if a packet is coming from br-lan and wants to go to 192.168.11.0,​ since it will

+

go through the same interface, no problem should occur. And instead not, different routes, even on the

+

same interface, create a bit of obstacles. It is like that only packets coming from an interface and going through the same interface, when the source of the packet and the destination of the packet are matched by the same routing rule, do not create any problem.

+

+

In the case that the interface is the same (for input and output) but the source of the packet differs from the destination shown in the routing rule, then the packet is stopped. What do we need then? Seems counter-intuitive but: forwarding.

+

+

On **WP** in ''/​etc/​config/​firewall''​ we need a rule that says "a packet coming on the lan side can go through the lan side without being stopped":​

+

<​file>​

+

config forwarding

+

option src '​lan'​

+

option dest '​lan'​

+

</​file>​

+

+

And with this we have ended our problems. Computer in ''​192.168.10.0/​24''​ can communicate with computers in ''​192.168.11.0/​24''​ and viceversa using original ip addresses.