Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Bug] Connected WLAN's "Router" unknown in debug menu of HeliPort (but shown in SysPrefs) #104

Closed
mackonsti opened this issue Jul 18, 2020 · 19 comments · Fixed by #118
Closed
Labels
bug Something isn't working enhancement New feature or request
Projects
Milestone

Comments

@mackonsti
Copy link

mackonsti commented Jul 18, 2020

Although this could be is an itlwm.kext issue, I am reporting it here as it involves UI as well. Please assign this accordingly. Thanks.

Describe the bug
On HeliPort.app and with the debug menu shown (via Option key on keyboard and clicking on the menubar icon) I can see the connected WLAN network and IP address obtained and other kext information, but "Router" remains "Unknown".

To Reproduce
Steps to reproduce the behavior:

  1. With Option key on keyboard, click on HeliPort icon on menubar;
  2. Verify the SSID is connected and data is displayed;
  3. Check "Router" information displayed;
  4. On both 2.4GHz and 5GHz Wi-Fi networks of the same router, it's shown as "Unknown";
  5. Go to System Preferences and Network section;
  6. Click on the Intel WLAN device: Router information is there.

Expected behavior
Not sure what's supposed to be shown in "Router" so I can guess the Gateway information that's 192.168.1.1 i.e. my Asus router's IP. This information is displayed just fine in System Preferences -> Network -> ITLWM device tab.

Screenshots
Please see below both HeliPort and System Preferences:

Router

Network

Environment (please complete the following information):

  • OS Version: Mojave 10.14.6
  • Software Version: Commits up to 2020-07-17

Additional context
I tested on both 2.4GHz and 5GHz of my Asus RT-AC58U router, same result. Thanks.

@mackonsti mackonsti changed the title [Bug] Connected WLAN's "Router" not detected in debug menu of HeliPort (but shown in SysPrefs) [Bug] Connected WLAN's "Router" unknown in debug menu of HeliPort (but shown in SysPrefs) Jul 18, 2020
@williambj1
Copy link
Collaborator

CC @ErrorErrorError

@ErrorErrorError
Copy link
Collaborator

@mackonsti Do you have any logs that print out on Xcode? I wan't to know if it doesn't find the interface or ip address since it uses SystemConfiguration, which is the recommended API from Apple to find out network state.

@mackonsti
Copy link
Author

mackonsti commented Jul 18, 2020

