0

I'm trying to setup a wifi to ethernet bridge on a RPi model 1B (maybe B+, I can't remember) to connect a device with ethernet only to a wifi network. It's a freshly installed system, so latest Raspbian. I have been following the guide posted by Ingo at this address: Workaround for a wifi bridge on a Raspberry Pi with proxy arp (the Static configuration of proxy arp procedue) and I have at least managed to connect the RPi to the wifi (which by the way uses WPA-EAP as authentication method, not WPA-PSK, in case it's relevant) using systemd-networkd, which is already something. However, when I connect the device to RPi's ethernet (first I connect the ethernet cable with the device on, then I switch on the RPi) the device is not getting an IP address. Running journalctl -b -e to get some logs yield this result (hopefully I've cut the log in the right places):

Aug 18 17:57:15 raspberrypi systemd[1]: Starting proxy arp routing service...
Aug 18 17:57:16 raspberrypi echo[631]: systemd-networkd-wait-online: wlan0 is online
Aug 18 17:57:16 raspberrypi kernel: smsc95xx 1-1.1:1.0 eth0: hardware isn't capable of remote wakeup
Aug 18 17:57:16 raspberrypi systemd-networkd[110]: eth0: Gained carrier
Aug 18 17:57:16 raspberrypi kernel: device wlan0 entered promiscuous mode
Aug 18 17:57:16 raspberrypi systemd[1]: parprouted.service: Can't open PID file /run/parprouted.pid (yet?) after start: No such file or directory
Aug 18 17:57:16 raspberrypi parprouted[640]: Starting.
Aug 18 17:57:16 raspberrypi systemd-networkd[110]: eth0: Lost carrier
Aug 18 17:57:18 raspberrypi systemd-networkd[110]: eth0: Gained IPv6LL
Aug 18 17:57:18 raspberrypi systemd-networkd[110]: eth0: Gained carrier
Aug 18 17:57:18 raspberrypi kernel: smsc95xx 1-1.1:1.0 eth0: link up, 100Mbps, full-duplex, lpa 0xCDE1
Aug 18 17:57:46 raspberrypi systemd[1]: parprouted.service: Start operation timed out. Terminating.
Aug 18 17:57:47 raspberrypi parprouted[640]: Received signal; cleaning up.
Aug 18 17:57:47 raspberrypi parprouted[640]: Terminating.
Aug 18 17:57:47 raspberrypi kernel: device wlan0 left promiscuous mode
Aug 18 17:57:47 raspberrypi systemd-networkd[110]: eth0: Lost carrier
Aug 18 17:57:48 raspberrypi kernel: smsc95xx 1-1.1:1.0 eth0: hardware isn't capable of remote wakeup
Aug 18 17:57:48 raspberrypi systemd[1]: parprouted.service: Failed with result 'timeout'.
Aug 18 17:57:48 raspberrypi systemd[1]: Failed to start proxy arp routing service.
Aug 18 17:57:53 raspberrypi systemd[1]: parprouted.service: Service RestartSec=5s expired, scheduling restart.
Aug 18 17:57:53 raspberrypi systemd[1]: parprouted.service: Scheduled restart job, restart counter is at 5.
Aug 18 17:57:53 raspberrypi systemd[1]: Stopped proxy arp routing service.

and now I'm not sure if this is a hardware limitation of the RPi 1 network card, or if I have made some mistakes somewhere (or if I need to adapt Ingo's guide to my specific hardware). Can anybody suggest something to make this work?

I'm sorry if this looks like a duplicate question - I actually wanted to comment on Ingo's answer but I'm a new user and I don't have the reputation to do that, I can only open a new question.

EDIT: Following Ingo's request, I'm posting the output of ip addr:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether b8:27:eb:43:13:45 brd ff:ff:ff:ff:ff:ff
    inet 10.57.109.29/32 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::ba27:ebff:fe43:1345/64 scope link 
       valid_lft forever preferred_lft forever
3: wlan0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 00:19:86:52:00:bd brd ff:ff:ff:ff:ff:ff
    inet 10.57.109.29/18 brd 10.57.127.255 scope global dynamic wlan0
       valid_lft 43083sec preferred_lft 43083sec
    inet6 fe80::219:86ff:fe52:bd/64 scope link 
       valid_lft forever preferred_lft forever
iacchi
  • 1
  • 2
  • A Raspberry Pi B(+) does not have WiFi on-board. Do you use a USB/WiFi dongle? Do you really need to (pseudo) bridge the device? It may be possible to use routing instead. That's simpler and less error prone. To get an overview about the interfaces can you please [edit](https://raspberrypi.stackexchange.com/posts/116243/edit) your question and add the output of this command to it: `ip addr`? – Ingo Aug 18 '20 at 21:32
  • @Ingo yes, I have a USB dongle (on a self-powered USB hub). I've tried two different ones that I had, but the result is the same. Eventually I'll buy a RPi 4 for the job, but for the moment I'm using my personal RPi 1 to experiment. The device I need to connect in this was is a NAS, which will need to talk to the rest of the devices on the network. I thought that allowing it to get a proper IP from the network DHCP server would be more proper and easier to have it reachable by other computers, but I may go the NAT way with a bunch of port forwards if the bridging fails. – iacchi Aug 19 '20 at 08:45
  • I will look for a simpler setup with subnetting, no need to use additional helpers. Just a moment please... – Ingo Aug 20 '20 at 01:50

1 Answers1

2

I have made a new section to Workaround for a wifi bridge on a Raspberry Pi with proxy arp to use an overlapping subnet. This needs some knowledge about subnets but I have tried to explain it so it should be usable. The advantage is that it doesn't need additional helper programs and its setup is fairly simple.

Because you only want to connect one device, you can use "the smallest possible subnet with 2 ip addresses". Just use Address=192.168.50.253/30 as shown as example in /etc/systemd/network/04-wired.network in the tutorial. This will give you an ip address for the eth0 interface and one ip address for your device and you only lose 4 ip addresses from your main subnet.

Ingo
  • 40,606
  • 15
  • 76
  • 189
  • Thank you @Ingo for your answer! It doesn't quite fit my case (I have no control over the network's DHCP server as I'm a client in the network, not an admin), but I'm sure it'll be very helpful for others. For the moment I'll go the NAT way to see if what I want to do works in general inside this network, then I'll try again bridging if/when I get the RPi 4 for the final setup. – iacchi Aug 21 '20 at 08:30