Topic: Issues with DHCP relay (pseudobrige)

The content of this topic has been archived on 5 May 2018. There are no obvious gaps in this topic, but there may still be some posts missing at the end.

Page 1 of 1

Post #1

vic-t

7 Mar 2018, 21:38

I own an Ubiquiti Airrouter running OpenWRT that I'm using to connect several cabled devices to my wireless network. This works fine as long as I'm using static IP's but even after spending several hours on this, I cannot get DHCP addresses coming in from my main router to be relayed.

My setup:

<client> ---[cable]--- <owrt bridge> --[wifi]-- <my_router> ------ <Internet>

Setting up, I followed the instructions exactly as found on the wiki. I also went and checked if there are any updated versions out there but all information I could find more or less confirms what's in the wiki. The only thing I did in the end on top of what's written in the wiki is to give my wwan a static IP and to entirely stop and disable dnsmasq, the firewall, and dhcp.

I ran tcpdump on the client and on the owrt bridge. The DHCP request from the client clearly gets to my_router and my_router sends a valid dhcp reply to the broadcast adress (255.255.255.255). In the tcpdump on owrt bridge, I can verify that the owrt bridge actually receives this reply.

root@OpenWrt:/etc# tcpdump -i any port 68
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes
19:29:27.981849 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:16:3e:0a:ff:da (oui Unknown), length 300
19:29:27.981872 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:16:3e:0a:ff:da (oui Unknown), length 300
19:29:27.982138 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:16:3e:0a:ff:da (oui Unknown), length 300
19:29:28.513557 IP 192.168.0.1.bootps > 255.255.255.255.bootpc: BOOTP/DHCP, Reply, length 300

Unfortunately, however, the DHCP server's reply never makes it to the client. There is no firewall or anything else blocking the communication between the owrt bridge and the client.

Here some other information about my configuration:

root@OpenWrt:/etc# cat openwrt_release
DISTRIB_ID="OpenWrt"
DISTRIB_RELEASE="14.07"
DISTRIB_REVISION="r42625"
DISTRIB_CODENAME="barrier_breaker"
DISTRIB_TARGET="ar71xx/generic"
DISTRIB_DESCRIPTION="OpenWrt Barrier Breaker 14.07"
DISTRIB_TAINTS=""

root@OpenWrt:/etc/config# cat network

config interface 'loopback'
        option ifname 'lo'
        option proto 'static'
        option ipaddr '127.0.0.1'
        option netmask '255.0.0.0'

config globals 'globals'
        option ula_prefix 'fd6e:f1f4:0690::/48'

config interface 'lan'
        option ifname 'eth0'
        option force_link '1'
        option type 'bridge'
        option proto 'static'
        option netmask '255.255.255.0'
        option ip6assign '60'
        option gateway '192.168.0.1'
        option dns '192.168.0.100'
        option ipaddr '192.168.1.1'
        option stp '1'

config interface 'wan'
        option ifname 'eth1'
        option proto 'dhcp'

config interface 'wan6'
        option ifname '@wan'
        option proto 'dhcpv6'

config switch
        option name 'switch0'
        option reset '1'
        option enable_vlan '1'

config switch_vlan
        option device 'switch0'
        option vlan '1'
        option ports '0 1 2 3 4'

config interface 'wwan'
        option proto 'static'
        option ipaddr '192.168.0.201'
        option netmask '255.255.255.0'
        option gateway '192.168.0.1'

config interface 'stabridge'
        option proto 'relay'
        list network 'lan'
        list network 'wwan'
        option ipaddr '192.168.0.201'

root@OpenWrt:/etc/config# cat wireless

config wifi-device 'radio0'
        option type 'mac80211'
        option hwmode '11g'
        option path 'pci0000:00/0000:00:00.0'
        option htmode 'HT20'
        option channel 'auto'

config wifi-iface
        option device 'radio0'
        option mode 'sta'
        option network 'wwan'
        option ssid 'my_router'
        option encryption 'psk2'
        option key '*******'