I am sorry @ErrorErrorError I think I can't provide what you need. I do not run Xcode, I am on Mojave too. I ran the pre-compiled HeliPort.app from https://github.com/1hbb/OpenIntelWireless-Factory/releases
I am simply a power user not a developer :-( Let me know if I can do anything else to helping you?

As the driver does show the Router and DNS etc. in System Preferences via DHCP (not manually entered) is there no way to see how itlwm works maybe? (just an idea, possibly not even working the same way...)

I would be happy to test a debug-verbose version of HeliPort that you could provide, if you have time, so I can copy-paste the output from Console etc. for your information?

@ErrorErrorError
Copy link
Collaborator

I am sorry @ErrorErrorError I think I can't provide what you need. I do not run Xcode, I am on Mojave too. I ran the pre-compiled HeliPort.app from https://github.com/1hbb/OpenIntelWireless-Factory/releases
I am simply a power user not a developer :-( Let me know if I can do anything else to helping you?

As the driver does show the Router and DNS etc. in System Preferences via DHCP (not manually entered) is there no way to see how itlwm works maybe? (just an idea, possibly not even working the same way...)

If you don't mind, can you open terminal and type scutil and press enter. After that, you should see a right arrow symbol,>. I want you to type show State:/Network/Global/IPv4 and let me know if you see any information regarding router IP.

@mackonsti
Copy link
Author

Of course. Here it is. I do get Router value. Had to disable en0 first (the Ethernet controller) and repeated the command once WLAN en1 had connected to my router:

$ scutil
> show State:/Network/Global/IPv4
<dictionary> {
  PrimaryInterface : en0
  PrimaryService : C6D7BE42-DB00-4CE9-8F17-1CC78F9EABA1
  Router : 192.168.1.1
}
> show State:/Network/Global/IPv4
<dictionary> {
  PrimaryInterface : en1
  PrimaryService : 84278F6F-6984-497E-B557-4714EFF85CE0
  Router : 192.168.1.1
}
> quit

@ErrorErrorError
Copy link
Collaborator

Hm, can you check if you see the router address showing in HeliPort? The commands seems to work fine so it should get those same results.

@mackonsti
Copy link
Author

mackonsti commented Jul 18, 2020

Yes now I can see it!
I think that after turning the Wireless controller OFF then ON, I can see it. Because straight from boot time, it doesn't seem to work (with HeliPort auto-started). Just a hunch. I can reboot soon, to check again. Could this be the case?

WAIT: In the meantime, after posting my original message, I had disabled the device (named "Wireless" in System Preferences) via Terminal IPv6 could this be it?
networksetup -setv6off Wireless
I am rebooting now...

@ErrorErrorError
Copy link
Collaborator

ErrorErrorError commented Jul 18, 2020

I think that after turning the Wireless controller OFF then ON, I can see it. Because straight from boot time, it doesn't seem to work (with HeliPort auto-started). Just a hunch. I can reboot soon, to check again. Could this be the case?

It returns unknown because the primary interface was not en1, instead it was en0, as from the first time you ran show State:/Network/Global/IPv4 it showed en0 however HeliPort expected en1.

Had to disable en0 first (the Ethernet controller) and repeated the command once WLAN en1 had connected to my router:

This is what fixed your issue since itlwm interface is under en1 and for some reason en0 was the primary connected interface.

@mackonsti
Copy link
Author

mackonsti commented Jul 18, 2020

OK so after rebooting and with en0 pre-disabled, I do get Router now displayed, with IPv6 disabled too:

Router

Please, a kind request:

a) Write on the main page that users are advised to disable IPv6 via Terminal (as System Preferences drop-down list doesn't contain OFF anymore by default)

b) Change the text label "Address" to "MAC Address" on your menu list, just as it's shown in System Preferences -> Network -> Device properties. "Address" prompts to IP, without the word "MAC" (although a n00b may not distinguish IP and xx:xx:xx:xx LOL)

Not sure if this is solved now? Have you guys been able to run only IPv6 with this driver?

@ErrorErrorError
Copy link
Collaborator

ErrorErrorError commented Jul 18, 2020

a) Write on the main page that users are advised to disable IPv6 via Terminal (as System Preferences drop-down list doesn't contain OFF anymore by default)

Why should they disable IPv6? It's not an issue with IPv6. It's an issue with the primary interface was connected to en0 and not en1. I could remove the checking if the primary interface returns en1, but I am not sure if that is the best way to do it since I also have to consider VPN now.

b) Change the text label "Address" to "MAC Address" on your menu list, just as it's shown in System Preferences -> Network -> Device properties. "Address" prompts to IP, without the word "MAC" (although a n00b may not distinguish IP and xx:xx:xx:xx LOL)

That is a question for @williambj1 since Apple does not do that on their Wi-Fi interface.

@mackonsti
Copy link
Author

mackonsti commented Jul 18, 2020

OK sure, sorry, I thought disabling IPv6 was the culprit here. Let me re-enable and reboot again a couple of times and report back. But as en1 does get a Router, even with en0 active, should we not get it displayed in HeliPort?

As for the "Address" word, fine by me. Who am I to argue with Apple's stylistic choices :-D

@ErrorErrorError
Copy link
Collaborator

OK sure, sorry, I thought disabling IPv6 was the culprit here. Let me re-enable and reboot again a couple of times and report back. But as en1 does get a Router, even with en0 active, should we not get it displayed in HeliPort?

No worries I see why you say that lol. And technically yes you do get your router IP address, however en0 is not from itlwm, as it shows the itlwm interface name on top of HeliPort, which it why it fails the condition and returns Unknown in HeliPort. Right now I am checking to see if I can just get the router ip for a specific interface regardless if it's primary or not.

@mackonsti
Copy link
Author

mackonsti commented Jul 18, 2020

Right now I am checking to see if I can just get the router ip for a specific interface regardless if it's primary or not.

Not a bad idea! Hope you come up with something neat and clever!

So I rebooted with en0 disabled and then rebooted as enabled, and despite some system freezing and me being forced to turn off then on again the itlwm driver (when being the only network active device in Mojave) it seems that if en0 is assigned to active Ethernet and itlwm as en1 then HeliPort does indeed get Router=Unknown. I have re-enabled IPv6 for all devices (LAN/WLAN) by the way...

However, I found a couple of other issues, not sure if you want me to create tickets, so I take the opportunity to ask you:

