• State TI Thinks Resolved
  • Locked Locked
  • Replies 8 replies
  • Answers 3 answers
  • Subscribers 41 subscribers
  • Views 797 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Linux/WL1835MOD: AP mode: inbound IPv6 traffic not received

James Betker
Prodigy 50 points
Part Number: WL1835MOD

Tool/software: Linux

The product I am working on has a WiLink chip which is configured in access point mode. This is normally done via Connman. Currently, this works great for all IPv4 traffic. However, a use case has recently come up that will require us to support clients which will communicate via IPv6. I have determined that, for some reason, IPv6 traffic over a WiFi AP managed by the WiLink chip does not work.

Here is how I've determined this:

  1. Enable AP mode on product.
  2. Give the product an IPv6 address:
    ifconfig wlan0 add 2001:0db8:0:f101::1/64
  3. Connect a Linux laptop to the product's WiFi.
  4. Give the Linux laptop an IPv6 address:
    ifconfig wlan0 add 2001:0db8:0:f101::10/64
  5. Connect a second Linux laptop to the product's WiFi and configure as so:
    ifconfig wlan0 add 2001:0db8:0:f101::11/64
  6. Attempt to ping second laptop from first:
    ping6 2001:0db8:0:f101::11 (optionally can add on interface on the end of the IPv6 address - this does not affect outcome)
    This does not work.
  7. Ping either laptop from the product:
    ping6 2001:0db8:0:f101::10
    This does work.

Through some additional experimentation, I've determined that the limitation seems to be that the product running the AP can send IPv6 traffic to any connected client, but cannot receive traffic back from those clients nor can the clients communicate with each other.

IPv6 support is baked into the kernel. Furthermore, IPv6 traffic does work on other network interfaces for this product - particularly in the case where the product hosts a virtual network interface over USB (NCM). We also have a different product that has a very similar configuration and a different wireless chip which does not exhibit this issue.

Are there any limitations to IPv6 support when in AP mode for the WiLink chips? If not - are there any configuration changes I can make to hopefully alleviate this problem?

Thanks,

