altramayor / xia-for-linux Goto Github PK

Description:

When using the net-echo application with Serval, the client is unable to send packets.

Environment:

xia@xia:~$ uname -r
4.0.0-rc1-xia
xia@xia:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 14.04.3 LTS
Release:    14.04
Codename:   trusty

Last commit: xia: update warnings about changing FIB

VirtualBox version 5.0.14_Ubuntu r10512

Steps to Reproduce Error:

In one terminal, we can see the addresses being used and start the server:

xia@xia:~$ cd net-echo/
xia@xia:~/net-echo$ cat server.txt 
serval-e771ea6f57c2bc9adde62fb0ece2868354b98e9a-0
xia@xia:~/net-echo$ cat client.txt 
serval-e771ea6f57c2bc9adde62fb0ece2868354b98e9b-0
xia@xia:~/net-echo$ ./eserv stream xip server.txt 

On the client (second terminal), we can see the sockets and start the client:

xia@xia:~$ sudo xip serval showsockets service
local serval-e771ea6f57c2bc9adde62fb0ece2868354b98e9a
socket state = LISTEN flags []

xia@xia:~$ cd net-echo/
xia@xia:~/net-echo$ ./ecli stream xip client.txt server.txt 

When the client starts, the server outputs:

---- Connect()

In a third terminal, we can dump the socket information:

xia@xia:~$ sudo xip serval showsockets service
local serval-e771ea6f57c2bc9adde62fb0ece2868354b98e9b
socket state = CONNECTED flags []

local serval-e771ea6f57c2bc9adde62fb0ece2868354b98e9a
socket state = LISTEN flags []

xia@xia:~$ sudo xip serval showsockets flow
local flowid-0b6947ac22fc65cc81a0e283d21d10bca9307c72
peer !serval-e771ea6f57c2bc9adde62fb0ece2868354b98e9b->0***
socket state = CONNECTED flags []

local flowid-0a6947ac22fc65cca85671f4c08c5d264aa89040
peer !serval-e771ea6f57c2bc9adde62fb0ece2868354b98e9a->0***
socket state = CONNECTED flags []

No error messages have been reported by dmesg.

In the client, we can type a message to be echoed and press enter:

xia@xia:~/net-echo$ ./ecli stream xip client.txt server.txt 
hello

No response from the server (not even a '.'). Capturing on all interfaces using tcpdump shows that no packets are sent from the client.

dmesg now reports an error:

