Given that you appear to have a single network segment set up (192.168.6.0/24) for both interfaces on the rpi (let me stress out: appear), then there's only one day to get this done: bridging.

If you want to use routing, then these are the things that you should consider:

They should have separate network segments or you will come into all kind of craziness. Say, keep network for wired/sensor on 192.168.6.0/24 and have 192.168.7.0/24 for wireless.

Then if you are using static IPs on the wifis of rpi/desktop, the simplest thing to do is to add a routing rule on your desktop so that it knows that in order to reach network 192.168.6.0/24, it has to go through the rpi. How to set it up is OS-specific but I'll provide how to do it on linux:

ip route add 192.168.6.0/24 dev wlan0 via 192.168.7.1 # adjust wlan0 to whatever device the wireless is on the laptop

Then, there are other details:

• Is the rpi allowing to forward traffic? sysctl -w net.ipv4.ip_forward=1
• Is the rpi firewall allowing traffic to be forwarded? This has to be checked with iptables. iptables -L FORWARD -nv and the policy and the rules have to be checked. This should allow traffic that is going from the desktop to the sensor to reach the sensor network interface. You can check this by running a sniffer on the rpi (use tshark, for example.... how to use it is outside of the scope of the question).

Then there are more details. Does the sensor know that in order to go back to 192.168.7.0/24 it will have to send the traffic through rpi? If the sensor is set up to have its default gateway to be the rpi, then no problem, when it wants to send traffic to 192.168.7.0/24 it will send it to the rpi and the rpi will be able to send it back to the desktop, but if it's not possible to do this then you have to "fool" the sensor into believing that the traffic was generated by the rpi... this is not that difficult to achieve. This netfilter rule on the rpi would take care of that:

iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE -m comment --comment "masquerade all traffic that is sent out to the sensor"

All kinds of tricky stuff, right?

Given that you appear to have a single network segment set up (192.168.6.0/24) for both interfaces on the rpi (let me stress out: appear), then there's only one day to get this done: bridging.

If you want to use routing, then these are the things that you should consider:

They should have separate network segments or you will come into all kind of craziness. Say, keep network for wired/sensor on 192.168.6.0/24 and have 192.168.7.0/24 for wireless.

Then if you are using static IPs on the wifis of rpi/desktop, the simplest thing to do is to add a routing rule on your desktop so that it knows that in order to reach network 192.168.6.0/24, it has to go through the rpi. How to set it up is OS-specific but I'll provide how to do it on linux:

ip route add 192.168.6.0/24 dev wlan0 via 192.168.7.1 # adjust wlan0 to whatever device the wireless is on the laptop and I'm assuming 192.168.7.1 is the IP of the rpi wireless interface

There's nothing to do in terms of routing on the rpi because the rpi knows what both network segments are and how to reach them so no need to set up any special routing information on it.

Then, there are other details:

• Is the rpi allowing to forward traffic? sysctl -w net.ipv4.ip_forward=1
• Is the rpi firewall allowing traffic to be forwarded? This has to be checked with iptables. iptables -L FORWARD -nv and the policy and the rules have to be checked. This should allow traffic that is going from the desktop to the sensor to reach the sensor network interface. You can check this by running a sniffer on the rpi (use tshark, for example.... how to use it is outside of the scope of the question).

Then there are more details. Does the sensor know that in order to go back to 192.168.7.0/24 it will have to send the traffic through rpi? If the sensor is set up to have its default gateway to be the rpi, then no problem, when it wants to send traffic to 192.168.7.0/24 it will send it to the rpi and the rpi will be able to send it back to the desktop, but if it's not possible to do this then you have to "fool" the sensor into believing that the traffic was generated by the rpi... this is not that difficult to achieve. This netfilter rule on the rpi would take care of that:

iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE -m comment --comment "masquerade all traffic that is sent out to the sensor"

All kinds of tricky stuff, right?