James Betker

  • 0
    TI__Mastermind 20285 points
    Hi James,

    I am pretty sure it is related to hostap etc. configuration.
    Not something specific to wl18xx.

    Have not tried it myself but it seems similar to this issue, right?:
    bugzilla.redhat.com/show_bug.cgi

    BR,
    Eyal
  • 0 in reply to Eyal Reizer
    Prodigy 50 points

    Hi Eyal,
    Thanks for the reply. I generally agree with you that this seems like a upper-layer software issue. The thing that is tipping me towards it being an issue with the chipset or WiLink drivers is the fact that we have another product which is built from a near-identical Yocto root and with very similar configuration and services installed --- and this product does not exhibit the issues described (and does not use WiLink).

    I do not have access to a WiLink reference board. Is there any chance someone else on here can give this a quick test on a reference board using hostapd? The steps to reproduce it are pretty simple as long as you have two WiFi/IPv6-enabled devices that can ping each other. This could help me clear up if this issue is relegated to our distro or the fact that we are using ConnMan to launch the AP.

  • 0 in reply to James Betker
    Prodigy 50 points
    Sorry - to be clear - I read the thread you linked and it doesn't seem to offer a solution to the problem other than some suggestions which multiple people say does not fix the issue. Also, our soft AP does get an IPv6 link local address after it goes into tether mode. The issue is that inter-device traffic itself is blocked.
  • 0 in reply to James Betker
    TI__Mastermind 20285 points
    Hi James,

    It might be a stupid question but on the same setup, is everything working ok if you use IPv4 addresses?

    BR,
    Eyal
  • 0 in reply to Eyal Reizer
    TI__Mastermind 20285 points

    Hi James,

    I have just tested it on an am335x BBB and I see no issues.

    See below.

    My AP is set on wlan1, address 2001:db8:0:f101::1

    Laptop1: 2001:db8:0:f101::10

    Laptop2: 2001:db8:0:f101::12

    Below is ping from the am335x board to the two Laptops.

    Ping between the two Laptops is also working ok.

    root@am335x-evm:/usr/share/wl18xx# ifconfig
    eth0 Link encap:Ethernet HWaddr 84:EB:18:9C:DD:98
    UP BROADCAST MULTICAST MTU:1500 Metric:1
    RX packets:0 errors:0 dropped:0 overruns:0 frame:0
    TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
    collisions:0 txqueuelen:1000
    RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
    Interrupt:175

    lo Link encap:Local Loopback
    inet addr:127.0.0.1 Mask:255.0.0.0
    inet6 addr: ::1%763860/128 Scope:Host
    UP LOOPBACK RUNNING MTU:65536 Metric:1
    RX packets:16 errors:0 dropped:0 overruns:0 frame:0
    TX packets:16 errors:0 dropped:0 overruns:0 carrier:0
    collisions:0 txqueuelen:1
    RX bytes:1568 (1.5 KiB) TX bytes:1568 (1.5 KiB)

    usb0 Link encap:Ethernet HWaddr B6:3D:6D:CB:B6:40
    UP BROADCAST MULTICAST MTU:1500 Metric:1
    RX packets:0 errors:0 dropped:0 overruns:0 frame:0
    TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
    collisions:0 txqueuelen:1000
    RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)

    wlan1 Link encap:Ethernet HWaddr 54:4A:16:13:12:B8
    inet addr:192.168.43.1 Bcast:192.168.43.255 Mask:255.255.255.0
    inet6 addr: 2001:db8:0:f101::1%763860/64 Scope:Global
    inet6 addr: fe80::564a:16ff:fe13:12b8%763860/64 Scope:Link
    UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
    RX packets:4733 errors:0 dropped:3 overruns:0 frame:0
    TX packets:1071 errors:0 dropped:0 overruns:0 carrier:0
    collisions:0 txqueuelen:1000
    RX bytes:401714 (392.2 KiB) TX bytes:160961 (157.1 KiB)

    root@am335x-evm:/usr/share/wl18xx#

    root@am335x-evm:/usr/share/wl18xx#

    root@am335x-evm:/usr/share/wl18xx#
    root@am335x-evm:/usr/share/wl18xx# ping6 2001:0db8:0:f101::10
    PING 2001:0db8:0:f101::10 (2001:db8:0:f101::10): 56 data bytes
    64 bytes from 2001:db8:0:f101::10: seq=0 ttl=64 time=3.629 ms
    64 bytes from 2001:db8:0:f101::10: seq=1 ttl=64 time=2.943 ms
    64 bytes from 2001:db8:0:f101::10: seq=2 ttl=64 time=3.086 ms
    64 bytes from 2001:db8:0:f101::10: seq=3 ttl=64 time=2.988 ms
    ^C
    --- 2001:0db8:0:f101::10 ping statistics ---
    4 packets transmitted, 4 packets received, 0% packet loss
    round-trip min/avg/max = 2.943/3.161/3.629 ms
    root@am335x-evm:/usr/share/wl18xx# ping6 2001:0db8:0:f101::12
    PING 2001:0db8:0:f101::12 (2001:db8:0:f101::12): 56 data bytes
    64 bytes from 2001:db8:0:f101::12: seq=0 ttl=64 time=118.203 ms
    64 bytes from 2001:db8:0:f101::12: seq=1 ttl=64 time=3.003 ms
    64 bytes from 2001:db8:0:f101::12: seq=2 ttl=64 time=10.228 ms
    64 bytes from 2001:db8:0:f101::12: seq=3 ttl=64 time=3.026 ms
    64 bytes from 2001:db8:0:f101::12: seq=4 ttl=64 time=2.987 ms
    ^C
    --- 2001:0db8:0:f101::12 ping statistics ---
    5 packets transmitted, 5 packets received, 0% packet loss
    round-trip min/avg/max = 2.987/27.489/118.203 ms

    Best Regards,

    Eyal

  • 0 in reply to Eyal Reizer
    Prodigy 50 points

    Hi Eyal,

    I've identified the cause behind the problem I was seeing. It is the same problem that Jimmy Perchet provided a solution for a couple of years ago. When using mainline kernel TI wilink drivers (as we are), multicast packets of all forms are filtered out by the wilink drivers, which causes IPv6 (which requires multicast to work) between network nodes to fail. Making the changes Jimmy suggested fixes our issue. I'm not sure why you weren't seeing this problem but I appreciate your help. Hopefully this thread will help others who see this problem out, at least. Here is the thread with Jimmy's patch:

  • 0 in reply to Eyal Reizer
    Prodigy 50 points
    Hi Eyal,
    I spoke with an integration engineer. He wanted to ask me if you knew of any particular patch upstream of what is committed to the Kernel mainline which could have fixed the issue I described in the last post. If not, could you tell me what upstream kernel you are using on the am335x BBB you tested this on so we can try to trace the solution implemented by TI?

    For reference, we are using Kernel version 4.9 so we are interested in any changes made upstream of that.

    Thanks again,
    James
  • 0 in reply to James Betker
    TI__Mastermind 20285 points

    Hi James,

    This patch is part of our official release (R8.7_SP3):

    It has also been already accepted upstream:

    patchwork.kernel.org/.../

    Please check that it is part of your kernel, or not...

    Seems like it had hit mainline only in v4.11 so you may not have it in your kernel and you would need to pull it in.



    BR,
    Eyal