# Connecting 2 physically separated parts of network with a Wired/Wifi Bridge



## MG (Apr 19, 2020)

Hello, I have a wall-board on which I'm planning to place different single board computers on a cental power supply.
Currently, the whole network works properly but I want to get rid of the UTP wire to the board.
So I configured a Orange Pi PC2 to connect to the LAN with a tiny USB Wifi-stick, while the wired interface is connected to the other sbc's. Both interfaces are in a bridge.

The wifi interface is given a static IP and connects to my modem as supposed. I can ssh into the Orange Pi and from there ssh further to the other sbc's.
The problem is, from other computers connected to my modem, both wired and wireless cannot reach the systems on the board and vice versa because they are separated by this bridge.

What do I need to keep all systems visible to each other on my LAN in the same subnet/ip-range while they are in 2 separate groups, only brought together by the Orange Pi bridge?

The Orange Pi is now install with a GENERIC arm64 system.
The wifi starts with this script in /etc/rc.d:


----------



## MG (Apr 19, 2020)

```
#!/bin/sh

kldload wlan_tkip
kldload wlan_ccmp
kldload wlan_wep
ifconfig wlan create wlandev run0
wpa_supplicant -B -i wlan0 -c /etc/wpa_supplicant.conf
ifconfig wlan0 ssid "wirelez"
dhclient wlan0
ifconfig bridge0 create
ifconfig bridge0 addm wlan0
ifconfig bridge0 addm awg0
ifconfig bridge0 up
```

With another rc.d script I had to bring the awg0 interface up. If that command is included here, it somehow doesn't happen.


----------



## TracyTiger (Apr 20, 2020)

I tried unsuccessfully connecting two LANs via wireless many years ago and eventually found out the wireless protocol I was using wouldn't support it.  That is, only a single session was permitted across the wireless connection, not multiple sessions.  Protocols/Standards change and that may not be a problem now but you may want to check that.


----------



## MG (Apr 21, 2020)

TracyTiger said:


> I tried unsuccessfully connecting two LANs via wireless many years ago and eventually found out the wireless protocol I was using wouldn't support it.  That is, only a single session was permitted across the wireless connection, not multiple sessions.  Protocols/Standards change and that may not be a problem now but you may want to check that.



That could be possible since this is an old Ralink (802.11n) wifi-stick that I have for years. Nothing else, though. Would it be because a hardware switch ignores the wifi bridge in the LAN on hardware-level because the nodes on the other side can't be identified fast enough to keep the wired LAN working properly? My modem might have a hardware-method to merge wired and wireless on it's own network, where a OS-level software configuration isn't sufficient...


----------



## Phishfry (Apr 21, 2020)

I believe you need to configure the security/wpa_supplicant port with the p2p option enabled.




__





						wpa_supplicant / hostapd: Wi-Fi Direct - P2P module
					





					w1.fi
				




I am not sure that FreeBSD has support for this mode.




__





						Trying to to P2P Device Discovery
					





					lists.freebsd.org


----------



## MG (May 1, 2020)

Phishfry said:


> I believe you need to configure the security/wpa_supplicant port with the p2p option enabled.
> 
> 
> 
> ...



I wasn't aware of the external wpa_supplicant port.
Installed it with the p2p option enabled and added setting p2p_disabled=0 to /etc/wpa_supplicant.conf

Also took out individual ip settings of both bridge members. The bridge succesfully takes a DHCP lease from my modem and connects to the gateway. From there, I can ping all other machines on the LAN.

What remains is that I can't reach the sbc-group from my PC or laptop, except the bridge machine, while all are configured on the same subnet. Any attempt, ping, ssh or nc results in timeout. The bridge functionality appears incomplete.

Currently trying to figure the README-P2P file of the wpa_supplicant port but it appears obsoleted. Mentioned settings have disapeared. Also can't get python to run the example scripts while all deps are installed (missing gobject).

wpa_supplicant shows a strange message about which I can't find much: [988]: Failed to add supported operating classes IE


----------



