@Joseph-TP , thx for your reply.

But it doesn't really help. 

1.  We are not taking about a change of the MAC address of wireless client on the RE
2. MAC filtering means, you have to allow each client separately. That is not the policy in my local network.
3. The RE hands over the real MAC address of the client. But it changes it's own MAC from real to virtual occassionally. This means a 'change of identiy' for the device RE.

 

Why does the RE do  this change ? 

After a restart the RE uses the real MAC for DHCP request.

After change of MAC the DHCP server of my router denies the refresh of the IP, it isn't the device identified by MAC. The RE then gets a new IP, not the configured one.

 

Edit:

Further investigation shows, that the change just happens without reason.

A short exerpt of the system logs of my internet router:

 

/var/log/messages.21.gz:Feb  5 11:27:02 BitschCop dhcpd: DHCPDISCOVER from b4:b0:24:0b:a7:fe via blue0
/var/log/messages.21.gz:Feb  5 11:27:02 BitschCop dhcpd: DHCPOFFER on 192.168.20.3 to b4:b0:24:0b:a7:fe via blue0
/var/log/messages.21.gz:Feb  5 11:27:03 BitschCop dhcpd: DHCPREQUEST for 192.168.20.3 (192.168.20.1) from b4:b0:24:0b:a7:fe via blue0
/var/log/messages.21.gz:Feb  5 11:27:03 BitschCop dhcpd: DHCPACK on 192.168.20.3 to b4:b0:24:0b:a7:fe via blue0
/var/log/messages.21.gz:Feb  5 11:27:03 BitschCop dhcpd: DHCPREQUEST for 192.168.20.3 (192.168.20.1) from b4:b0:24:0b:a7:fe via blue0
/var/log/messages.21.gz:Feb  5 11:27:03 BitschCop dhcpd: DHCPACK on 192.168.20.3 to b4:b0:24:0b:a7:fe via blue0
/var/log/messages.21.gz:Feb  5 11:27:05 BitschCop dhcpd: DHCPREQUEST for 192.168.20.3 from b4:b0:24:0b:a7:fe via blue0
/var/log/messages.21.gz:Feb  5 11:27:05 BitschCop dhcpd: DHCPACK on 192.168.20.3 to b4:b0:24:0b:a7:fe via blue0
/var/log/messages.21.gz:Feb  5 11:27:07 BitschCop dhcpd: DHCPREQUEST for 192.168.20.3 from b4:b0:24:0b:a7:fe via blue0
/var/log/messages.21.gz:Feb  5 11:27:07 BitschCop dhcpd: DHCPACK on 192.168.20.3 to b4:b0:24:0b:a7:fe via blue0
/var/log/messages.21.gz:Feb  5 11:27:09 BitschCop dhcpd: DHCPREQUEST for 192.168.20.3 from b4:b0:24:0b:a7:fe via blue0
/var/log/messages.21.gz:Feb  5 11:27:09 BitschCop dhcpd: DHCPACK on 192.168.20.3 to b4:b0:24:0b:a7:fe via blue0
/var/log/messages.21.gz:Feb  5 11:27:11 BitschCop dhcpd: DHCPREQUEST for 192.168.20.3 from b4:b0:24:0b:a7:fe via blue0
/var/log/messages.21.gz:Feb  5 11:27:11 BitschCop dhcpd: DHCPACK on 192.168.20.3 to b4:b0:24:0b:a7:fe via blue0
/var/log/messages.21.gz:Feb  5 11:27:13 BitschCop dhcpd: DHCPREQUEST for 192.168.20.3 from b4:b0:24:0b:a7:fe via blue0
/var/log/messages.21.gz:Feb  5 11:27:13 BitschCop dhcpd: DHCPACK on 192.168.20.3 to b4:b0:24:0b:a7:fe via blue0
/var/log/messages.21.gz:Feb  5 11:27:14 BitschCop dhcpd: DHCPREQUEST for 192.168.20.3 from b4:b0:24:0b:a7:fe via blue0
/var/log/messages.21.gz:Feb  5 11:27:14 BitschCop dhcpd: DHCPACK on 192.168.20.3 to b4:b0:24:0b:a7:fe via blue0
/var/log/messages.21.gz:Feb  5 11:27:15 BitschCop dhcpd: DHCPREQUEST for 192.168.20.3 from b4:b0:24:0b:a7:fe via blue0
/var/log/messages.21.gz:Feb  5 11:27:15 BitschCop dhcpd: DHCPACK on 192.168.20.3 to b4:b0:24:0b:a7:fe via blue0
/var/log/messages.21.gz:Feb  5 11:27:16 BitschCop dhcpd: DHCPREQUEST for 192.168.20.3 from b4:b0:24:0b:a7:fe via blue0
/var/log/messages.21.gz:Feb  5 11:27:16 BitschCop dhcpd: DHCPACK on 192.168.20.3 to b4:b0:24:0b:a7:fe via blue0
/var/log/messages.21.gz:Feb  5 11:27:18 BitschCop dhcpd: DHCPDISCOVER from b6:b0:24:0b:a7:fe via blue0
/var/log/messages.21.gz:Feb  5 11:27:19 BitschCop dhcpd: DHCPOFFER on 192.168.20.212 to b6:b0:24:0b:a7:fe (TL-WA860RE) via blue0
/var/log/messages.21.gz:Feb  5 11:27:20 BitschCop dhcpd: DHCPREQUEST for 192.168.20.212 (192.168.20.1) from b6:b0:24:0b:a7:fe (TL-WA860RE) via blue0
/var/log/messages.21.gz:Feb  5 11:27:20 BitschCop dhcpd: DHCPACK on 192.168.20.212 to b6:b0:24:0b:a7:fe (TL-WA860RE) via blue0
/var/log/messages.21.gz:Feb  5 11:27:20 BitschCop dhcpd: DHCPREQUEST for 192.168.20.212 (192.168.20.1) from b6:b0:24:0b:a7:fe (TL-WA860RE) via blue0
/var/log/messages.21.gz:Feb  5 11:27:20 BitschCop dhcpd: DHCPACK on 192.168.20.212 to b6:b0:24:0b:a7:fe (TL-WA860RE) via blue0
/var/log/messages.21.gz:Feb  5 11:27:23 BitschCop dhcpd: DHCPREQUEST for 192.168.20.212 (192.168.20.1) from b6:b0:24:0b:a7:fe (TL-WA860RE) via blue0
/var/log/messages.21.gz:Feb  5 11:27:23 BitschCop dhcpd: DHCPACK on 192.168.20.212 to b6:b0:24:0b:a7:fe (TL-WA860RE) via blue0
/var/log/messages.21.gz:Feb  5 11:27:24 BitschCop dhcpd: DHCPREQUEST for 192.168.20.212 (192.168.20.1) from b6:b0:24:0b:a7:fe (TL-WA860RE) via blue0
/var/log/messages.21.gz:Feb  5 11:27:24 BitschCop dhcpd: DHCPACK on 192.168.20.212 to b6:b0:24:0b:a7:fe (TL-WA860RE) via blue0
/var/log/messages.21.gz:Feb  5 11:57:23 BitschCop dhcpd: DHCPREQUEST for 192.168.20.212 from b6:b0:24:0b:a7:fe (TL-WA860RE) via blue0
/var/log/messages.21.gz:Feb  5 11:57:23 BitschCop dhcpd: DHCPACK on 192.168.20.212 to b6:b0:24:0b:a7:fe (TL-WA860RE) via blue0
/var/log/messages.21.gz:Feb  5 12:27:26 BitschCop dhcpd: DHCPREQUEST for 192.168.20.212 from b6:b0:24:0b:a7:fe (TL-WA860RE) via blue0
/var/log/messages.21.gz:Feb  5 12:27:26 BitschCop dhcpd: DHCPACK on 192.168.20.212 to b6:b0:24:0b:a7:fe (TL-WA860RE) via blue0

