Networking - OpenRC and Interface type detection.

[tatuzemdp]

Describe the bug
If the system detects that there is a ethernet card and that card is not configured on rc.conf the rc scripts think the card has WPA feature and tries to run wpa_supplicant on the ethernet card.

To Reproduce
Steps to reproduce the behavior:
1 - install an ethernet card.
2 - remove any related configuration from rc.conf (if there is any).
3 - serivce network restart (or just a plain install).
4 - to fix it define the interface unde rc.conf (ifconfig_igb0="")

Expected behavior
if an Ethernet card is not configured, it need to be just left inactive or default config (up, link and nothing else, apart from inet6 address that will pick it up automatically).

OS Version:

• Trident Beta3.

Additional context

• been checking the rc scripts and seems that the wpa function return that the card supports WPA and then it triggers the wpa_supplicant script.

[RodMyers]

Have you attempted to use RC3?

[tatuze]

Hi Rod, sorry for the delay.. i updated to the latest Trident release and is still the same..

[RodMyers]

give the release ISO a try

[tatuze]

Hi Rod, sorry for the delay, was on holidays :)

Indeed its the same with the new release, the "issue" is with the network.subr script.

The function ifconfig_up() on line 230 check if WPA is enabled (if wpaif $1;then) that is alright if you don't set WPA as a default options for all interfaces. This line causes WPA to executed for each interfaces, including TUN, Bridge and wired interfaces which is wrong.

There is a quick workaround as there is already a function that is called is_wired_interface that can we used to check if the interface is wired, if this is true then WPA should not be executed. The thing is that this will not help if the interface is a tunnel interface as the is_wired_interface will fail..

Long term fix is to add a function to detect if we are talking about a wireless interfaces and if its the case then execute any protocols related to wireless interfaces.

If you guys want i can work something out, but the thing is that I believe that this need to go to trueOS and not to trident, true?

Best regards.

Santi

[beanpole135]

Yes, fixes for network.subr would need to get sent to TrueOS.
Thanks for tracking that down and working out a possible solution though!

https://github.com/trueos/trueos

Quick note: Make sure you send a PR to the trueos-master branch, and then request that it be backported to the trueos-stable-18.12 branch as well. (Project Trident follows the stable branches, so we will not get fixes that get committed into master until 19.06 unless they get backported).

[tatuze]

Will do! Thanks Ken and Rod for the support! cheers santi

…

On 28 Jan 2019, at 15:32, Ken Moore ***@***.***> wrote: Closed #27. — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.