Router as LAN extension and second Access Point

Hello everyone! Sorry for such long post… :slight_smile:

Please allow me to start from the beginning, so that this conversation can be of help even to novice users. I want to learn and understand the why behind the required configuration options that will work in the following scenario. Your comments, corrections and suggestions are very welcome.

I have searched the internet and was persuaded to have found enough information to achieve the desired setup. Unfortunately, the information was either outdated (concerning old software versions), too technical (focusing on low-level details) or simply not applicable to Turris devices. Additionally, the likely presence of software bugs and the lack of knowledge to debug the underlying configuration have made it an arduous and unsuccessful task.

I’m experimenting with a Turris Omnia (HW revision CZ11NIC20) running Turris OS (SW version 4.0.3).

The desired setup is to use Turris Omnia LAN and Access Point as an extension of an existing network. The device provided by the ISP is a Modem / Router with LAN and Wireless capabilities. A computer connected to Turris Omnia LAN should be able to communicate with other computers on the ISP router LAN and vice-versa. Seamless wireless client roaming between both Access Points should also be possible. Isolation between LAN and Wireless is not required. Wireless guest network is not required.

1) Connecting the devices

A standard ethernet cable was used for this purpose. One end of the cable was connected to a LAN port on ISP device. Another end of the cable was connected to a LAN port on Turris Omnia.

I have found this LAN-to-LAN connection pretty much on every tutorial concerning similar setups and it seems to be the simplest approach. I know that in Turris OS it’s possible to assign the WAN port to the LAN and maybe it would also work, but it requires more advanced configuration and probably it has some other implications (e.g. firewall settings).

2) Configuring Turris OS

The configuration of Turris OS should be quite simple! Disable DHCP server and maybe update firewall settings. However, this is where things started to go wrong and beyond my basic knowledge.

I need your help to understand the situation and to find a working solution…

I’ve made several attempts, starting from a fresh USB re-flash of Turris OS version 4.0.3 and using the first run wizard of Foris (SW version 100.6) for the initial configuration, resulting on various degrees of misconfiguration and malfunction.

I’ve also tried to use LuCI (SW branch git-19.354.01383-590ecd6) and SSH to inspect the configuration in detail. Even without understanding many aspects of it, I was able to identify some unexpected contradictions.

2a) Local server workflow

Foris configuration:

  • WAN: port disconnected

  • LAN: port 0 connected to ISP router

  • LAN mode: Computer

  • Static IPv4 address, Netmask, Gateway (LAN connection tests OK)

  • Guest Network: disabled

  • DNS forwarding to provider’s resolver (DNS connection tests OK)

  • Wi-Fi 1 & 2 enabled and configured (wireless guests disabled)

Result: a computer connected to LAN port or to wireless Access Point was given an IP address from an unexpected network and unable to reach the internet on both situations.

LuCI configuration: Network > Interfaces:

  • LAN: br-lan aggregates LAN0…4 and WLAN0…1

  • LAN: br-lan displays a “random” MAC address :warning:

  • DHCP server: enabled :warning:

  • IPv6 settings: enabled :warning:

I’ve tried to disable DHCP server and IPv6 settings in LuCI. After a reboot they appear disabled, as expected.

Result: a computer connected to LAN port was unable to obtain an IP address. A computer connected to a wireless Access Point was given an IP address from an unexpected network and unable to reach the internet.

SSH configuration: ifconfig:

  • br-lan displays the same MAC address as wlan1 :warning:

2b) Router mode changed to Computer mode

Started Foris wizard to configure the router mode, with the WAN port connected to the ISP router.

Result: a computer connected to LAN port or to wireless Access Point was given an IP address from an expected network, different from existing network, and able to reach the internet on both situations.

Followed by changing the configuration to Computer mode in Foris, then disconnected the WAN port and connected a LAN port to the ISP router.

Result: a computer connected to LAN port was unable to obtain an IP address. A computer connected to a wireless Access Point was given an IP address from an unexpected network and unable to reach the internet.