DHCP-Parameters: default lease time 60 min, max. lease time 120 min

Why does the RE so many REQUEST/DISCOVER operations?

  @BeBiMa 

 

Hi,

 

If this is just about assigning a particular IP address to the TL-WA860RE, then you could configure a static IP address within the settings of the TL-WA860RE. (i.e. set it to "Use the following IP address" instead of "Obtain an IP address automatically")

 

woozle wrote

  @BeBiMa 

 

Hi,

 

If this is just about assigning a particular IP address to the TL-WA860RE, then you could configure a static IP address within the settings of the TL-WA860RE. (i.e. set it to "Use the following IP address" instead of "Obtain an IP address automatically")

 

This is a possible work around. But the behaviour of the firmware isn't changed.

If you look closely to the log, you can see that the RE sends a host name with the virtual MAC only.

To my understanding the real MAC is the identification in the wireless network of the router, the virtual address is used for relaying the packets of devices attached to the RE.

Is this right?

  @BeBiMa 

 

Apparently it is "right" for this particular model of range extender.

 

The thing is, there is no official standard for what these generic range extenders do. Extending a network wirelessly was not envisaged back when the original networking standards were made.
However, since there appeared to be demand for such kind of devices, manufacturers came up with a few solutions that involve some "trickery" with IP addresses and MAC addresses, in order to make work what wasn't supposed to work.