root@OpenWrt:~# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         192.168.0.1     0.0.0.0         UG    0      0        0 wlan0
192.168.0.0     *               255.255.255.0   U     0      0        0 wlan0
192.168.1.0     *               255.255.255.0   U     0      0        0 br-lan

I'm stuck. Any help would be much appreciated.

(Last edited by vic-t on 7 Mar 2018, 22:19)

Post #2

vic-t

9 Mar 2018, 21:57

I did some further research on the topic. By just adding another entry to the routing table (add -net 192.168.0.0 if br-lan) I can now reach all devices connected directly to the OpenWRT router.

Still, I'm no further on DHCP messages being relayed. As I mentioned in my original post, the DHCP server receives the request and sends a reply back to the mac address of the wlan0 interface on the OpenWRT router, including the mac address of the final recipient computer. But this reply never makes it out of the OpenWRT router. Is there a possibility that my DHCP server is the issue?

Anyway, still hoping someone more experienced can give me a hint what to try next.

Post #3

600cc

10 Mar 2018, 15:01

vic-t wrote:

Setting up, I followed the instructions exactly as found on the wiki.

Do you mean this article? https://openwrt.org/docs/guide-user/net … figuration

If so, then have a read of this thread: https://forum.openwrt.org/viewtopic.php?id=73466

Post #4

vic-t

10 Mar 2018, 15:49

Do you mean this article? openwrt.org/docs/guide-user/net … figuration

This is one of the many articles I read, and I did incorporate some of the information in my configuration. Although the first article I read and originally based my work on was from the OpenWRT archive as found on wiki.openwrt.org/doc/recipes/relayclient. Following these instructions literally to the letter with no deviation, I wasn't successful so I started looking elsewhere.

If so, then have a read of this thread: forum.openwrt.org/viewtopic.php?id=73466

Which part in particular? Maybe I'll just comment in the order of issues discussed in the mentioned thread.

DHCP is working and active on my client interface (I tried another one, too, just to be sure)
My OWRT bridge's IP address is 192.168.1.1 and thus on a different subnet than my router (192.168.0.1)
My OWRT bridge is properly connected to my main router, I have internet access from my client if I'm using a static IP, only DHCP won't work
I understand that relayd should provide layer2 bridging though I don't see what else I can do except from properly configuring the wlan-bridge section in the network file. The relayd process seems to be running with the proper arguments: /usr/sbin/relayd -I br-lan -I wlan0 -B -D

(Last edited by vic-t on 10 Mar 2018, 16:01)

Post #5

600cc

10 Mar 2018, 16:53

Here is a working configuration, derived from that wiki article I linked. I'm typing this reply on a computer connected by cable to OpenWRT, which is connected via WiFi to my usual LAN. My computer has an IP address via DHCP from the subnet allocated to my LAN, so I know it works.

