NFD

I think we should simply remove that assertion. We already have a BPF socket filter in place and we should trust it, no point in reimplementing the ethertype parsing logic (which is non-trivial in the presence of nested VLAN tags).

Davide Pesavento wrote:
I think we should simply remove that assertion. We already have a BPF socket filter in place and we should trust it, no point in reimplementing the ethertype parsing logic (which is non-trivial in the presence of nested VLAN tags).

I agree.

#3344 note-16 says NFD should only accept untagged packets. This Bug occurs because BPF program is incorrect that it accepts tagged packets into the EthernetTransport. note-5 solution is wrong. Instead, BPF program should be adjusted.

Junxiao Shi wrote:

#3344 note-16 says NFD should only accept untagged packets. This Bug occurs because BFD program is incorrect that it accepts tagged packets into the EthernetTransport. note-5 solution is wrong. Instead, BFD program should be adjusted.

note-5 predates my "verdict" in #3344. Changing the BPF program is exactly what I said in note-5 so I suppose we agree.

Also, when you say "BFD" I'm assuming you mean "BPF".

I did testing using 2 virtual machines, connected using vde switch (I think it works only on Linux-based Virtualbox host):

vagrant config:

# -*- mode: ruby -*-
# vi: set ft=ruby :

VAGRANTFILE_API_VERSION = "2"

Vagrant.configure(VAGRANTFILE_API_VERSION) do |config|
  config.vm.box = "ubuntu/trusty64"

  config.vm.provider "virtualbox" do |vb|
    vb.gui = false
    vb.memory = "2048"
    vb.cpus = "1"
  end

  (1..2).each do |i|
    config.vm.define "node-#{i}" do |node|
      node.vm.provision "shell",
        inline: "echo hello from node #{i}"
      node.vm.provider "virtualbox" do |vb|
        vb.customize ["modifyvm", :id, "--nic2", "generic", "--nicgenericdrv2", "VDE"]
        vb.customize ["modifyvm", :id, "--nicproperty2", "network=/tmp/switch1[#{i}]"]
      end
    end
  end
end

On Ubuntu 14.04 there a small hack is needed:

sudo ln -s /usr/lib/libvdeplug.so.2 /usr/lib/libvdeplug.so

Install and run vde switch on host

sudo apt-get install vde2
vde_switch -s /tmp/switch1

vlan/create 10
vlan/addport 10 1
vlan/addport 10 2

With this setup, I'm confirming the original report and conclusion of #3348: packet is received in both tagged (on eth1) and untagged (on eth1.10) forms. In release mode, I'm seeing a failure to parse, in debug mode, there is an assertion.

Release mode:

