2

I am working on an old code that used to connect different IPv6 devices over a different kind of network (a powe line netwrok, PLC, which is quite similar to 802.15.4). To do that, it created Linux tun/tap interfaces on each device (Tun actually, not the Tap) with C code, which can receive egress packets from tun and deliver them to the PLC and on the other direction it can read ingress packets from PLC and inject into the tun interface.

The system works basically fine, but only I found the NDP function seems not working correctly. Firstly I noticed, with two such devices, I cannot ping each other by their IPv6 link local address (fe80::.../10). I then used tcpdump to monitor the tun traffics and found there is no Neighbor Solicitation/Advertisement message at all. Another strange thing I found is that, there is Route Advertisement sent out from one device of the network (the master PLC device which is so-call coordinator node), but not from any other device in the network.

I want to understand what's the correct behavior I should expect from such kind of network according to IPv6 NDP and how to make it happen.

Will appreciate if someone give me some idea.

-woody

Improve this question
2
  • Are the devices doing 6LoWPAN over Bluetooth? You could just stick a Bluetooth adapter in your Linux machine and talk directly.
    – Michael Hampton
    Jan 20, 2019 at 15:38
  • Michael, it's 6LoWPAN over 802.15.4.
    – Woody Wu
    Jan 21, 2019 at 1:55

1 Answer 1

Reset to default
2

Expected behavior is that NDP is used on TAP interfaces but not on TUN interfaces.

TAP emulates Ethernet, so the kernel will deliver Ethernet frames to your code and expect Ethernet frames from your code. As such it has to first do NDP to know which destination MAC address to use for the IP packets it hands over to your code.

TUN on the other hand does IP without an Ethernet layer. Your code will receive IP packets with no additional headers and it will expect to receive IP packets from your code. Optionally it can be configured to have a small header in front of the IP packet to distinguish IPv4 and IPv6 packets, you can however also use the IP version field to distinguish (unless you are using a very outdated kernel version).

I would expect link-local addresses to work on both kinds of interfaces. As with other addresses NDP will be used on TAP but not on TUN interfaces.

Improve this answer
15
  • I wonder how similar to IEEE 802.15.4 it is because that is nothing like ethernet frames.
    – Ron Maupin
    Jan 20, 2019 at 14:57
  • @RonMaupin TAP is intended to be pretty much exactly like Ethernet. It's similar enough that bridging between TAP and physical Ethernet should work. You could use the TAP interface to implement an Ethernet VPN and on each end bridge it to a physical interface such that you could make a single Ethernet segment span different locations far apart. And to the rest of the network the only giveaway that it isn't a direct connection is the higher latency. TUN is nothing like Ethernet. It is either plain IP packets or IP packets with an extra 4 byte header consisting of flags and a protocol field.
    – kasperd
    Jan 20, 2019 at 15:06
  • I understand, but I'm wondering about using a protocol so very different from ethernet with an ethernet-type interface.
    – Ron Maupin
    Jan 20, 2019 at 15:09
  • Using TAP was really something I guessed should be a correct solution in my mind before I asked question. Now your answer seems like it got confirmed. But anyway, the program had already written with TUN not TAP. Currently, I can assign link local address to the TUN interfaces, and if I manually add router entries the TUN interfaces indeed can ping each other (without seeing any neighbor solicitation or neighbor advertisement messages exchanged), is this what you mean 'link-local addresses work on both kinds of interfaces'?
    – Woody Wu
    Jan 20, 2019 at 15:52
  • I in further has a question about using of the TAP, I think if I use it, the purpose in my application is just to trigger the kernel to send out neighbor solicitation and advertisement, right? Because anyway after my program get the Ethernet frame inside from the TUN, it still have to get rid of the Ethernet header because the underlying network is not Ethernet at all. Be more precise, the underlying network is a G3-PLC network which is defined in G.9903, which used a lot of IEEE 802.15.4 frames and protocols and also defined a adapter layer connecting IPv6 and IEEE 802.15.4.
    – Woody Wu
    Jan 20, 2019 at 15:53

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .