Help using kmod-trelay as WiFi-to-Ethernet bridge/pseudobridge

[dchang0]

Hi, everyone--

I'm trying to turn a GL.iNet GL-MT300A running OpenWrt into a plain ol' WiFi-N to Ethernet bridge for a PS3 that has a failing WiFi adapter.

Main WiFi router and DHCP server (192.168.13.1) -> WiFi-N (gets 192.168.13.102 via DHCP) | GL-MT300A | eth0.2 Ethernet port -> PS3 Ethernet Port (should get 192.168.13.103 to .150 but fails)

I use the GL-MT300A's eth0.1 Ethernet port (192.168.8.1) to configure it with LuCi.

The PS3 requests an IP via DHCP which should be served by the main WiFi router (DHCP pass-through and bi-directional communication at Layer 2), but no DHCP response is received.

The note at the top of this wiki page seems like it is written at me:

RELAYD - Historically used as a Wi-Fi extender

Using relayd as instructed in this article isn't guaranteed to work.
The most common problem is that the client router cannot pass the DHCP message between the main router and the client connected to the client router. Currently it seems to be the hardware/SOC limitation (related to MAC cloning?)
You may also consider to use WDS or mesh networking.
Instead of relayd it should be possible to use kmod-trelay, the only information about using it can be seen in its source code, if you used it successfully please add a section for it in this article.

relayd does work, but only very rarely, and randomly. Basically, I just have to reset the PS3's networking over and over until it eventually gets an IP via DHCP, and then it will work until the PS3 is turned off.

So, I'd like to try to get kmod-trelay working, but I was only able to find this short set of instructions from this ticket:

https://dev.archive.openwrt.org/ticket/10108

by nbd

OK, then relayd doesn't work, but I already thought of this use case a while ago and wrote a kernel module that you can use as a bridge replacement.
That way you will not have to use ebtables at all.
The package is called trelay (trivial relay). It works like this:

You create a VLAN on your ethernet and configure trelay on that vlan and wlan0.
Then on the other side where you run batman-adv you also create a VLAN interface with the same ID and assign to it the MAC address of the outgoing wlan interface. That way packets should be forwarded in both directions with no MAC address rewriting at all.

I am NOT running batman-adv; my use case is much simpler.

Here's what I've done so far on the GL-MT300A:

1. Connected its wlan0 interface (called "wwan") via WiFi-N to the main WiFi router in WISP repeater mode so that it auto-connects correctly as 192.168.13.102 (IP received via DHCP on the main WiFi router). The GL-MT300A has internet access via this interface. It shows up as wlan-sta in ifconfig -a

2. Installed prepackaged kmod-trelay successfully from the default repository.

3. Edited the file /etc/config/trelay and changed it to:

config trelay
	option enabled	1
	option dev1	eth0.2
	option dev2	wlan0

4. Edited the factory default eth0.2 interface (called "wan") so that it has the same MAC address as the wlan0 interface.

5. Restarted the trelay service and turned off the firewall and firewall_gl services (no firewalls for easier testing).

I do not see any errors in the main syslog at this point.

6. Started up the PS3, which sends a DHCP request.

Ten or so of these messages showed up in the main syslog:

daemon.warn dnsmasq-dhcp[2005]: DHCP packet received on eth0.2 which has no address

The PS3 gave up after getting no DHCP response.

7. Now, I left eth0.2 set to the factory default protocol of DHCP client. After getting the above error, I also tried setting it to Unmanaged, but this does not let me override the MAC address (via LuCi--maybe it can be done via command line).

Based on what I could glean from this other thread, it looks like eth0.2 ("wan") should be Unmanaged:

No DHCP/broadcast forwarding using client with relayd pseudobridge

So this configuration should work? Because it doesn't works root@Misza-LEDE:/etc/config# cat wireless config wifi-device 'radio0' option type 'mac80211' option hwmode '11g' option path 'platform/10180000.wmac' option htmode 'HT20' option channel '6' option legacy_rates '1' option country 'PL' config wifi-iface option ssid 'UPC249250565' option encryption 'psk2' option device 'radio0' option mode 'sta' option bssid '00:36:76:B5:54:FE' option key '********' option ifnam…

I also tried setting eth0.2 to a Static IP address, 192.168.168.1/24, which does allow for the MAC address override, but the error the PS3 generates becomes:

daemon.warn dnsmasq-dhcp[2005]: no address range available for DHCP request via eth0.2

If I change eth0.2 to a static IP address in the same subnet as the wlan0, it will cut off access to both eth0.2 and wlan0, which now both have the same MAC address but different IP addresses in the same subnet.

So, I'm kinda stuck. I think I've followed nbd's instructions correctly, but it's not working.

I have also tried using the interface names that show up in ifconfig -a in /etc/config/trelay like so:

