Sometimes old solutions work well for modern problems. Attaching a WiFi client interface to a software bridge doesn't work too well, as by default the upstream WAP will only accept frames having a source MAC of a device that's associated. One solution for a relatively static environment is to use proxy ARP.
In this configuration example, wlan0 is the interface with the 'real' network and eth0 is the small stub network.
Enable proxy ARP and IP forwarding with the following sysctl settings:
# Don't forget to load with 'sysctl -p' # after adding to /etc/sysctl.conf # Enable IPv4 forwarding net.ipv4.ip_forward = 1 # Enable proxy arp net.ipv4.conf.all.proxy_arp = 1
Assign an IP address to the external interface and leave eth0 unnumbered. For this purpose the external interface IP could be configured with DHCP rather than static. This example is for Debian / Ubuntu, updating /etc/network/interfaces:
auto wlan0 eth0
# Main network interface iface wlan0 inet static address 192.168.128.100 netmask 255.255.255.0 gateway 192.168.128.1 wpa-ssid "Test WLAN" wpa-psk "super s33cret"
# Stub network interface iface eth0 inet manual # no IP configuration here
# add host routes as post-up scripts via this interface post-up ip route add 192.168.128.200/32 dev eth0
Note that the resulting 192.168.128.0/24 network is split into two broadcast domains - this configuration doesn't result in a flat layer 2 broadcast domain. As such, anything depending on L2 broadcast like DHCP won't work through this, so anything on the stub network will need static IP configuration. It may be possible to get multicast to work, but I doubt link-local multicast addresses will ever work in this configuration since they don't cross the L3 boundary by design.
You can automate this installing parprouted to manage the routes, and dhcp-helper as an application proxy to forward DHCP requests between the partitioned networks. I've had good luck with this configuration, using my Raspberry Pi to provide wireless connectivity for my wired-only TV.