LuCI configuration: Network > Interfaces:

  • LAN: br-lan aggregates LAN0…4 and WLAN0…1

  • LAN: br-lan displays the same MAC address as LAN0…3 :warning:

  • DHCP server: disabled

  • IPv6 settings: enabled :warning:

I’ve tried to disable IPv6 settings in LuCI. After a reboot they appear disabled, as expected.

Result: a computer connected to LAN port was given an IP address from the existing network and able to reach the internet. A computer connected to a wireless Access Point was given an IP address from an unexpected network and unable to reach the internet.

SSH configuration: ifconfig:

  • br-lan displays the same MAC address as LAN0…3 :warning:

Did you consult https://openwrt.org/docs/guide-user/network/wifi/dumbap ?

Your setup seems trivial. There is probably problem with DHCP IP address assign. Your ISP probably give you only one IP address hence when you connect more devices on LAN cable which is correct only first one get the IP from DHCP server of your ISP. You have to obtain IP addresses for your LAN that ISP will assign and setup on their DHCP for other your devices. Or you can let turris to assign local IP addreses within given range from your ISP but you have to know the range. You have to distinguish if your ISP modem or device have on ISP side local or internet IP address. Usual setup is that modem get internet IP on wan side and give local IP via internal DNS on LAN side and doing address translation also called as masquerading. But as you want to access ISP servers on LAN there is probably no usual IP translation setup as you want be with all your devices on same network segment.

From link up @anon50890781 you need basically steps since number 3. you don’t need to bound WAN to LAN unless you need extra WAN port that will be connected to LAN network which is described there. And you have to decide if you need DHCP server on your side of segment and with what LAN local IP range - if you are really on LAN of your ISP the ISP’s probably doing NAT on other device in his network. Crucial is to determine what type of IP address you get assigned for first connected device to your modem. IF it is internet wan IP then you need some device e.g. turris to do NAT what is normal setup as ISP only give only one IP address to device behind modem.

Which one do you got?

You want to create a host computer with a Wi-Fi bridge. I was about the same. In my Turis MOX, in its initial configuration wizard (Foris), I went for:

  1. Step Guide Workflow: Local Server
  2. Step Network Interface: no WAN
  3. Step LAN: LAN mode: Computer

The remaining settings and steps do not matter and can be adjusted as you like. Those three steps disable NAT, turn off the firewall and turn off the DHCP server. That is very much your path 2a. Therefore, I am asking which IP you got.

After going through the wizard, you have to enable Wi-Fi. At the end, I faced IPv6 issues and had to do this…

@anon50890781 Thank you for this pointer! Probably I’ve come across it in the past, although I don’t remember.

Indeed it represents the desired scenario. The setup is quite simple, but something went wrong.

I’ve tried to configure as much as possible from Foris. Using the first run wizard with local server workflow resulted in strange configuration that I was unable to understand. There might be something wrong with that script…

Since LuCI is more complex than Foris, my choice was to use LuCI to inspect the configuration but not to change anything that was available in Foris. After all, Foris is one advantage of Turris OS over OpenWrt for basic users like me!

I will make another configuration attempt starting from scratch.

@Twinkie Thanks for your comment! Indeed the desired setup is quite simple…

ISP assigns dynamically only one IP address. ISP provided device (modem / router / AP) is configured with a private LAN (4 ports & wireless AP) and runs the DHCP server (subnet: 192.168.1.0/254).

I just want to “extend” the existing LAN by connecting a Turris Omnia (5 ports & wireless AP). Any device connected to Turris Omnia, wired or wirelessly, should be assigned an IP of the LAN subnet and be able to communicate with other devices connected to the ISP device.

@traud Thanks for your feedback!

Configuration 2a) was very strange! Existing DHCP server is configured with subnet 192.168.1.0/254. However, Turris Omnia was assigned something totally different (e.g. 192.168.73.25). A PC connected to the Omnia on LAN4 was assigned an IP from the same subnet as the Omnia (e.g. 192.168.73.62). However, a PC connected to the wireless AP of the Omnia was given an IP from another subnet (e.g. 192.168.30.41).

I will make another configuration attempt starting from scratch.

