Sorry for the team of developpers but i tried OpenWRT but I'm very disappointed because it does not work properly with OpenWrt
I still can't do:
Livebox 6 < -WIFI 5GHz - > OpenWrt Repeater STA/LAN < - Lan - > Orange TV + DLNA + Samba + USB Printer
--
The solution is at the end, again a big thank you to our friend lleachii
Despite your continued ranting, you haven't actually explained what problem you perceive to be here.
As the Livebox 6 is not running OpenWrt (at least presumably), WDS/ 4addr is out of the question (this is not a bug), leaving you either with the known problematic relayd or a routed client setup, but you don't specify that either.
Bridging STA interfaces is not a possibility provided by the IEEE 802.11 standards, as it would require sqeezing a fourth MAC address somehow into an IEEE 802.11 packet header which only specifies space for three MAC addresses, there can be no standards compliant way to accomplish this - only proprietary ones, which -by the very nature of it- are incompatible to each other.
One of these proprietary methods provided by mainline kernel drivers built upon the nl80211 stack would be the afforementioned WDS/ 4addr (which works around the header limit by setting up a second backchannel to the main AP to communicate this fourth MAC that way). This approach is compatible between mainline/ nl80211 wireless drivers of different vendors (e.g. ath10{,-ct}, mt76, …}, but not proprietary wireless drivers.
Some proprietary vendors (e.g. Broadcom in the past(?)) have their own proprietary/ incompatible means, I have not followed Mediatek's driver development recently - but that would only apply to their proprietary drivers (which are presumably used by Pandorabox and Padavan), not mt76 or ath10k{,-ct}, which would be the only drivers OpenWrt would care about here.
So unless I'm misunderstanding the problem, there is no bug here - nor any reason to be 'very disappointed', if you expect a feature that's not going to happen with any mainline wireless driver.
I'll add that OpenWrt is not a commercial product. It is an open source project that is staffed by volunteer developers who code in their spare time, often fitting it in with other life obligations like work/school/family/social, etc.
You didn't spend any money, nor did anyone promise you specific functionality that they failed to deliver. If you had purchased a product (hardware and/or software) that was sold on the premise of a specific feature that does not work, voicing your disappointment makes a lot of sense, especially if the company is not responsive in attempts to resolve the issue.
In this case, though, complaining about the fact that this doesn't work for you (especially without providing a lot more context about the details of the problem) really doesn't achieve anything useful.
The solution is at the end, again a big thank you to our friend lleachii
Relayd is something of a hack... it doesn't work in all situations, When it works well in the stock firmware of commercially available devices, it is often because of proprietary, closed source drivers that are not available to open source projects like OpenWrt.
Now, exactly which hardware are you trying to use with OpenWrt? (you've mentioned several devices, and I'm not sure which one you have used to install OpenWrt).
this functionality to be added does not interest anyone
I'm too old to reinvent powder
I therefore edit the content of this request for help
So I think the general concept has been covered pretty well by @slh -- using sta+ap mode in a non-routed configuration is generally a bit of a hack that was not part of the 802.11 spec. The fact that it doesn't work for what you want to do is not the fault of OpenWrt's developers -- it is mostly an issue with the fact that this was not a use case that was considered or was not felt to be critical when the IEEE ratified the 802.11 standard.
If OpenWrt doesn't do what you want, you should look for commercial products that can fill that need... the great thing is that there are plenty of for-profit companies who have devices to sell you that advertise this capability (oh, and spoiler alert -- not all of them are compatible across brands/product lines, but hopefully you'll find one that does what you want).
The solution is at the end, again a big thank you to our friend lleachii
because they are purpose built as repeaters by for-profit companies that employ (i.e. pay) developers to create proprietary code that is kept closed-source for their competitive advantage. Often they have access to the closed source drivers from the chipset vendors, and so they may not be able to release any of the code even if they wanted to.
OpenWrt is not a for-profit company, it does not employ (pay) developers, and as an open source project, it must work within the realm of whatever upstream open source drivers are available and/or develop their own that can be open-sourced.
Sure. Care to lend a hand here? (don't forget that beyond just the technical capability to hack/reverse-engineer such products, there still can be issues with closed source code and/or patents... it's a complex world out there).
As expected.
there are many reasons for this... refer back to @slh 's comments.
this functionality to be added does not interest anyone
I'm too old to reinvent powder
I therefore edit the content of this request for help
There is a very active volunteer development team... in fact just look at the release notes from each of the major recent releases (22.03, 21.02, 19.07, not to mention all of the service releases along the way.
But as you have made clear there is one feature you want out of OpenWrt that does not live up to your desires. So in your eyes, nobody in the development team cares to 'improve' OpenWrt.
I'll tell you what... why don't you roll up your sleeves and start contributing to the development of OpenWrt.
The solution is at the end, again a big thank you to our friend lleachii
Great. Some light reading:
For most developers, it makes sense to stat with the build system. You can set it up with the information provided here:
This is a great retirement project. You can start learning about all the millions of lines of source code that have been written by volunteer developers. And if it takes you several years to understand how this all works, somewhere along the journey you might realize just how much work has gone into this project.
You don't need to contact anyone. But there is an openwrt developers mailing list (just google that), and of course the "for developers" section of the forum.
If you've worked with digital logic, hardware/firmware/software can sometimes be considered interchangeable in that it boils down to logical operators. I mean, hardware and software are very different animals, but if you're versed in digital logic electronics (especially at the bare metal level), you can learn to code.
The solution is at the end, again a big thank you to our friend lleachii
Let us know when you've got a PR that will fix the problems you've been complaining about. 
What you would be looking at (if you were you be serious about it), tends to be (a lot) easier done on x86_64, just add a ath5k/ ath9k/ ath10k/ mt76 WLAN card[0], a mainstream general purpose linux distribution, hostapd/ wpa_supplicant and get cracking on mac80211/ hostapd. Get OpenWrt and its way of managing patches, wrapped in patches, wrapped into a quilt series - with tons of target specific- and generic patches out of the picture, just work on the code that (would) need[s] changing (mac80211/ drivers/ hostapd).
This is also an easy explanation why 'OpenWrt' would be the wrong tree to bark at for this functionality, you're looking at mainline linux and hostapd instead (still not going to happen easily[1]).
--
[0] whatever is easily available, cheap and comes closest to your desired target.
[1] but you'll see the details, once you get intimate with the 802.11 specifications (IEEE RFCs) and the code implementing them
???
It was very difficult to read this thread since the OP vandalized it by editing every post and adding irrelevant text. As a reminder, that doesn't help others interested in reading to solve their problem.
The solution is at the end, again a big thank you to our friend lleachii
You seem to want:
This is called "WiFi bridge" in some marketing terms. Others noted that is not possible.
Is there a reason you're insisting that it is (please do not refrence the proprietary ISP firmware when responding)?
You also put:
config wifi-iface 'wifinet0'
option device 'radio1'
option mode 'sta`
option network 'lan'
STA is an invalid config.
BTW, please stop making mutiple posts for the same issue. I just realized when searching for a reference thread - that you've asked this same question before. Multi posts take away time from others who need help with thier issues too - to be resolved by the community members.
The solution is at the end, again a big thank you to our friend lleachii