Using Old Router as Wireless AP to New x86-64 PC Router

Ok. I recently finally got my PC turned into a router and working. Now I want to tie in my old router, both use OpenWRT, and use that older device as a Wireless AP for my new router which does not possess it's own wireless hardware.

This is how it's currently setup...

ISP Fiber Line to Home ->
ISP Fiber Line to ISP Fiber to Ethernet Modem ->
Ethernet to OpenWrt RouterPC(192.168.1.1) with 3 interfaces.

eth0
eth1

Are part of a PCIe add in card. And both are tied and set to the br-lan on the RouterPC.

eth2

is part of the PC's motherboard Ethernet NIC and is being used as the WAN interface.

-> Ethernet cables from br-lan(eth0+eth1) ports to

  • eth1(RouterPC) to Old Router acting as a wireless AP(192.168.1.2) with OpenWRT installed via Ethernet cable to Old Router LAN port 2.

  • eth0 to This PC I am posting from.

====

What do I need to do to tie this in properly so I can start getting proper wi-fi from the old router? Or should I be all set? Are there any settings I should check off or on?

Any help would be greatly appreciated. Thank you!

You need to remove the routing side of the router
and make it a Dump AP
what is this device ? And is its OpenWrt a current version eg V23.05.5

1 Like

The most common approach is to use the simple bridged AP recipe:

https://openwrt.org/docs/guide-user/network/wifi/wifiextenders/bridgedap

1 Like

While not actually covering your question, I hope 'old' means >= 802.11ac here - 802.11n and older (while still fully functional) is just showing its ages and slow wireless operations.

https://openwrt.org/toh/gl.inet/gl-mt6000

V23.05.4

My " " old " " router.

https://openwrt.org/toh/gl.inet/gl-mt6000

It's a great router, no doubt, but it can't handle SQM at Gigabit speeds properly. My new Router PC can smash my needs and still be under 25% usage. So I am very happy with my upgrade.

The following photo is some basic connection info with SQM enabled.

Fantastic, so it looks like I had everything setup properly. Thank you for this documentation.

Thank you again. I was able to get back some of the used CPU cycles due to unneeded services being enabled on the AP. This has slightly improved performance. Thank you again for the documentation.

If you're referring to the firewall and dnsmasq, I actually recommend keeping those enabled, but disabling the DHCP server explicitly via the configuration in /etc/config/dhcp. The amount of CPU cycles that those services consume should be trivial (especially on your device) and should not impact performance. You're more likely to see minute-to-minute/day-to-day variability in the RF noise floor/interference in your environment.

1 Like

Why is that? The guide recommends the opposite.

Is the command I need to us, vi /etc/config/dhcp, to alter the file and remove DHCP?
I know cat /etc/config/dhcp simply shows the current configuration.

Example, here is my /etc/config/dhcp from the AP...

root@GL:~# cat /etc/config/dhcp

config dnsmasq
       option domainneeded '1'
       option localise_queries '1'
       option rebind_protection '1'
       option rebind_localhost '1'
       option local '/lan/'
       option domain 'lan'
       option expandhosts '1'
       option cachesize '1000'
       option readethers '1'
       option leasefile '/tmp/dhcp.leases'
       option resolvfile '/tmp/resolv.conf.d/resolv.conf.auto'
       option localservice '1'
       option ednspacket_max '1232'

config dhcp 'lan'
       option interface 'lan'
       option start '100'
       option limit '150'
       option leasetime '12h'
       option dhcpv4 'server'
       option ignore '1'

config odhcpd 'odhcpd'
       option maindhcp '0'
       option leasefile '/tmp/hosts/odhcpd'
       option leasetrigger '/usr/sbin/odhcpd-update'
       option loglevel '4'

root@GL:~#

I mostly disagree with the guide, although it's not critical. My reasons are as follows:

  • Both the firewall and dnsmasq consume very little resources and sit almost entirely idle since the services aren't be actively used.
  • Currently, a sysupgrade will re-enable the services and this can cause two 'surprises':
    • if the network used to manage the AP is not explicitly allowed 'input' to the device, the firewall becoming re-enabled will lock out access to the administrative features of the AP.
    • If the DHCP server isn't explicitly disabled, a rogue DHCP server could start running after a sysupgrade, and this could cause network conflicts/headaches.
  • That said, if the DHCP server is actually disabled via configuration, and the firewall is also configured to ensure input is allowed from the management network, disabling the services is fine insofar as it won't matter if they inadvertently become re-enabled.

You've got the correct configuration to properly disable the DHCP server on the lan.

3 Likes

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.