Hello everyone! Sorry for spamming this topic with so many consecutive posts. Here is an update about my latest configuration attempt… let’s call it 2c).

TL;DR: unfortunately, the desired setup is still not working! :frowning: Please help!

Started with a fresh USB re-flash of Turris OS 4.0.3.

Followed Foris first run wizard with the local server guided workflow. The wizard finishes without Wi-Fi configuration. Below is the resulting configuration (some values were redacted and replaced by <…>).

# ifconfig

br-guest_turris Link encap:Ethernet  HWaddr FA:A0:36:4D:1C:98  
          inet addr:10.111.222.1  Bcast:10.111.222.255  Mask:255.255.255.0

br-lan    Link encap:Ethernet  HWaddr <MAC_eth1>  
          inet addr:192.168.1.1  Bcast:192.168.1.255  Mask:255.255.255.0

eth0      Link encap:Ethernet  HWaddr <MAC_eth0>
eth1      Link encap:Ethernet  HWaddr <MAC_eth1>
eth2      Link encap:Ethernet  HWaddr <MAC_eth2>

lan0      Link encap:Ethernet  HWaddr <MAC_eth1>
lan1      Link encap:Ethernet  HWaddr <MAC_eth1>
lan2      Link encap:Ethernet  HWaddr <MAC_eth1>
lan3      Link encap:Ethernet  HWaddr <MAC_eth1>
lan4      Link encap:Ethernet  HWaddr <MAC_eth0>

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0

Also used UCI to inspect the configuration. Some UCI output was redacted for brevity.

# uci show network

network.loopback=interface
network.loopback.ifname='lo'
network.loopback.proto='static'
network.loopback.ipaddr='127.0.0.1'
network.loopback.netmask='255.0.0.0'

network.globals=globals
network.globals.ula_prefix='fd6b:62b3:ad3a::/48'

network.lan=interface
network.lan.type='bridge'
network.lan.proto='static'
network.lan.ipaddr='192.168.1.1'
network.lan.netmask='255.255.255.0'
network.lan.ip6assign='60'
network.lan.bridge_empty='1'
network.lan.ifname='lan0' 'lan1' 'lan2' 'lan3' 'lan4'
network.lan._turris_mode='unmanaged'
network.lan.gateway='<IP of main router>'

network.wan=interface
network.wan.ifname='eth2'
network.wan.proto='none'

network.guest_turris=interface
network.guest_turris.enabled='1'
network.guest_turris.type='bridge'
network.guest_turris.proto='static'
network.guest_turris.ipaddr='10.111.222.1'
network.guest_turris.netmask='255.255.255.0'
network.guest_turris.bridge_empty='1'

Wireless is disabled, as expected.

# uci show wireless

wireless.radio0=wifi-device
wireless.radio0.macaddr='<MAC_WiFi_Card_0>'
wireless.radio0.disabled='1'

wireless.radio1=wifi-device
wireless.radio1.macaddr='<MAC_WiFi_Card_1>'
wireless.radio1.disabled='1'

Everything was looking good, so I proceeded with Wi-Fi 1 configuration using Foris.

# ifconfig

wlan0     Link encap:Ethernet  HWaddr <MAC_WiFi_Card_0>

# uci show wireless

wireless.radio0=wifi-device
wireless.radio0.macaddr='<MAC_WiFi_Card_0>'
wireless.radio0.disabled='0'

wireless.default_radio0=wifi-iface
wireless.default_radio0.device='radio0'
wireless.default_radio0.network='lan'
wireless.default_radio0.mode='ap'
wireless.default_radio0.disabled='0'

wireless.guest_iface_0=wifi-iface
wireless.guest_iface_0.disabled='1'
wireless.guest_iface_0.device='radio0'

Everything was looking good, so I proceeded with Wi-Fi 2 configuration using Foris.

# ifconfig

wlan1     Link encap:Ethernet  HWaddr <MAC_WiFi_Card_1> 

# uci show wireless

wireless.radio1=wifi-device
wireless.radio1.macaddr='<MAC_WiFi_Card_1>'
wireless.radio1.disabled='0'

