Apalis TK1 Wi-Fi Backports

I’m trying to get an Intel 7260 PCI-E Wi-Fi card up and running on the Apalis TK1.

Having followed instructions from here:

I’ve managed to get a backports build and have copied them across to the target. I’ve noticed though, that during the compilation, a couple of warnings occur:

depmod: WARNING: /home/kevin/apalis-tk1/build_iwlwifi/lib/modules/3.10.40-g19722d4/updates/net/wireless/cfg80211.ko needs unknown symbol rfkill_unregister

There are several other WARNING messages with other unknown symbol messages.

When my target reboots and I check dmesg, I can see that only the compat module is loaded and searching for the cfg80211 results in the following:

[    7.672868] cfg80211: Unknown symbol rfkill_unregister (err 0)
[    7.679578] cfg80211: Unknown symbol rfkill_blocked (err 0)
[    7.685923] cfg80211: Unknown symbol rfkill_destroy (err 0)
[    7.694389] cfg80211: Unknown symbol rfkill_resume_polling (err 0)
[    7.702858] cfg80211: Unknown symbol rfkill_pause_polling (err 0)
[    7.710083] cfg80211: Unknown symbol rfkill_set_hw_state (err 0)
[    7.717553] cfg80211: Unknown symbol rfkill_alloc (err 0)
[    7.724078] cfg80211: Unknown symbol rfkill_register (err 0)
[    7.736482] cfg80211: Unknown symbol rfkill_set_sw_state (err 0)

Any clues?

Kind regards,
Kevin

Please ignore my question, I have since realised that the RFKILL features needed to be enabled in my Linux kernel. Having enabled them, re-compiled and reloaded the backports, the Wi-Fi now works perfectly.

Ok, so maybe my Wi-Fi isn’t working as I expected. Since posting the above message, I realised that the ethernet was still connected and traffic was being routed via the ethernet interface.

Once the ethernet is unplugged, although Wi-Fi can connect to our company network (using connmanctl), it always receives an IPv6 address yet our network only serves out IPv4 addresses. Because of this, I am unable to successfully ping another address nor am I able to access the web.

Having attempted to disable IPv6 on Wi-Fi using many attempts suggested by several Google searches, the Wi-Fi endpoint is still allocated an IPv6 address.

Is there a more definite way to disable the ability to obtain an IPv6 address in Linux for the TK1?

Thanks

@kwebster83: Do you have any kind of DHCP client active on the WLAN interface? IPv6 protocol specifies several types of addresses including link-local addresses that are assigned automatically to all interfaces (so even if there is nothing assigning them in the network). You can confirm that by checking if that address starts with “fe80:”.

While it is possible to completely disable IPv6, I do not think that’s the right way to solve the problem, because it should work with IPv6 active.

If you are not sure if there is DHCP client active, I would recommend setting IPv4 address manually (using ifconfig wlan0 <addr> netmask <mask> or something like that, you have to know correct address and netmask) for the interface and trying to ping other host on same subnet. If that works, try to set default gateway ( route add default gw <addr> ) and ping 8.8.8.8. If that works as well, set DNS server correctly (put nameserver 8.8.8.8 into /etc/resolv.conf, that should work always) and try accessing something using domain name instead of IP address. If that works, it was only matter of missing configuration, which would be solved by DHCP client, so install and configure one.

EDIT: Or just try to run udhcpc wlan0, maybe the DHCP client is already there and is just does not get started by anything…

@EGM, thanks for your response.

I did happen to notice that the IPv6 address did start with fe80. I guess that means there is a DHCP client running on my platform. The Wi-Fi endpoint appears as wlp1s0. I would rather have an IPv4 address allocated by our DHCP server but I guess temporarily it is possible for me to specify a fixed address.

@kwebster83: No, presence of link-local IPv6 address does not indicate at all that there is running DHCP client. Link-local addresses are part of stateless autoconfiguration mechanism in IPv6 protocol, while DHCPv6 is stateful autoconfiguration (see RFC 2462 if you are curious for details).

@EGM, ok, thank you for the information. I will check the status of the DHCP client first thing in the morning.

@kwebster83: Have you been able to resolve this issue already?

@EGM, yes, I was able to resolve this issue - thank you. I’m now able to obtain a valid IPv4 address and can access the internet, etc, over Wi-Fi.

One thing I’m currently battling with is setting up Samba to access the contents of an SSD. Samba is up and running but when I try to access the share via Windows 7, I’m always prompted for a password even though guest access is enabled and the share is public. This is for another day though