## MG (May 10, 2020)

Update: I think this isn't going to work, so I changed to the "traditional" pf-router setup. Never tried this behind a already existing home-LAN but everything seems to work fine.

Now, is there any configuration possible where machines on 2 subnets can see eachother directly? This is beyond my networking knowledge...

Current network: "modem" subnet: 192.168.2, of which machine 192.168.2.123 connects via wifi and routes internet communication to subnet 192.168.3 computers with 192.168.3.1 as their gateway ip.
Is it possible to make 192.168.3.20 visible from my work PC, which is 192.168.2.5? Currently, I have to manually ssh into 192.168.2.123 and go further from there, as the 192.168.2.x and 192.168.3.x networks can only see eachother when there's a real wire.


----------



## SirDice (May 13, 2020)

MG said:


> Now, is there any configuration possible where machines on 2 subnets can see eachother directly?


No, if they could talk to each other "directly" they would have to be in the same broadcast domain (i.e. the same subnet). The fact it's two subnets means they can never talk to each other directly, only through a router.  





__





						Broadcast domain - Wikipedia
					






					en.wikipedia.org
				






MG said:


> Currently, I have to manually ssh into 192.168.2.123 and go further from there, as the 192.168.2.x and 192.168.3.x networks can only see eachother when there's a real wire.


They don't  need to "see" each other. You do have to make sure your routing is set up properly, and this works both ways. Packets are routed from A to B but you also need to make sure packets from B can route back to A. Routes only look at a packet's destination and passes it to the next hop. This next hop looks at the destination address to decide where to send it next and so on, until it has reached the destination network. The  return packets do the same but the other way around, again it simply looks at the destination address, sends it to the next hop and so on, until it gets to where it needs to be.

It's similar to you traveling by train, you have a train ticket from A to B and there's no direct line between A and B. You hop on a train that travels some distance to a central station, there you may need to switch to a different train that will take you further along the route. Each time you get to a crossing station you need to look at the tables to see which platform has your next train, until you get to the destination. On your return trip you do the same but the order is now reversed.


----------



## MG (May 13, 2020)

SirDice said:


> No, if they could talk to each other "directly" they would have to be in the same broadcast domain (i.e. the same subnet). The fact it's two subnets means they can never talk to each other directly, only through a router.



Thanks, just got that roughly working. For a networking noob, I'm not disappointed.
My modem maintains network 192.168.2.x. On it's webpage, I added a static route to sub-network 192.168.3.x. On the secondary pf-router with outgoing ip 192.168.2.123, I did a  route  -net add 192.168.2.0/24 192.168.2.123'

Now all systems on 192.168.2 and 192.168.3 can ping eachother. I can ssh "up" from 192.168.3 to 192.168.2 but not vice versa.


----------



## SirDice (May 13, 2020)

MG said:


> Thanks, just got that roughly working. For a networking noob, I'm not disappointed.


Excellent. Networking really isn't that difficult. With routing issues I always imagine myself as the packet. Look at the routing table, see which hop comes next. Then go to that device, look at the routing table for the next hop, and so on. Keep going until you hit that "directly" connected network.  Scribble some notes somewhere to keep track, I make crude network diagrams while doing this. It helps me visualize the problem.


----------



## MG (May 13, 2020)

SirDice said:


> Excellent. Networking really isn't that difficult. With routing issues I always imagine myself as the packet. Look at the routing table, see which hop comes next. Then go to that device, look at the routing table for the next hop, and so on. Keep going until you hit that "directly" connected network.  Scribble some notes somewhere to keep track, I make crude network diagrams while doing this. It helps me visualize the problem.



I just found out that ssh to the other network was somehow jammed by some old NAT settings on my modem, which is a very old Zyxel, so that's solved too.

I think the problem was basically that combining 2 separated networks, configured with the same ip range via a bridge isn't a good idea anyway. Wouldn't that technically require that the bridge machine must be able understand the network on low level, like a hardware switch, but at OS-level because there, the 2 interfaces are linked?


----------