wireless.default_radio1=wifi-iface
wireless.default_radio1.device='radio1'
wireless.default_radio1.network='lan'
wireless.default_radio1.mode='ap'
wireless.default_radio1.disabled='0'

wireless.guest_iface_1=wifi-iface
wireless.guest_iface_1.disabled='1'
wireless.guest_iface_1.device='radio1'

Everything was looking great, so I rebooted the Turris Omnia.

Immediately I’ve noticed something strange to my eyes… the MAC address of br-lan changed! I was not expecting it to change from <MAC_eth1> to <MAC_WiFi_Card_1>. The MAC of br-guest_turris also changed to some “random” MAC address. Is this behaviour normal?!

# ifconfig

br-guest_turris Link encap:Ethernet  HWaddr 46:C4:99:A0:9E:5F

br-lan    Link encap:Ethernet  HWaddr <MAC_WiFi_Card_1>

Another strange thing is that LuCI displays a different MAC address of br-lan. It seems to be “random” and is does not represent any physical hardware. I haven’t checked br-guest_turris.

br-lan_01

The configuration inspected with UCI apparently did not suffer any changes.

I continued with the configuration via LuCI, now following steps 5 to 8 of the OpenWrt Dumb AP guide suggested by @anon50890781 in a previous comment.

Below is the resulting DHCP configuration of Turris Omnia, in full.

# uci show dhcp

dhcp.@dnsmasq[0]=dnsmasq
dhcp.@dnsmasq[0].domainneeded='1'
dhcp.@dnsmasq[0].boguspriv='1'
dhcp.@dnsmasq[0].filterwin2k='0'
dhcp.@dnsmasq[0].localise_queries='1'
dhcp.@dnsmasq[0].rebind_protection='1'
dhcp.@dnsmasq[0].rebind_localhost='1'
dhcp.@dnsmasq[0].local='/lan/'
dhcp.@dnsmasq[0].domain='lan'
dhcp.@dnsmasq[0].expandhosts='1'
dhcp.@dnsmasq[0].nonegcache='0'
dhcp.@dnsmasq[0].authoritative='1'
dhcp.@dnsmasq[0].readethers='1'
dhcp.@dnsmasq[0].leasefile='/tmp/dhcp.leases'
dhcp.@dnsmasq[0].resolvfile='/tmp/resolv.conf.auto'
dhcp.@dnsmasq[0].nonwildcard='1'
dhcp.@dnsmasq[0].localservice='1'
dhcp.@dnsmasq[0].port='0'

dhcp.lan=dhcp
dhcp.lan.interface='lan'
dhcp.lan.ignore='1'

dhcp.wan=dhcp
dhcp.wan.interface='wan'
dhcp.wan.ignore='1'

dhcp.odhcpd=odhcpd
dhcp.odhcpd.maindhcp='0'
dhcp.odhcpd.leasefile='/tmp/hosts/odhcpd'
dhcp.odhcpd.leasetrigger='/usr/sbin/odhcpd-update'
dhcp.odhcpd.loglevel='4'

dhcp.guest_turris=dhcp
dhcp.guest_turris.interface='guest_turris'
dhcp.guest_turris.ignore='0'
dhcp.guest_turris.start='100'
dhcp.guest_turris.limit='150'
dhcp.guest_turris.leasetime='3600'
dhcp.guest_turris.dhcp_option='6,10.111.222.1'

A computer connected to a LAN port worked as expected. Great! :smiley:

On the other hand, a computer connected wirelessly had some troubles… it was given the IP 169.254.250.58! After stoping and disabling the firewall, dnsmasq and odhcpd services (step 6), and renewing the DHCP lease on the client side a few times then it finally worked. Great, the computer was assigned the IP 192.168.1.7 from the existing LAN! :smiley:

It was time to reboot the Turris Omnia one last time and to double check that everything was still working. Configuration looked good in Foris, LuCI and UCI. The firewall, dnsmasq and odhcpd services were stopped and disabled.

The MAC address of br-lan did not change this time. However, br-guest_turris again changed to some “random” MAC address.