For this test I made one single change from the wiki article (or, rather, I didn't change anything at all). I left the OpenWRT box's IP address as 192.168.1.1, because my usual LAN is on a different subnet. I didn't have to change it to 192.168.2.1, because there was no conflict between subnets.

Feel free to compare this configuration against yours to determine what you might need to change.

For reference, this test was carried out on a GL-iNet MT-G300N (v1), running LEDE 17.01.4, with all included opkg packages updated. The only additional packages I installed were relayd and luci-proto-relay.

/etc/config/wireless

config wifi-device 'radio0'
    option type 'mac80211'
    option hwmode '11g'
    option path 'platform/10180000.wmac'
    option htmode 'HT20'
    option disabled '0'
    option channel 'auto'
    option country 'GB'

config wifi-iface 'default_radio0'
    option device 'radio0'
    option network 'lan'
    option mode 'ap'
    option ssid 'LEDE'
    option encryption 'none'

config wifi-iface
    option network 'wwan'
    option ssid '<redacted>'
    option encryption 'psk2'
    option device 'radio0'
    option mode 'sta'
    option bssid '<redacted>'
    option key '<redacted>'

/etc/config/network

config interface 'loopback'
    option ifname 'lo'
    option proto 'static'
    option ipaddr '127.0.0.1'
    option netmask '255.0.0.0'

config globals 'globals'

config interface 'lan'
    option type 'bridge'
    option ifname 'eth0.1'
    option proto 'static'
    option ipaddr '192.168.1.1'
    option netmask '255.255.255.0'
    option ip6assign '60'
    option delegate '0'

config device 'lan_dev'
    option name 'eth0.1'
    option macaddr 'e4:95:6e:40:72:32'

config interface 'wan'
    option ifname 'eth0.2'
    option proto 'dhcp'

config device 'wan_dev'
    option name 'eth0.2'
    option macaddr 'e4:95:6e:40:72:33'

config interface 'wan6'
    option ifname 'eth0.2'
    option proto 'dhcpv6'

config switch
    option name 'switch0'
    option reset '1'
    option enable_vlan '1'

config switch_vlan
    option device 'switch0'
    option vlan '1'
    option ports '1 2 3 4 6t'

config switch_vlan
    option device 'switch0'
    option vlan '2'
    option ports '0 6t'

config interface 'wwan'
    option proto 'dhcp'

config interface 'repeater_bridge'
    option proto 'relay'
    option delegate '0'
    list network 'lan'
    list network 'wwan'

/etc/config/firewall

config defaults
    option syn_flood '1'
    option input 'ACCEPT'
    option output 'ACCEPT'
    option forward 'REJECT'

config zone
    option name 'lan'
    option input 'ACCEPT'
    option output 'ACCEPT'
    option forward 'ACCEPT'
    option network 'lan wwan repeater_bridge'

config zone
    option name 'wan'
    option input 'REJECT'
    option output 'ACCEPT'
    option forward 'REJECT'
    option masq '1'
    option mtu_fix '1'
    option network 'wan wan6'

config forwarding
    option src 'lan'
    option dest 'wan'

config rule
    option name 'Allow-DHCP-Renew'
    option src 'wan'
    option proto 'udp'
    option dest_port '68'
    option target 'ACCEPT'
    option family 'ipv4'

config rule
    option name 'Allow-Ping'
    option src 'wan'
    option proto 'icmp'
    option icmp_type 'echo-request'
    option family 'ipv4'
    option target 'ACCEPT'

config rule
    option name 'Allow-IGMP'
    option src 'wan'
    option proto 'igmp'
    option family 'ipv4'
    option target 'ACCEPT'

config rule
    option name 'Allow-DHCPv6'
    option src 'wan'
    option proto 'udp'
    option src_ip 'fc00::/6'
    option dest_ip 'fc00::/6'
    option dest_port '546'
    option family 'ipv6'
    option target 'ACCEPT'

config rule
    option name 'Allow-MLD'
    option src 'wan'
    option proto 'icmp'
    option src_ip 'fe80::/10'
    list icmp_type '130/0'
    list icmp_type '131/0'
    list icmp_type '132/0'
    list icmp_type '143/0'
    option family 'ipv6'
    option target 'ACCEPT'

config rule
    option name 'Allow-ICMPv6-Input'
    option src 'wan'
    option proto 'icmp'
    list icmp_type 'echo-request'
    list icmp_type 'echo-reply'
    list icmp_type 'destination-unreachable'
    list icmp_type 'packet-too-big'
    list icmp_type 'time-exceeded'
    list icmp_type 'bad-header'
    list icmp_type 'unknown-header-type'
    list icmp_type 'router-solicitation'
    list icmp_type 'neighbour-solicitation'
    list icmp_type 'router-advertisement'
    list icmp_type 'neighbour-advertisement'
    option limit '1000/sec'
    option family 'ipv6'
    option target 'ACCEPT'

config rule
    option name 'Allow-ICMPv6-Forward'
    option src 'wan'
    option dest '*'
    option proto 'icmp'
    list icmp_type 'echo-request'
    list icmp_type 'echo-reply'
    list icmp_type 'destination-unreachable'
    list icmp_type 'packet-too-big'
    list icmp_type 'time-exceeded'
    list icmp_type 'bad-header'
    list icmp_type 'unknown-header-type'
    option limit '1000/sec'
    option family 'ipv6'
    option target 'ACCEPT'

config rule
    option name 'Allow-IPSec-ESP'
    option src 'wan'
    option dest 'lan'
    option proto 'esp'
    option target 'ACCEPT'

config rule
    option name 'Allow-ISAKMP'
    option src 'wan'
    option dest 'lan'
    option dest_port '500'
    option proto 'udp'
    option target 'ACCEPT'

config include
    option path '/etc/firewall.user'

Post #6

vic-t

10 Mar 2018, 18:44

I'm not sure if it will help if I just copy your config seeing as how we have a different device. Maybe let's have a look at the differences first? Maybe you or someone else will spot the problem, if there is any.

Firewall config: After the initial config failed, I disabled my firewall and all chains are on ACCEPT. I in fact don't need a firewall on this bridge as I'm the only LAN user anyway.

Wireless config: Our configuration is pretty much identical, except that you have an additional interface called "default_radio0". As I understand I only need this interface if I wish for the bridge to be accessible via Wi-Fi, i.e. to act as a repeater - which I don't. The bridge should work for devices connected via Ethernet cable. So I should be able to skip it.

Network config: The main difference between our files is that you are referencing virtual interfaces (such as eth0.1). I don't have those, I have eth1 for my wan (unused), eth0 for the switch (br-lan), and wlan0 for the wifi. Here some other differences:

You seem to have an option called "delegate" in the relay and lan interface configuration. I can't find a reference to this option in the Network configuration wiki (wiki.openwrt.org/doc/uci/network), I'm not sure it's even available in my version but I can try it out.
Your wwan interface is set to dhcp, mine to a static IP. Though I did try it with dhcp first, same effect. I'll set it back to dhcp so our config looks the same here since I can use my router to make it static anyway.
In accordance with various articles I could find on the net, my stabridge has an IP address set so that it can be reached from the LAN subnet. I'll remove the entry, just in case.
Your LAN config doesn't have a gateway or a DNS entry. I guess it shouldn't hurt that I have.

So, I'll make those small changes now and will report back. Please do let me know if you see an issue in my description above.

Post #7

600cc

10 Mar 2018, 19:11

vic-t wrote:

I'm not sure if it will help if I just copy your config seeing as how we have a different device. Maybe let's have a look at the differences first? Maybe you or someone else will spot the problem, if there is any.
Firewall config: After the initial config failed, I disabled my firewall and all chains are on ACCEPT. I in fact don't need a firewall on this bridge as I'm the only LAN user anyway.
Wireless config: Our configuration is pretty much identical, except that you have an additional interface called "default_radio0". As I understand I only need this interface if I wish for the bridge to be accessible via Wi-Fi, i.e. to act as a repeater - which I don't. The bridge should work for devices connected via Ethernet cable. So I should be able to skip it.
Network config: The main difference between our files is that you are referencing virtual interfaces (such as eth0.1). I don't have those, I have eth1 for my wan (unused), eth0 for the switch (br-lan), and wlan0 for the wifi. Here some other differences:
You seem to have an option called "delegate" in the relay and lan interface configuration. I can't find a reference to this option in the Network configuration wiki (wiki.openwrt.org/doc/uci/network), I'm not sure it's even available in my version but I can try it out.
Your wwan interface is set to dhcp, mine to a static IP. Though I did try it with dhcp first, same effect. I'll set it back to dhcp so our config looks the same here since I can use my router to make it static anyway.
In accordance with various articles I could find on the net, my stabridge has an IP address set so that it can be reached from the LAN subnet. I'll remove the entry, just in case.
Your LAN config doesn't have a gateway or a DNS entry. I guess it shouldn't hurt that I have.
So, I'll make those small changes now and will report back. Please do let me know if you see an issue in my description above.

Start by getting the bridge working and passing DHCP traffic from your main router to your computer. The steps described in that wiki article will work. Follow them to the letter. It's easy to lose your place in that article (I did repeatedly) so double-check each step as you go along.

Don't attempt to guess or adapt the instructions for your device, with just one exception: if necessary, make one - and only one - change: the bridge's static IP address. The article says to use the subnet 192.168.2.0/24 with the bridge at 192.168.2.1 - if that conflicts with your main LAN, then pick a different address/subnet for the bridge. Apart from that one potential change, leave the rest of the configuration as described in that article.

Once you've got it working, then you can look at refinements such as accessing the OpenWRT bridge via an IP address accessible from your LAN.

As for the contents of the configuration files, the interface-specific entries such as subinterfaces are an artefact of the build for the chipset in the GL-MT300N. Don't worry about the interface names, they're a red herring.

"Delegate" is an IPv6 option, and may be safely ignored.

Post #8

vic-t

10 Mar 2018, 19:27

I'm still not getting anywhere.. I've adapted my configuration files to make them as simple as possible - they are basically a copy of what you have (or what is described in the article). See for yourself.

/etc/config/network: 
------------------------------------------------
config interface 'loopback'
        option ifname 'lo'
        option proto 'static'
        option ipaddr '127.0.0.1'
        option netmask '255.0.0.0'

config globals 'globals'
        option ula_prefix 'fd6e:f1f4:0690::/48'

config interface 'lan'
        option ifname 'eth0'
        option type 'bridge'
        option proto 'static'
        option netmask '255.255.255.0'
        option ip6assign '60'
        option ipaddr '192.168.1.1'
        option delegate '0'

config interface 'wan'
        option ifname 'eth1'
        option proto 'dhcp'

config interface 'wan6'
        option ifname '@wan'
        option proto 'dhcpv6'

config switch
        option name 'switch0'
        option reset '1'
        option enable_vlan '1'

config switch_vlan
        option device 'switch0'
        option vlan '1'
        option ports '0 1 2 3 4'

config interface 'wwan'
        option proto 'dhcp'

config interface 'stabridge'
        option proto 'relay'
        list network 'lan'
        list network 'wwan'
        option delegate '0'

I'm not even attaching my wireless config as it's exactly the same as yours.

So I restarted the network using /etc/init.d/network restart. Then confirmed relayd is working with the correct configuration - it is.

root@OpenWrt:~# ps | grep relayd
 2984 root       900 S    /usr/sbin/relayd -I br-lan -I wlan0
 3111 root      1356 S    grep relayd

Then made a tcpdump on my br-lan interface. As you can see, the client is sending requests to this interface but is not getting anything in return.

root@OpenWrt:~# tcpdump -i br-lan port 68
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on br-lan, link-type EN10MB (Ethernet), capture size 65535 bytes
18:05:50.083323 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:16:3e:0a:ff:da (oui Unknown), length 300
18:05:53.455093 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:16:3e:0a:ff:da (oui Unknown), length 300
18:05:58.871694 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:16:3e:0a:ff:da (oui Unknown), length 300
18:06:06.822163 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:16:3e:0a:ff:da (oui Unknown), length 300
18:06:15.971457 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:16:3e:0a:ff:da (oui Unknown), length 300

Doing the same on the wlan0 interface, you can see both the discover message from the client as well as the offer message from the dhcp server:

root@OpenWrt:/etc/config# tcpdump -i wlan0 port 68 -v
tcpdump: listening on wlan0, link-type EN10MB (Ethernet), capture size 65535 bytes
18:19:47.426821 IP (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 328)
    0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:16:3e:0a:ff:da (oui Unknown), length 300, xid 0x94b11841, secs 17, Flags [Broadcast]
          Client-Ethernet-Address 00:16:3e:0a:ff:da (oui Unknown)
          Vendor-rfc1048 Extensions
            Magic Cookie 0x63825363
            DHCP-Message Option 53, length 1: Discover
            Requested-IP Option 50, length 4: 192.168.0.198
            Hostname Option 12, length 4: "net1"
            Parameter-Request Option 55, length 13:
              Subnet-Mask, BR, Time-Zone, Default-Gateway
              Domain-Name, Domain-Name-Server, Option 119, Hostname
              Netbios-Name-Server, Netbios-Scope, MTU, Classless-Static-Route
              NTP
18:19:47.431527 IP (tos 0x0, ttl 16, id 0, offset 0, flags [none], proto UDP (17), length 328)
    gateway.example.com.bootps > 255.255.255.255.bootpc: BOOTP/DHCP, Reply, length 300, xid 0x94b11841, Flags [Broadcast]
          Your-IP 192.168.0.198
          Server-IP gateway.example.com
          Client-Ethernet-Address 00:16:3e:0a:ff:da (oui Unknown)
          Vendor-rfc1048 Extensions
            Magic Cookie 0x63825363
            DHCP-Message Option 53, length 1: Offer
            Server-ID Option 54, length 4: gateway.example.com
            Lease-Time Option 51, length 4: 600
            Subnet-Mask Option 1, length 4: 255.255.255.0
            Default-Gateway Option 3, length 4: gateway.example.com
            Domain-Name-Server Option 6, length 4: nameserver.example.com

But the offer message never makes it out of the br-lan interface.

Post #9

vic-t

10 Mar 2018, 19:30

I just noticed something. I completely dismissed your "dev" settings in the network configuration. I didn't understand its purpose, why manually assign a mac address? So I ran ifconfig and had a closer look at the mac addresses. All interfaces (br-lan, wlan0, eth0, eth1) have the same mac address. That doesn't seem right though?

Post #10

600cc

10 Mar 2018, 19:48

vic-t wrote:

I just noticed something. I completely dismissed your "dev" settings in the network configuration. I didn't understand its purpose, why manually assign a mac address? So I ran ifconfig and had a closer look at the mac addresses. All interfaces (br-lan, wlan0, eth0, eth1) have the same mac address. That doesn't seem right though?

It can catch you unawares but, like the interface names, it's a red herring. The MAC address works at layer 2 of the OSI model. IP addresses work at layer 3, and DHCP works at layer 7.

The logical interfaces (br-lan, wlan0, eth0, eth1) can share the same physical interface (MAC address). It will make sense in time, but it can be ignored for now.

Rather than copying/pasting configuration files which might or might not be suitable for your device, I recommend:

Flash LEDE 17.01.4 on to your device, if it isn't already.
Reset LEDE to factory defaults.
Apply all opkg package updates for the built-in packages.
Follow the steps in https://openwrt.org/docs/guide-user/net … iguration, from the top of the page to halfway down. Stop where you see "Setup with CLI". The second half of the page is a repeat of the first half of the page, but from a CLI perspective. Just install relayd and luci-proto-relay and configure through the web GUI.
After successful configuration through the GUI, then look at the configuration files in /etc/config and use them for reference.

(Last edited by 600cc on 10 Mar 2018, 19:51)

Post #11

vic-t

10 Mar 2018, 20:17

Just fyi, randomizing the mac addresses didn't change anything.

I wasn't aware that LEDE is even an option for my device.. I see that it's not really recommended but I'll give it a shot anyway. Will report back.

Post #12

600cc

10 Mar 2018, 20:24

Yeah, it's not recommended (32MB RAM is a bit low; 64MB is the recommended minimum these days) but it should work. I've installed LEDE 17.01.4 on three TP-Link TL-WR710N units, all of which have 32MB. I expect support to be dropped (or at least reduced) from OpenWRT 18.01 onwards.

Post #13

vic-t

10 Mar 2018, 21:16

Upgraded to LEDE with a swipe of the configuration, reconfigured to the letter according to the instructions in the LEDE wiki, i.e. using LUCI, our config files now practically look the same. After verifying that all changes in LUCI were actually reflected in the config files, I rebooted. Unfortunately, dhcp is still not being relayed.

I'm going to try now again to randomize the mac addresses. It's the only thing left for me to try, I'm out of ideas otherwise.

Post #14

vic-t

10 Mar 2018, 22:15

Making the mac addresses unique didn't change a thing..

The relay setup is simple enough, I'm sure I got it right (I even did it twice). So at this point I just have to guess that either OpenWRT/LEDE is not fully compatible with my device, or that my specific device has an issue.

Out of curiosity, is there any way to trace or log what relayd is doing? Maybe it would point me to the exact problem.

Post #15

600cc

10 Mar 2018, 22:26

Try logread -e relayd

(Last edited by 600cc on 10 Mar 2018, 22:26)

The discussion might have continued from here.

Page 1 of 1