A little bit of insight into this can be found here: https://community.tp-link.com/en/home/kb/detail/412804

 

I have owned a few generic range extenders myself and they work fine for simple networking (i.e. provide an Internet connection to some client devices), but when trying to do advanced networking stuff the effects of the "trickery" can often be noticed one way or another.
 

  @Joseph-TP  ,  @woozle , I do also only networking.

Just extending my home wifi net. 

 

I know the functionality of proxying, and I can live with it.

The RE sends all traffic from/to the associated clients using its own MAC ( the virtual MAC ).

DHCP clients send their own data (MAC, host name, ...) in the REQUEST packet. So they get the same IP, independent from the connection (directly, over the RE).

The RE itself is a client in the routers WLAN. It gets its own IP from the DHCP server.

What I observed is the fact, that immediately after restart the RE sends (LAN MAC, "") as request; after some time it uses (virtual MAC, "TL-WA860E"), which results in another IP.

I observe difficulties in proxying client connections in this case also.

  @Joseph-TP ,

don't know when and how long the situation occurs.

At the moment, I do a restart each night at 02:30. This clears the error.

The problem doesn't arise daily. 

I can search through the dhcp traffic without autoamtic restart, if it helps.

  @BeBiMa 

 

Well, within the context of this kind of wireless range extenders, trying to assign it a particular IP address of your own choice via DHCP I would already call as "advanced networking".

 

Nevertheless, the Wi-Fi range extenders I own (different models than yours) already have a virtual MAC address right from the beginning, not just after a day or so.

 

Have you already tried to do the DHCP IP address assignment via the TL-WA860RE's virtual MAC address (B6-B0-xx-xx-xx-xx), instead of using its hardware MAC address?

 

On my router the range extender's virtual MAC address is used to have DHCP assign a particular IP address to it and I didn't notice any problems this way.
 

What is "advanced" in this config? The RE is a 'simple' client in my network. It has an web interface, which can be reached by an IP. This IP is set by a DHCP request to the router, this is the default policy in my local network. DHCP server assigns the IPs to devices, which identify by their MAC. The RE identifies after restart with the 'LAN MAC' (real MAC ) which is the same as 'extended 2.4Ghz'. After ~ 1 day dhcpcd restarts ( according to the system logs ) and identifies with virtual MAC, this is another device for the DHCP server of the router. My question is just, why this occurs. Sending the virtual MAC from start wouldn't matter. I can configure the DHCP server to accept this. But what I don't is to define two MACs for the same IP.