# ifconfig

br-guest_turris Link encap:Ethernet  HWaddr 46:A7:33:07:32:F3

br-lan    Link encap:Ethernet  HWaddr <MAC_WiFi_Card_1>

One strange thing is that LuCI again displays a different MAC address of br-lan. It seems to be “random” and is does not represent any physical hardware. I haven’t checked br-guest_turris.

br-lan_02

When connecting a computer wirelessly, it was given the IP 169.254.250.58 again! Trying to renew the DHCP lease on the client side multiple times did not help, obtaining the same IP every time. Trying to reboot Turris Omnia did not help either… :cry:

This thing is driving me crazy! Can anyone please help me to debug and understand what is going wrong with such a simple setup?!

Suggest you stop focussing on the MAC of the bridge device [1] (least for the moment) since it is not being utilised in a way that is likely to cause the grievance with DHCP and probably just a distraction.

Try rebooting the client, else packet capture (client | AP) could shine some light


[1] https://gitlab.labs.nic.cz/turris/turris-os-packages/issues/288

You’re probably right! Nevertheless, proper handling of network interfaces is a critical core feature of a router and I don’t understand how related bugs or inconsistent behaviours remain unfixed for years. I believed it could be a symptom of a serious internal problem…

Rebooting the client computer and connecting wirelessly to Turris Omnia resulted in the same IP 169.254.250.58. It was given the subnet mask 255.255.0.0. The computer does not display any IP for the router or DNS.

Connecting two other devices wirelessly resulted in IP 169.254.249.25 and IP 169.254.207.144. They were given the same subnet mask. They also do not display any IP for the router or DNS.

I don’t know how to do packet capture, much less how to analyse and interpret the results. :frowning:

Those are link-local addresses. In your case, this means that there is no (connection to the) DHCP server. Consequently, nothing works. I recommend to go back to step 2a because that is the path which has to work. There, you mentioned different subnets. That indicates several DHCP servers on your network. To find those servers, you have to learn how to capture packets.

One easy way is to install Wireshark and filter for ‘dhcp’ (in older versions of Wireshark you had to filter for ‘bootp’). There, you see the MAC address of the DHCP server. That should help to find the culprit. You might have problems to capture the DHCP packets because they happen at the very start of the Ethernet/Wi-Fi interface. I recommend to reach out to the Wireshark community for that (and mention your operating system).

The more easier but more expensive (15€) path is to go for a (smart-) managed switch. That can be configured to do Port Mirroring = in one port you attach your existing router, in another port you put your Turris device, and in the third port you put a computer. On that computer, you start Wireshark, again filter for ‘bootp’. Then, you power-up the Turris device and see where it gets that IP from.

Of course, you could do I packet capture directly on your Turris device for free. However, looking at your issues I would go for Wireshark on a host computer behind the Turris device or a switch in front of the Turris device.

Again, your step 2a was the way to go. That has to work and works here for me. I do not see any reason to go ‘down’ to LuCI or SSH. If that does not work with Turris Foris, this should be analyzed. Either there is an issue in your scenario which has to be tracked down for sure, or something very wild is happening on your existing network; which should be tracked down as well.

Thank you all for your suggestions.

Turris OS was automatically updated to version 4.0.5. The situation has improved, without any intervention or manual configuration change. Connecting a computer to any LAN port on Turris Omnia now works perfectly, since a good IP is assigned instantly. Connecting the same computer wirelessly mostly works, but it can take more than 30s to get an IP and sometimes even fails. Connecting mobile devices wirelessly works only on rare occasions, getting a local IP instead.

Indeed, that was my expectation, validated by all the replies received here and what I could find out by reading other relevant sources.

I’m pretty sure there’s only one DHCP server on the network. The major problem now is connecting mobile devices wirelessly. This may indicate a problem within Turris Omnia itself, but I have no explanation at this time…

I will continue to investigate the issue to the best of my abilities and will report here if/when I have meaningful progress.

If your computer takes so long, do Wireshark on/from that. 30 seconds is too long already. If you need help to read the logs, do not hesitate to ask.