1450682025.026806 TRACE: [EthernetTransport] [id=257,local=dev://eth1,remote=ether://[01:00:5e:00:17:aa]] Received: 12 bytes from 08:00:27:b1:1b:c8
1450682025.027094 WARNING: [GenericLinkService] [id=257,local=dev://eth1,remote=ether://[01:00:5e:00:17:aa]] packet parse error (unrecognized TLV-TYPE 0): DROP
1450682025.027158 TRACE: [EthernetTransport] [id=258,local=dev://eth1.10,remote=ether://[01:00:5e:00:17:aa]] Received: 30 bytes from 08:00:27:b1:1b:c8

Debug mode:

***** Internal Program Error - assertion (ntohs(eh->ether_type) == ethernet::ETHERTYPE_NDN) failed in void nfd::face::EthernetTransport::processIncomingPacket(const pcap_pkthdr*, const uint8_t*):
../daemon/face/ethernet-transport.cpp(347): Received frame with unrecognized ethertype
Aborted (core dumped)

After applying patch from http://gerrit.named-data.net/#/c/2607/3 the problem persists!

root@vagrant-ubuntu-trusty-64:~/NFD# ./build/bin/nfd
1450683041.939100 INFO: [EthernetTransport] [id=0,local=dev://eth1,remote=ether://[01:00:5e:00:17:aa]] Creating transport
1450683041.942406 DEBUG: [EthernetTransport] [id=0,local=dev://eth1,remote=ether://[01:00:5e:00:17:aa]] Interface MTU is 1500
1450683041.945520 INFO: [EthernetTransport] [id=0,local=dev://eth1.10,remote=ether://[01:00:5e:00:17:aa]] Creating transport
1450683041.948372 DEBUG: [EthernetTransport] [id=0,local=dev://eth1.10,remote=ether://[01:00:5e:00:17:aa]] Interface MTU is 1500
1450683041.952410 INFO: [EthernetTransport] [id=0,local=dev://eth0,remote=ether://[01:00:5e:00:17:aa]] Creating transport
1450683041.956304 DEBUG: [EthernetTransport] [id=0,local=dev://eth0,remote=ether://[01:00:5e:00:17:aa]] Interface MTU is 1500
1450683041.970910 WARNING: [EthernetTransport] [id=259,local=dev://eth0,remote=ether://[01:00:5e:00:17:aa]] Read timeout

***** Internal Program Error - assertion (ntohs(eh->ether_type) == ethernet::ETHERTYPE_NDN) failed in void nfd::face::EthernetTransport::processIncomingPacket(const pcap_pkthdr*, const uint8_t*):
../daemon/face/ethernet-transport.cpp(349): Received frame with unrecognized ethertype
Aborted (core dumped)

Something is really fishy with the filter. Here is my attempt to play with tcpdump filters:

root@vagrant-ubuntu-trusty-64:~/NFD# tcpdump -nei eth1 "(ether proto 0x8624) and not vlan"
tcpdump: WARNING: eth1: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes
07:44:33.610003 08:00:27:b1:1b:c8 > 01:00:5e:00:17:aa, ethertype 802.1Q (0x8100), length 64: vlan 10, p 0, ethertype 0x8624,
    0x0000:  051c 0710 0804 7465 7374 0805 6865 6c6c  ......test..hell
    0x0010:  6f08 0133 0902 1200 0a04 a77b 7b13 0000  o..3.......{{...
    0x0020:  0000 0000 0000 0000 0000 0000 0000       ..............

This seem to be contradictory to what I'm requesting... I tried to remove eth1.10 interface and remove 8021q module. No change. Somehow, this VLAN-tagged packet is not treated as a VLAN tagged packet... Filter, for some reason, applies to the inner packet, not to the outer.

Can it be related to https://bugzilla.redhat.com/show_bug.cgi?id=498981#c4 ?

Can you attach a pcap trace of the packets that trigger this behavior?

Davide Pesavento wrote:
Can you attach a pcap trace of the packets that trigger this behavior?

Interesting, I don't see the behavior Alex described.

Publisher machine:

faceid=261 remote=ether://[01:00:5e:00:17:aa] local=dev://enp68s0f1.802 counters={in={4i 0d 96B} out={0i 2d 704B}} non-local permanent multi-access
/test nexthops={faceid=261 (cost=0)}
/test route={faceid=261 (origin=255 cost=0 ChildInherit)}

nfdc register /test 261

$ echo "hello" | ndnputchunks3 /test

Consumer machine:

faceid=262 remote=ether://[01:00:5e:00:17:aa] local=dev://enp68s0f0.802 counters={in={0i 2d 704B} out={4i 0d 96B}} non-local permanent multi-access
/test nexthops={faceid=262 (cost=0)}
/test route={faceid=262 (origin=255 cost=0 ChildInherit)}

nfdc register /test 262

[root@atmos-sac NFD]# ndncatchunks3 -o /test
hello

Yeah I suspect a bug in libpcap, only recently fixed. I'm on 1.7.4, Alex is probably on 1.5.3.

Susmit, what version are you using?

Davide Pesavento wrote:

Yeah I suspect a bug in libpcap, only recently fixed. I'm on 1.7.4, Alex is probably on 1.5.3.

Susmit, what version are you using?

That might be true. I am using 1.7.4.

Maybe this is effect of virtualbox emulation (something lacking in emulated driver), but I'm not 100% convinced. Unfortunately, I don't have a real system to try with.

I will repeat experiment with virtualbox'ed Fedora.

I cannot reproduce the problem on Ubuntu 15.10 reading Alex's trace (tcpdump -r eth1.pcap ...), the packet is correctly filtered.

Alex Afanasyev wrote:

I tried to compile the last version of libpcap and tcpdump, but still see the same result.

The bug you referenced in note-11 says that some kernel changes were also required to completely fix it. Maybe your kernel doesn't have those changes.

I noticed that on Ubuntu 14.04 the BPF assembly code generated for both 'ether proto 0x8624' and 'ether proto 0x8624 && not vlan' is exactly the same, while on 15.10 it's different (the '&& not vlan' part adds Linux-specific BPF extensions to the compiled filter).

This probably means that we cannot rely on a BPF filter for this job, instead we have to "manually" discard tagged packets in the transport.

Just checked with Fedora 23 with the same virtualized environment. Everything works as expected:

[root@fedora NFD]# tcpdump -ni enp0s8
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on enp0s8, link-type EN10MB (Ethernet), capture size 262144 bytes
20:34:39.656886 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 08:00:27:34:16:fe, length 300
20:34:40.415807 08:00:27:b1:1b:c8 > 01:00:5e:00:17:aa, ethertype 802.1Q (0x8100), length 64:
    0x0000:  0518 0710 0804 7465 7374 0805 6865 6c6c  ......test..hell
    0x0010:  6f08 0132 0a04 eed8 4064 0000 0000 0000  o..2....@d......
    0x0020:  0000 0000 0000 0000 0000 0000 0000       ..............

[root@fedora NFD]# tcpdump -ni enp0s8 not vlan
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on enp0s8, link-type EN10MB (Ethernet), capture size 262144 bytes

[root@fedora NFD]# tcpdump -ni enp0s8 vlan 10
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on enp0s8, link-type EN10MB (Ethernet), capture size 262144 bytes
20:35:20.119949 08:00:27:b1:1b:c8 > 01:00:5e:00:17:aa, ethertype 802.1Q (0x8100), length 64:
    0x0000:  0518 0710 0804 7465 7374 0805 6865 6c6c  ......test..hell
    0x0010:  6f08 0132 0a04 745c 989d 0000 0000 0000  o..2..t\........
    0x0020:  0000 0000 0000 0000 0000 0000 0000       ..............

As a conclusion. We should proceed with the fix of the tcpdump filter. However, we also need to remove asserts and additional checks in incoming packet processing path. I think just checking for ethernet type would suffice.

Alex Afanasyev wrote:

As a conclusion. We should proceed with the fix of the tcpdump filter. However, we also need to remove asserts and additional checks in incoming packet processing path. I think just checking for ethernet type would suffice.

Agreed.