config trelay
	option enabled	1
	option dev1	wlan-sta
	option dev2	eth0.2

No difference; the PS3 still fails to get a DHCP response. HOWEVER, with this config file, I can no longer SSH in via the wlan-sta IP address of 192.168.13.102, because wlan-sta will no longer connect. Looking at the syslog, the corresponding line is:

daemon.notice netifd: wwan (####): Received SIGTERM

So it looks like trelay crashes the interface wlan-sta (called "wwan" in LuCi) if wwan is still set to DHCP client. If it is set to Unmanaged, then it will no longer crash when trelay is restarted, but it gets no IP. The PS3 still fails to receive a DHCP response, but the syslog no longer records any error when it tries.

Any help figuring this out would be appreciated--thanks! It'll probably become the wiki article on how to use kmod-trelay to do simple bridging.

[mk24]

Since the PS3 only needs Internet access, not a full bridge to your LAN, for this you should not use relayd. Instead set up a routed client.

The routed client is basically the default configuration where the Ethernet port remains in the LAN bridge which has a static IP and runs a DHCP server. Then set up a WAN network with a wifi client and DHCP client. The default firewall rules for routing from lan to wan will work.

[dchang0]

Thanks for the suggestion. I tried that first, and while the PS3 does get an IP (192.168.8.###), the PS3 is unable to connect in the game that I play (HellDivers), so I figured a full bridge might be better.

I'll give that a try again; maybe it will be easier to figure out what is wrong with that setup than figure out kmod-trelay.

UPDATE 1: The PS3 CAN connect to the Playstation Network using the typical setup, but the game randomly does not connect. Using the relayd bridge, both PSN and the game can connect reliably once it gets an IP.

I should mention that running a long 25ft Ethernet cable from the router to the PS3 always works 100% of the time. Also, it is not a matter of poor wireless signal from the main router, as there is clear line-of-sight to the router and all other WiFi devices work fine (including a gaming PC). The GL-MT300A claims the WiFi signal is 80% strength when it is the client.

UPDATE 2: I am using the GL-MT300A in the typical repeater setup, and yes, it is unreliable: randomly does not connect, randomly loses connection mid-game. Still much more reliable than the failing internal PS3 WiFi. The relayd setup was more reliable once it got an IP.

Anyway, this is off the original track of this thread, so I'll stop posting here unless I come back to the kmod-trelay approach. Thanks for the help.

[dchang0]

Well, I'm back.

I tried the typical repeater mode and it's just too unreliable. It will cut off in the middle of the game.
The relayd pseudobridge was more reliable.

One thing to note is that this game is very demanding of the network connection--more so than other games that run just fine over the PS3's built-in WiFi or the typical OpenWrt repeater setup. This game seems to be be especially sensitive to latency.

(I'm not in a situation where I can run an Ethernet cable across the middle of the room or around the side except for testing.)

Anyway, I'd like to figure out the kmod-trelay method, assuming that it will be more reliable than the typical repeater mode. All it has to do is match relayd in reliability/performance and also pass DHCP back and forth.

Plus it would be nice to have more examples of how to use kmod-trelay out there in the world.

Thanks in advance!

[dchang0]

I've played a bit more with the GL-MT300A in these modes:

1. typical repeater setup (uses WISP)
2. relayd bridge

The poor reliability in regards to the PS3 game HellDivers appears to be dropped packets. The typical repeater setup is terrible--drops enough packets that the game gets disconnected midgame. The relayd bridge drops fewer packets, so the game is more reliable but still drops out often enough to be a problem.

It seems to be that the router can't handle when the game sends a ton of data to the server, usually during the automatic save/sync. I guess it's filling a buffer and dropping packets at that time.

Dropped packets is not quite the same problem as wanting to get kmod-trelay working, but it does rule out the typical repeater setup completely.

[dchang0]

Updating the GL-MT300A's firmware from the latest stable 2.264 to the beta and "clean" (minimal, i.e. OpenWrt 18 with none of TP-Link's skins/scripts) 3.0 fixed the dropped packets problem in typical repeater mode (WISP).

I can now play the game all the way through without it dropping.

So I don't need kmod-trelay any more, BUT, out of curiosity, I would still like to learn how to use it, if someone can provide examples. I have a second brand new GL-MT300A that I can use as a test device.

[mk24]

Identify the bottlenecks in your network (usually but not always the ISP) and deploy SQM.

[dchang0]

Thanks for the advice.
It turns out that the firmware upgrade (OpenWrt 15 to OpenWrt 18) was enough. The connection is rock solid.
I just tested it today by leaving the game connected for several hours and checking on it every so often. It stayed connected the whole time, so I am good to go.

Still would like to learn kmod-trelay, though.