epoch1970
Posts: 1752
Joined: Thu May 05, 2016 9:33 am
Location: Paris, France

Re: A scenario very close to one described...

Thu Apr 26, 2018 9:11 am

JohnEdens wrote:
Wed Apr 25, 2018 10:29 pm
I think the above referenced link is similar to what I want, however I won't be using DHCP and am not sure from the instructions at the link how this would work with static IP addresses. I'm also not sure whether or not I would need three different static IPs in this setup, one for the camera, one for eth0 and one for wlan0.
This thread is a crumbling mess, although "I want wifi and ethernet to play nice" isn't the rarest of requests I would advise you try and create a new thread if you have further issues.

To answer your questions, and looking at the post your were referring to:
  • Drop the dhcpcd part, you'll be working with static addresses
  • Make the Pi's wifi interface a client on the wireless network. I suppose this is DHCP, see if you can get a fixed lease as you'll need to know this address in order to get to the cameras (via NAT, same as having a public website installed at home.)
  • For the ethernet part, take 2 addresses on any network you want, like 192.168.0.1 and 192.168.0.2, use one for the Pi, one for the IP camera.
  • In addition you have to NAT the wifi address, say port 8080/tcp to the IP cam's address, same port. That's an additional iptables rule you need to set in the file mentioned in the post. I think this is what you want.
Overall that will work, but it does not play nice with the rest of the setup (MAC VLAN and monitoring central.) Also, I am not so sure why USB cams would fail and IP cams would work, except IP cams are usually higher quality gear.

So I would advise to install a test machine with the simple setup above, and see if you can reliably get a stream out of the test cam over a few days.
  • If you don't, then the issue is with the wifi link, either in the Pi or in the AP (or both, or somewhere else, wireless is funny like that).
    Further options:
    • Replace the Pi with a dedicated wireless device, like a pocket travel AP (which works as "ethernet to wireless bridge" for a single device) or whatever wireless device your IT recommends. Could play nice with MAC VLAN
    • Replace wifi and Pi with a pair of powerline adapters (one next to the IP cam, one in the monitoring room -- or next the main ethernet switch in the museum building). Will play nice with MAC VLAN
    • Deploy something like POF (plastic optical fiber) instead of ethernet: fast, flexible, small diameter, easy to install, carries no electricity. So it could be easy to install/reinstall. 50m cable runs should be ok. Requires a pair of powered copper-to-fiber adapters at each end, should be cheap but sourcing is a bit of a challenge. Will play nice with MAC VLAN.
  • If you do, then all hail the mighty Pi. You'll still have that pesky VLAN and seamless integration with other cams to contend with.
    Your IT will advise, but let me peddle a solution to it here. You can implement that with Pis and/or big honking servers. That would give you your VLAN and seamless integration, plus a welcome layer of security over the wifi link if you cipher the VPN tunnel(s).
Have fun :)
"S'il n'y a pas de solution, c'est qu'il n'y a pas de problème." Les Shadoks, J. Rouxel

riph72-lumi
Posts: 7
Joined: Wed Jul 19, 2017 8:41 am

Re: How To: Wifi to Ethernet Bridge(Updated for RPi 3)

Thu Apr 26, 2018 10:43 am

jamesh wrote:
Mon Jul 24, 2017 8:45 pm
Or you could just read the official instructions..

https://www.raspberrypi.org/documentati ... s-point.md
I followed this and it worked (which is amazing because I've been struggling with this) 8-)

Shahriar Al Rabbi
Posts: 3
Joined: Mon May 14, 2018 9:53 am

Re: How To: Wifi to Ethernet Bridge(Updated for RPi 3)

Tue Jul 10, 2018 11:43 am

I followed every step and it doesn't work. Moreover, my headless pi 3 doesn't connect to WiFi after reboot. It doesn't connect to the router through ethernet either.
I can't connect to it via vnc or ssh. So I'm blind right now.
I can borrow a friend's monitor to undo the changes. I can undo any changes made using nano. But how do I undo the changes made by the following two commands?

Code: Select all

sudo iptables -t nat -A POSTROUTING -o wlan0 -j MASQUERADE 
and

Code: Select all

sudo sh -c "iptables-save > /etc/iptables.ipv4.nat"

SurferTim
Posts: 1648
Joined: Sat Sep 14, 2013 9:27 am
Location: Miramar Beach, Florida

Re: How To: Wifi to Ethernet Bridge(Updated for RPi 3)

Tue Jul 10, 2018 11:48 am

Access the SD card and remove this file.
/etc/iptables.ipv4.nat

Edit: What do you mean it won't connect to Wifi? You can't bridge a client wireless device to any other network device. It must be an AP.

Shahriar Al Rabbi
Posts: 3
Joined: Mon May 14, 2018 9:53 am

Re: How To: Wifi to Ethernet Bridge(Updated for RPi 3)

Thu Jul 12, 2018 5:39 am

Thank you for the help.
In addition to changing back the contents of the files, I had to run one more command to restore iptables.

Code: Select all

sudo iptables -F
After that, the pi became good as before.

It seems, I am in the wrong thread. I am looking for a way to bridge the pi's wlan0 and eth0 where eth0 serves as an Access Point and the wlan0 connects to any wifi hotpot as usual. in short, wlan0 forwards packets to eth0.

mfa298
Posts: 1202
Joined: Tue Apr 22, 2014 11:18 am

Re: How To: Wifi to Ethernet Bridge(Updated for RPi 3)

Thu Jul 12, 2018 7:47 am

Shahriar Al Rabbi wrote:
Thu Jul 12, 2018 5:39 am
It seems, I am in the wrong thread. I am looking for a way to bridge the pi's wlan0 and eth0 where eth0 serves as an Access Point and the wlan0 connects to any wifi hotpot as usual. in short, wlan0 forwards packets to eth0.
As has been said by several people in this thread already a bridge (where both ports are on the same Ethernet network) is not (usually*) possible due to how Wi-Fi works.

The only option is having the pi act as a router where the Ethernet port is on a different network to the WiFi and the pi routes (and potentially nats) the packets as they pass through.



* there are some extensions (generally proprietary) that might let a client bridge packets like that. There are also some hacks (like proxy arp) that make some things appear to work (but some stuff might fail in unusual ways)

Return to “Networking and servers”

Who is online

Users browsing this forum: jerrm and 9 guests