[94322.709842] XIP: unreachable destination on direction out, last_node=126, destination_address=`serval-e771ea6f57c2bc9adde62fb0ece2868354b98e9a-0'

We can show the sockets again (the listening socket has been closed):

xia@xia:~$ sudo xip serval showsockets service
local serval-e771ea6f57c2bc9adde62fb0ece2868354b98e9b
socket state = CONNECTED flags []

xia@xia:~$ sudo xip serval showsockets flow
local flowid-0b6947ac22fc65cc81a0e283d21d10bca9307c72
peer !serval-e771ea6f57c2bc9adde62fb0ece2868354b98e9b->0***
socket state = CONNECTED flags []

local flowid-0a6947ac22fc65cca85671f4c08c5d264aa89040
peer serval-e771ea6f57c2bc9adde62fb0ece2868354b98e9a-0
socket state = CONNECTED flags []

We can also dump the DST:

xia@xia:~$ sudo xip dst show
to
0: serval-e771ea6f57c2bc9adde62fb0ece2868354b98e9b
1: nat-0000000000000000000000000000000000000000
2: nat-0000000000000000000000000000000000000000
3: nat-0000000000000000000000000000000000000000
output, key_hash=0x4f061600, chosen_edge=0
passthrough/sink_action=XDA_ERROR/XDA_METHOD_AND_SELECT_EDGE
flags []

to
0: serval-e771ea6f57c2bc9adde62fb0ece2868354b98e9a
1: nat-0000000000000000000000000000000000000000
2: nat-0000000000000000000000000000000000000000
3: nat-0000000000000000000000000000000000000000
output, key_hash=0xc408ca74, chosen_edge=none
passthrough/sink_action=XDA_METHOD/XDA_METHOD
flags []

to
0: flowid-0a6947ac22fc65cca85671f4c08c5d264aa89040
1: nat-0000000000000000000000000000000000000000
2: nat-0000000000000000000000000000000000000000
3: nat-0000000000000000000000000000000000000000
output, key_hash=0x7f6481db, chosen_edge=0
passthrough/sink_action=XDA_ERROR/XDA_METHOD_AND_SELECT_EDGE
flags []

to
0: flowid-0b6947ac22fc65cc81a0e283d21d10bca9307c72
1: nat-0000000000000000000000000000000000000000
2: nat-0000000000000000000000000000000000000000
3: nat-0000000000000000000000000000000000000000
output, key_hash=0x66d506e7, chosen_edge=0
passthrough/sink_action=XDA_ERROR/XDA_METHOD_AND_SELECT_EDGE
flags []

The Ethernet principal is not properly verifying its XIDs that come from userland to its local and main tables.

The Ethernet principal does not check that the interface associated to a local Ethernet XID exists, is up, or has the proper format (e.g. having the correct number of zeros after the Ethernet address). local_newroute() in net/xia/ppal_ether/main.c should do these verifications. Most of the code for this fix can be copied from another function in the same file, namely main_newroute().

Finally, main_newroute() should verify that the Ethernet address part of the Ethernet XID being added is not the Ethernet address of the interface referred in the XID. Putting in simpler language, the neighbor represented by the new XID should not be the host itself because it would mean that the XID is local instead of main. Notice that analogous test is not needed in local_newroute() because one may want to force a neighbor XID to behave as a local XID.

Description:

kernel When trying to use the net-echo application with Serval (streaming echo using XIP), the XIA kernel panics.

How to reproduce:

Setup two XIA-enabled (3.11.0rc7 kernel) hosts connected via Ethernet. Insert the HID and Serval principals into each kernel. Follow the below instructions to setup the net-echo application.

Server side:

• Server HID (example): hid-f4876ba0094167017e175f94392cf5e874caba1f
• net-echo server instance: serval-007f4e38904e83634acc7e1340ef7665e3f1f57a-0

$ ./eserv stream xip server

On client side:

• Client HID (example): hid-21f7cedae9821d0b45d2ce304e48f32fff47d865
• net-echo client instance: serval-007f4e38904e83634acc7e1340ef7665e3f1f57b-0

$ sudo xip serval addroute service  007f4e38904e83634acc7e1340ef7665e3f1f57a \
gw hid-f4876ba0094167017e175f94392cf5e874caba1f
$ ./ecli stream xip client server   # kernel panic in HID module

Additional Information:

• Something bad is happening in the HID module, especially around main_input_output. The bug happens before trying to transmit any data (the panic occurs when the ecli application is started).

Screenshot:

Description:

When using the HID principal to send packets between containers, the code crashes in net/xia/ppal_hid/main.c:main_input_input().

The crash happens because apparently skb->sk is NULL when using containers, so the call to sock_net(skb->sk) passes a null pointer which is then dereferenced.

The line of code is here: https://github.com/AltraMayor/XIA-for-Linux/blob/xia/net/xia/ppal_hid/main.c#L355

This code was recently added as a part of this commit: 1695676

I have not checked whether the other parts of the code in this commit cause a similar crash.

When testing the HID principal by sending packets between two VMs, this crash does not occur.

Environment:

xia@xia:~$ uname -r
4.5.0-rc7-xia
xia@xia:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 14.04.3 LTS
Release:    14.04
Codename:   trusty

Last commit: xia/u4id: remove call to sk_release_kernel

Steps to Reproduce Error:

I was testing the net-eval scripts when I found this bug, the setup for which can be found here: https://github.com/AltraMayor/XIA-for-Linux/wiki/Forwarding-performance-evaluation#Experiment_Scripts

# Obtain net-eval scripts and build.
git clone https://github.com/cjdoucette/net-eval.git
cd net-eval
bash howto
cd exp

# Obtain necessary packages.
sudo apt-get install lxc ruby1.9.1 bridge-utils
sudo gem install netaddr 

# Setup experiments and run them.
sudo ruby1.9.1 ./net-eval-setup.rb 10 60 -xs
sudo ruby1.9.1 ./net-eval-run.rb

Implementation of LPM is not described on https://github.com/AltraMayor/XIA-for-Linux/wiki/4ID-principals
It still shows "Status: not yet implemented".

In xia/net/xia/fib.c the function vmalloc from vmalloc.h is used on line 129, but there is no include statement for vmalloc in the header. This was causing an error while compiling, but by adding #include < linux/vmalloc.h > the issue was solved.

Description:

when kernel compiling, if choose XIA stack not as optional modules (select with [*] rather than ) along with IPv4 stack in kernel configuration, there will jump out a multiple definition error. Otherwise, If selecting XIA stack as optional modules, kernel compiling will success.

How to reproduce:

Following steps in wiki except for selecting XIA stack as default:

1. $ make nconfig
2. Select the XIA stack in configuration

3. $ make prepare
4. $ sed -rie 's/echo "\+"/#echo "\+"/' scripts/setlocalversion
5. $ make-kpkg clean
6. $ CONCURRENCY_LEVEL=`getconf _NPROCESSORS_ONLN` fakeroot \
      make-kpkg --initrd --append-to-version=-xia --revision=05 \
      kernel_image kernel_headers

Snapshot:

Kernel compiling error is caused by multiple definition of `sk_stream_alloc_skb':

As far as I know, we have a lot of solutions to this error, such as modifying Makefile, changing struct name or adding #ifdef to avoid this, but I am not sure which one is optimal. Also, one truth is that we will finally have XIA-only networks without IP stack, so this is not a severe issue.

I've found no math formulae in PhD thesis available in your wiki - have you did any math theory elaboration? Any theorem proving XIA is efficient and complete network stack? ... any network models used?

Hey there,

I noticed the link of the PhD thesis Linux XIA: An Interoperable Meta Network Architecture inside the Wiki is not valid anymore.