a) If you turn OFF Wi-Fi via HeliPort and back ON, there's no indicator (like that rotating icon, perhaps next to Turn WiFi On label) to indicate you that a scan is being done; the drop-down list is empty. It takes 5 seconds to show nearby SSIDs. Expected behaviour, but the macOS rotating icon would be welcome.

Activity

b) If the itlmw.kext driver's Info.plist contains a valid SSID like the one I insert (due to custom editing it and entering my SSID/password) it seems that this may confuse HeliPort and won't load the last-saved SSID. For example, in Info.plist I set WiFi_1 as my 2.4GHz SSID; but with HeliPort I choose each time (manually) the 5GHz SSID.

Should I delete all <key>WiFiConfig</key> dictionary entries in the kext i.e. WiFi_1 to WiFi_4 keys? Is this expected behaviour of HeliPort? If I don't auto-run-on-login HeliPort and I let the system boot OK, thus having initialised the kext, and then I manually run HeliPort, I do get the last-used SSID to be connected...
Connected
c) If I set itlwm to OFF via HeliPort, and I reboot, it seems that this "OFF" state is not respected without having HeliPort being executed/run; it seems HeliPort-dependent i.e. it doesn't set the device to "inactive" same as in System Preferences. This is expected behaviour?

Thank you! (sorry.... part of my job is IT specs validation at work :-D )

@ErrorErrorError
Copy link
Collaborator

However, I found a couple of other issues, not sure if you want me to create tickets, so I take the opportunity to ask you:

If they are other issues that have not been created I would recommend creating an issue so it can be tracked easier. If it's a feature request, like scanning for networks, pls mark it as feature request or it's corresponding issue,bug, feature request etc...

So I rebooted with en0 disabled and then rebooted as enabled, and despite some system freezing and me being forced to turn off then on again the itlwm driver (when being the only network active device in Mojave) it seems that if en0 is assigned to active Ethernet and itlwm as en1 then HeliPort does indeed get Router=Unknown. I have re-enabled IPv6 for all devices (LAN/WLAN) by the way...

Does en0 have a Network connection and is it being used instead of the Wireless itlwm?

@mackonsti
Copy link
Author

I will create the other tickets, thanks. Of course I will discriminate between request and bug.

Does en0 have a Network connection and is it being used instead of the Wireless itlwm?

Yes it's cable Ethernet plugged in and using IntelMausi.kext by acidanthera.

@williambj1
Copy link
Collaborator

williambj1 commented Jul 19, 2020

That's actually quite odd since we get BSD name directly from itlwm's API &drv_info.bsd_name.0

CC @zxystd

@ErrorErrorError
Copy link
Collaborator

ErrorErrorError commented Jul 19, 2020

That's actually quite odd since we get BSD name directly from itlwm's API &drv_info.bsd_name.0

I mean I don't think it's an issue with itlwm or bsd, I just think that the priority of his system is not on the Wireless, but instead on the ethernet interface. You can have two, or more active network interfaces but only one of them is going to be used, and that is the one who is the one that should prioritize.

The only way I can get the router IP is from the network interface that has the priority since that is where the system is getting the connection from.

Edit: I mean yeah sure I can remove the precondition of BSD however that will mean even if the wifi is not the one that is being used as primary it will still get the router address but from the primary.

guard let interface = dictionary?[kSCDynamicStorePropNetPrimaryInterface] as? String, interface == bsd else {

@williambj1 williambj1 added bug Something isn't working enhancement New feature or request labels Jul 19, 2020
@williambj1 williambj1 added this to Needs triage in Bugs via automation Jul 19, 2020
@williambj1 williambj1 moved this from Needs triage to Low priority in Bugs Jul 19, 2020
@williambj1 williambj1 added this to the v1.0.1 milestone Jul 19, 2020
@mackonsti
Copy link
Author

mackonsti commented Jul 19, 2020

Yes @ErrorErrorError you are correct, my "service order" (to talk Apple) was Ethernet first:

Service Order

I wasn't aware that two or more active network devices (and with IP, I must stress) despite being both active, only the first would be used. I was under the impression there was some mild load balancing LOL. Merci

@Goshin
Copy link
Collaborator

Goshin commented Jul 19, 2020

@ErrorErrorError seems it only returns the primary network. A workaround I can think of is to parse the routing table.

An example: to get the gateway addr of en1

netstat -rn | egrep -o "default.*en1" | egrep -o "\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}"   # ipv4

Bugs automation moved this from Low priority to Closed Jul 21, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working enhancement New feature or request
Projects
Bugs
  
Closed
Development

Successfully merging a pull request may close this issue.

4 participants