Note: the issue was created automatically with bugzilla2github tool

Bugzilla Bug ID: 45

Date: 2015-10-21 09:55:36 +0200
From: Sorin Vultureanu <[email protected]>
To: Bogdan Pricope <[email protected]>

Last updated: 2015-11-26 14:29:08 +0100

Bugzilla Comment ID: 57

Date: 2015-10-21 09:55:36 +0200
From: Sorin Vultureanu <[email protected]>

in ofp_init_global(), ofp_init_local() function calls don't threat error situations.
The return of these functions is always 0 even if inside there is an error.
When one calls these functions the error situation should be handled.

See bug #30 for error types.

Note: the issue was created automatically with bugzilla2github tool

Bugzilla Bug ID: 34

Date: 2015-06-03 09:12:02 +0200
From: Bogdan Pricope <[email protected]>
To: Sorin Vultureanu <[email protected]>
CC: [email protected]

Last updated: 2015-11-30 09:04:21 +0100

Bugzilla Comment ID: 40

Date: 2015-06-03 09:12:02 +0200
From: Bogdan Pricope <[email protected]>

Refactoring from ifup/ifdown pov

Bugzilla Comment ID: 56

Date: 2015-10-21 09:30:13 +0200
From: Sorin Vultureanu <[email protected]>

API to start/stop each interface during run-time.

Miss a 'SP' macro in ofp_init_pre_global function. Not sure master has same issue. :)
Error log like this.
ofp_init.c: In function 'ofp_init_pre_global':
ofp_init.c:116:5: error: 'struct ofp_global_config_mem' has no member named 'nl_thread_is_running'
shm->nl_thread_is_running = 0;

Note: the issue was created automatically with bugzilla2github tool

Bugzilla Bug ID: 40

Date: 2015-06-12 12:45:57 +0200
From: Bogdan Pricope <[email protected]>
To: Sorin Vultureanu <[email protected]>
CC: [email protected]

Last updated: 2015-11-30 09:05:59 +0100

Bugzilla Comment ID: 48

Date: 2015-06-12 12:45:57 +0200
From: Bogdan Pricope <[email protected]>

For TCP, connect ends after SYN is sent.
It should end after the handshake is complete.

Note: the issue was created automatically with bugzilla2github tool

Bugzilla Bug ID: 44

Date: 2015-07-27 12:57:25 +0200
From: Bogdan Pricope <[email protected]>
To: Sorin Vultureanu <[email protected]>

Last updated: 2015-07-27 12:57:25 +0200

Bugzilla Comment ID: 55

Date: 2015-07-27 12:57:25 +0200
From: Bogdan Pricope <[email protected]>

Note: the issue was created automatically with bugzilla2github tool

Bugzilla Bug ID: 26

Date: 2015-06-03 09:01:07 +0200
From: Bogdan Pricope <[email protected]>
To: Sorin Vultureanu <[email protected]>

Last updated: 2015-10-22 14:24:09 +0200

Bugzilla Comment ID: 31

Date: 2015-06-03 09:01:07 +0200
From: Bogdan Pricope <[email protected]>

Move some logging and debug features to a debug only configuration

Bugzilla Comment ID: 71

Date: 2015-10-21 12:04:29 +0200
From: Sorin Vultureanu <[email protected]>

Can this be closed?

Note: the issue was created automatically with bugzilla2github tool

Bugzilla Bug ID: 46

Date: 2015-10-21 09:57:15 +0200
From: Sorin Vultureanu <[email protected]>
To: Sorin Vultureanu <[email protected]>
CC: [email protected]

Last updated: 2015-11-24 12:08:05 +0100

Bugzilla Comment ID: 58

Date: 2015-10-21 09:57:15 +0200
From: Sorin Vultureanu <[email protected]>

Create a new issue for each situation identified by review.

Bugzilla Comment ID: 142

Date: 2015-11-24 12:08:05 +0100
From: José Pekkarinen <[email protected]>

Uninitialized variables are identified by the compiler, during the development process. No need for a ticket like this.

Note: the issue was created automatically with bugzilla2github tool

Bugzilla Bug ID: 41

Date: 2015-06-16 09:30:46 +0200
From: Bogdan Pricope <[email protected]>
To: Sorin Vultureanu <[email protected]>

Last updated: 2015-06-16 09:30:46 +0200

Bugzilla Comment ID: 49

Date: 2015-06-16 09:30:46 +0200
From: Bogdan Pricope <[email protected]>

As far as I can tell, odpfp_select() socket API has the following limitations:

• only "readfds" set is processed, while "writefds" and "exceptfds" are ignored
• "timeout" cannot be NULL and will block execution until completion and not until a socket "become ready"
• a socket cannot be part of more than one set

All those limitations need to be addressed.

With OFP being used for basic routing pings WAN to LAN display as show below:

root@MCDEBIAN-HOME:~# ping 192.168.1.2
PING 192.168.1.2 (192.168.1.2) 56(84) bytes of data.
64 bytes from 192.168.1.2: icmp_seq=1 ttl=127 time=0.780 ms
64 bytes from 192.168.1.2: icmp_seq=1 ttl=127 time=0.805 ms (DUP!)
64 bytes from 192.168.1.2: icmp_seq=1 ttl=127 time=1.53 ms (DUP!)
64 bytes from 192.168.1.2: icmp_seq=1 ttl=127 time=1.61 ms (DUP!)
64 bytes from 192.168.1.2: icmp_seq=2 ttl=127 time=0.793 ms
64 bytes from 192.168.1.2: icmp_seq=2 ttl=127 time=0.809 ms (DUP!)
64 bytes from 192.168.1.2: icmp_seq=2 ttl=127 time=2.93 ms (DUP!)
64 bytes from 192.168.1.2: icmp_seq=2 ttl=127 time=4.69 ms (DUP!)
64 bytes from 192.168.1.2: icmp_seq=3 ttl=127 time=0.860 ms
64 bytes from 192.168.1.2: icmp_seq=3 ttl=127 time=0.875 ms (DUP!)
64 bytes from 192.168.1.2: icmp_seq=3 ttl=127 time=0.985 ms (DUP!)
64 bytes from 192.168.1.2: icmp_seq=3 ttl=127 time=0.997 ms (DUP!)
64 bytes from 192.168.1.2: icmp_seq=4 ttl=127 time=0.736 ms
64 bytes from 192.168.1.2: icmp_seq=4 ttl=127 time=0.854 ms (DUP!)
64 bytes from 192.168.1.2: icmp_seq=4 ttl=127 time=1.86 ms (DUP!)
64 bytes from 192.168.1.2: icmp_seq=4 ttl=127 time=1.87 ms (DUP!)

It think this is causing a routing performance problem as the below iperfs show:

C:\Users\chad\Downloads\iperf-3.0.11-win32>iperf3 -c 192.168.200.1
Connecting to host 192.168.200.1, port 5201
[  4] local 192.168.1.2 port 49251 connected to 192.168.200.1 port 5201
[ ID] Interval           Transfer     Bandwidth
[  4]   0.00-1.00   sec  4.25 MBytes  35.6 Mbits/sec
[  4]   1.00-2.00   sec  3.19 MBytes  26.7 Mbits/sec
[  4]   2.00-3.00   sec  3.56 MBytes  29.9 Mbits/sec
[  4]   3.00-4.00   sec  3.25 MBytes  27.3 Mbits/sec
[  4]   4.00-5.00   sec  3.69 MBytes  30.9 Mbits/sec
[  4]   5.00-6.00   sec  3.37 MBytes  28.3 Mbits/sec
[  4]   6.00-7.00   sec  3.50 MBytes  29.4 Mbits/sec
[  4]   7.00-8.00   sec  3.81 MBytes  32.0 Mbits/sec
[  4]   8.00-9.00   sec  3.62 MBytes  30.4 Mbits/sec
[  4]   9.00-10.00  sec  3.25 MBytes  27.3 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth
[  4]   0.00-10.00  sec  35.5 MBytes  29.8 Mbits/sec                  sender
[  4]   0.00-10.00  sec  35.4 MBytes  29.7 Mbits/sec                  receiver

iperf Done.

C:\Users\chad\Downloads\iperf-3.0.11-win32>iperf3 -c 192.168.200.1 -R
Connecting to host 192.168.200.1, port 5201
Reverse mode, remote host 192.168.200.1 is sending
[  4] local 192.168.1.2 port 49253 connected to 192.168.200.1 port 5201
[ ID] Interval           Transfer     Bandwidth
[  4]   0.00-1.00   sec  4.34 MBytes  36.4 Mbits/sec
[  4]   1.00-2.00   sec  4.21 MBytes  35.3 Mbits/sec
[  4]   2.00-3.00   sec  4.25 MBytes  35.7 Mbits/sec
[  4]   3.00-4.00   sec  4.41 MBytes  37.0 Mbits/sec
[  4]   4.00-5.00   sec  3.93 MBytes  33.0 Mbits/sec
[  4]   5.00-6.00   sec  4.21 MBytes  35.3 Mbits/sec
[  4]   6.00-7.00   sec  4.35 MBytes  36.5 Mbits/sec
[  4]   7.00-8.00   sec  4.35 MBytes  36.5 Mbits/sec
[  4]   8.00-9.00   sec  4.27 MBytes  35.8 Mbits/sec
[  4]   9.00-10.00  sec  3.98 MBytes  33.4 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-10.00  sec  42.5 MBytes  35.6 Mbits/sec  127             sender
[  4]   0.00-10.00  sec  42.4 MBytes  35.6 Mbits/sec                  receiver

iperf Done.

Without OFP the same iperf would show 400-500mb/s

root@MCDEBIAN:~# ifconfig
eth0      Link encap:Ethernet  HWaddr e2:0a:32:f0:bb:9f
          inet6 addr: fe80::e00a:32ff:fef0:bb9f/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:64451 errors:0 dropped:0 overruns:0 frame:0
          TX packets:124588 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:49272423 (46.9 MiB)  TX bytes:62691995 (59.7 MiB)
          Interrupt:28

eth1      Link encap:Ethernet  HWaddr da:b6:90:aa:e3:89
          inet6 addr: fe80::d8b6:90ff:feaa:e389/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:68364 errors:0 dropped:0 overruns:0 frame:0
          TX packets:109126 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:46395828 (44.2 MiB)  TX bytes:60418100 (57.6 MiB)
          Interrupt:27

fp0       Link encap:Ethernet  HWaddr da:b6:90:aa:e3:89
          inet addr:192.168.1.1  Bcast:192.168.1.255  Mask:255.255.255.0
          inet6 addr: fe80::d8b6:90ff:feaa:e389/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:4056 errors:0 dropped:281 overruns:0 frame:0
          TX packets:64289 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:582280 (568.6 KiB)  TX bytes:49203085 (46.9 MiB)

fp1       Link encap:Ethernet  HWaddr e2:0a:32:f0:bb:9f
          inet addr:192.168.200.161  Bcast:192.168.200.255  Mask:255.255.255.0
          inet6 addr: fe80::e00a:32ff:fef0:bb9f/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:439 errors:0 dropped:0 overruns:0 frame:0
          TX packets:71812 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:36754 (35.8 KiB)  TX bytes:46881725 (44.7 MiB)

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

wlan0     Link encap:Ethernet  HWaddr 00:25:9c:13:07:31
          inet6 addr: fe80::225:9cff:fe13:731/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:7 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:864 (864.0 B)

wlan1     Link encap:Ethernet  HWaddr 00:25:9c:13:07:30
          inet6 addr: fe80::225:9cff:fe13:730/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:7 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:864 (864.0 B)

Note: the issue was created automatically with bugzilla2github tool

Bugzilla Bug ID: 25

Date: 2015-06-03 08:59:04 +0200
From: Bogdan Pricope <[email protected]>
To: Sorin Vultureanu <[email protected]>

Last updated: 2015-06-03 08:59:04 +0200

Bugzilla Comment ID: 30

Date: 2015-06-03 08:59:04 +0200
From: Bogdan Pricope <[email protected]>

Support/feature documentation

Note:
Can be a root textfile from the start

Assigned: Ulf

Is transparent proxy possible under OFP ?

slow path transparent proxy can be achieved with some iptables PREROUTING, TPROXY rules and a matching IP_TRANSPARENT socket option.

slow path code examples:
tproxy_example
yet to be released nginx 1.11

Note: the issue was created automatically with bugzilla2github tool

Bugzilla Bug ID: 38

Date: 2015-06-03 09:15:29 +0200
From: Bogdan Pricope <[email protected]>
To: Sorin Vultureanu <[email protected]>
CC: [email protected]

Last updated: 2015-11-24 12:01:20 +0100

Bugzilla Comment ID: 44

Date: 2015-06-03 09:15:29 +0200
From: Bogdan Pricope <[email protected]>

Implement/validate ICMPv6 Neighbor Advertisement and Neighbor Solicitation Messages

Bugzilla Comment ID: 140

Date: 2015-11-24 12:01:20 +0100
From: José Pekkarinen <[email protected]>

icmpv6 seems to be implemented, is this still missing?

Note: the issue was created automatically with bugzilla2github tool

Bugzilla Bug ID: 37

Date: 2015-06-03 09:14:56 +0200
From: Bogdan Pricope <[email protected]>
To: Sorin Vultureanu <[email protected]>

Last updated: 2015-06-03 09:14:56 +0200

Bugzilla Comment ID: 43

Date: 2015-06-03 09:14:56 +0200
From: Bogdan Pricope <[email protected]>

Move private header files to public for eg TCP and UDP so that the structures can be used universally

Note: the issue was created automatically with bugzilla2github tool

Bugzilla Bug ID: 33

Date: 2015-06-03 09:11:07 +0200
From: Bogdan Pricope <[email protected]>
To: Sorin Vultureanu <[email protected]>

Last updated: 2015-06-03 09:11:07 +0200

Bugzilla Comment ID: 39

Date: 2015-06-03 09:11:07 +0200
From: Bogdan Pricope <[email protected]>

Interface handling - "hijacking" interface in realtime, flagging interface in use etc

Note: the issue was created automatically with bugzilla2github tool

Bugzilla Bug ID: 50

Date: 2015-10-21 10:08:26 +0200
From: Sorin Vultureanu <[email protected]>
To: Sorin Vultureanu <[email protected]>

Last updated: 2015-10-21 10:08:26 +0200

Bugzilla Comment ID: 62

Date: 2015-10-21 10:08:26 +0200
From: Sorin Vultureanu <[email protected]>

Sync/Lock primitives can be disabled in some scenarios.

Note: the issue was created automatically with bugzilla2github tool

Bugzilla Bug ID: 20

Date: 2015-06-03 08:43:46 +0200
From: Bogdan Pricope <[email protected]>
To: Sorin Vultureanu <[email protected]>

Last updated: 2015-06-03 08:43:46 +0200

Bugzilla Comment ID: 25

Date: 2015-06-03 08:43:46 +0200
From: Bogdan Pricope <[email protected]>

Environment - core isolation and tickless

Note: the issue was created automatically with bugzilla2github tool

Bugzilla Bug ID: 55

Date: 2015-10-21 12:01:57 +0200
From: Sorin Vultureanu <[email protected]>
To: Bogdan Pricope <[email protected]>

Duplicates: #56
Last updated: 2015-11-05 09:36:35 +0100

Bugzilla Comment ID: 69

Date: 2015-10-21 12:01:57 +0200
From: Sorin Vultureanu <[email protected]>

Bugzilla Comment ID: 97

Date: 2015-11-05 09:36:35 +0100
From: Sorin Vultureanu <[email protected]>

*** This bug has been marked as a duplicate of bug #56 ***

Causes the below build warnings:

../include/ofpi_util.h:129:36: warning: cast increases required alignment of target type [-Wcast-align]
  return (((*(uint64_t *)addr1 ==  *(uint64_t *)addr2) &&
                                    ^
../include/ofpi_util.h:130:5: warning: cast increases required alignment of target type [-Wcast-align]
   (*(uint64_t *)(addr1 + 8) ==  *(uint64_t *)(addr2 + 8)))
     ^
../include/ofpi_util.h:130:34: warning: cast increases required alignment of target type [-Wcast-align]
   (*(uint64_t *)(addr1 + 8) ==  *(uint64_t *)(addr2 + 8)))
                                  ^
  CC       cli/ofp_cli_debug.lo
In file included from cli/ofp_cli_debug.c:14:0:
../include/ofpi_util.h: In function 'ofp_ip6_is_set':
../include/ofpi_util.h:125:12: warning: cast increases required alignment of target type [-Wcast-align]
  return ((*(uint64_t *)addr | *(uint64_t *)(addr + 8)) == 0 ? 0 : 1);
            ^
../include/ofpi_util.h:125:32: warning: cast increases required alignment of target type [-Wcast-align]
  return ((*(uint64_t *)addr | *(uint64_t *)(addr + 8)) == 0 ? 0 : 1);
                                ^
../include/ofpi_util.h: In function 'ofp_ip6_equal':
../include/ofpi_util.h:129:13: warning: cast increases required alignment of target type [-Wcast-align]
  return (((*(uint64_t *)addr1 ==  *(uint64_t *)addr2) &&
             ^
../include/ofpi_util.h:129:36: warning: cast increases required alignment of target type [-Wcast-align]
  return (((*(uint64_t *)addr1 ==  *(uint64_t *)addr2) &&
                                    ^
../include/ofpi_util.h:130:5: warning: cast increases required alignment of target type [-Wcast-align]
   (*(uint64_t *)(addr1 + 8) ==  *(uint64_t *)(addr2 + 8)))
     ^
../include/ofpi_util.h:130:34: warning: cast increases required alignment of target type [-Wcast-align]
   (*(uint64_t *)(addr1 + 8) ==  *(uint64_t *)(addr2 + 8)))

Note: the issue was created automatically with bugzilla2github tool

Bugzilla Bug ID: 47

Date: 2015-10-21 09:58:42 +0200
From: Sorin Vultureanu <[email protected]>
To: Sorin Vultureanu <[email protected]>

Last updated: 2015-11-26 12:19:27 +0100

Bugzilla Comment ID: 59

Date: 2015-10-21 09:58:42 +0200
From: Sorin Vultureanu <[email protected]>

Create a new issue for each situation identified by review.

Bugzilla Comment ID: 143

Date: 2015-11-26 12:19:27 +0100
From: Sorin Vultureanu <[email protected]>

Reviews done. Changes were made. We can close this.

Note: the issue was created automatically with bugzilla2github tool

Bugzilla Bug ID: 24

Date: 2015-06-03 08:48:56 +0200
From: Bogdan Pricope <[email protected]>
To: Sorin Vultureanu <[email protected]>
CC: [email protected]

Last updated: 2015-11-24 11:54:26 +0100

Bugzilla Comment ID: 29

Date: 2015-06-03 08:48:56 +0200
From: Bogdan Pricope <[email protected]>

Add/change naming for public/internal functionality

Note:
Discussed on 3 December meeting. Public calls can have odpfp_ prefix. Internal calls _odpfp or _. Internal local static calls don’t need any prefix. We can do this latter by using a script in a future task.

Note:
We should do this before public launch.

State:
Keep and add to all other things needed for public launch

Bugzilla Comment ID: 132

Date: 2015-11-24 11:41:17 +0100
From: José Pekkarinen <[email protected]>

This seems to be addressed nowadays, even though I don't remember to have heard any official intention on this. If you feel this is no longer applicable, let me know, to close this.

Bugzilla Comment ID: 138

Date: 2015-11-24 11:54:26 +0100
From: Sorin Vultureanu <[email protected]>

This task was done.

Note: the issue was created automatically with bugzilla2github tool

Bugzilla Bug ID: 30

Date: 2015-06-03 09:08:04 +0200
From: Bogdan Pricope <[email protected]>
To: Sorin Vultureanu <[email protected]>
CC: [email protected]

Last updated: 2015-11-24 12:02:41 +0100

Bugzilla Comment ID: 35

Date: 2015-06-03 09:08:04 +0200
From: Bogdan Pricope <[email protected]>

Fix socket API return code/errno values: errno vs. oipfp_return_code

Bugzilla Comment ID: 139

Date: 2015-11-24 11:56:05 +0100
From: José Pekkarinen <[email protected]>

There was work in this direction recently. What is the status on this?

Bugzilla Comment ID: 141

Date: 2015-11-24 12:02:41 +0100
From: Sorin Vultureanu <[email protected]>

Hi,

The return values should be documented with public API and later on internal headers.
There are 3 situations:

Ofp_errno is behaving for socket calls of ofp_socket.h, as errno in Linux system calls.
OFP does not have system calls, but code ported from Linux will bring the same return model, i.e. socket calls.
Calls from ofp_socket.h return 0 on success and -1 + errno set on failture.

The <ofp_errno.h> header file defines the integer variable ofp_errno, which
is set by system calls and some library functions in the event of an
error to indicate what went wrong. Its value is significant only
when the return value of the call indicated an error (i.e., -1 from
most system calls; -1 or NULL from most library functions); a
function that succeeds is allowed to change ofp_errno.
http://man7.org/linux/man-pages/man3/errno.3.html

On hierarchical packet processing routines return values can be ofp_return_code.
enum ofp_return_code {
OFP_PKT_CONTINUE = 0,
OFP_PKT_PROCESSED,
OFP_PKT_ON_HOLD,
OFP_PKT_DROP
};

For example:
enum ofp_return_code ofp_ipv4_processing(odp_packet_t pkt);

Like in ODP model:
0 on success
-1 or multiple values < -1 on failure but each case should be documented.

For example:
ofp_init_global() should return 0 on success and -1 on failure, as documented in API. Now it returns always 0, so it should be fixed.

Kind Regards,
Sorin

Note: the issue was created automatically with bugzilla2github tool

Bugzilla Bug ID: 19

Date: 2015-06-03 08:43:18 +0200
From: Bogdan Pricope <[email protected]>
To: Sorin Vultureanu <[email protected]>
CC: [email protected]

Last updated: 2015-11-24 11:52:20 +0100

Bugzilla Comment ID: 24

Date: 2015-06-03 08:43:18 +0200
From: Bogdan Pricope <[email protected]>

Environment - bare metal

Bugzilla Comment ID: 130

Date: 2015-11-24 11:36:51 +0100
From: José Pekkarinen <[email protected]>

Can anyone elaborate in what is this all about?

Bugzilla Comment ID: 136

Date: 2015-11-24 11:52:20 +0100
From: Sorin Vultureanu <[email protected]>

Run OFP in an environment that excludes Linux.
OFP application should run in other OSs and have no dependency to Linux or others.

Note: the issue was created automatically with bugzilla2github tool

Bugzilla Bug ID: 36

Date: 2015-06-03 09:14:03 +0200
From: Bogdan Pricope <[email protected]>
To: Sorin Vultureanu <[email protected]>

Last updated: 2015-06-03 09:14:03 +0200

Bugzilla Comment ID: 42

Date: 2015-06-03 09:14:03 +0200
From: Bogdan Pricope <[email protected]>

Multipath equal cost routing

Note: the issue was created automatically with bugzilla2github tool

Bugzilla Bug ID: 21

Date: 2015-06-03 08:44:13 +0200
From: Bogdan Pricope <[email protected]>
To: Sorin Vultureanu <[email protected]>

Last updated: 2015-06-03 08:44:13 +0200

Bugzilla Comment ID: 26

Date: 2015-06-03 08:44:13 +0200
From: Bogdan Pricope <[email protected]>

Environment - virtual

After cloning odp and tried to run ./bootstrap but ran into errors below.
I am running on Centos 6 linux.

Any help will be appreciated. Thx.

[root@localhost odp]# ./bootstrap

• aclocal -I config -I m4
  configure.ac:28: warning: macro `AM_PROG_AR' not found in library
• libtoolize --copy
  libtoolize: putting auxiliary files in .'. libtoolize: copying file./ltmain.sh'
  libtoolize: putting macros in AC_CONFIG_MACRO_DIR, m4'. libtoolize: copying filem4/libtool.m4'
  libtoolize: copying file m4/ltoptions.m4' libtoolize: copying filem4/ltsugar.m4'
  libtoolize: copying file m4/ltversion.m4' libtoolize: copying filem4/lt~obsolete.m4'
• autoheader
• automake --add-missing --copy --warnings=all
  configure.ac:23: installing ./compile' configure.ac:32: installing./config.guess'
  configure.ac:32: installing ./config.sub' configure.ac:3: installing./install-sh'
  configure.ac:3: installing ./missing' example/classifier/Makefile.am: installing./depcomp'
• autoconf --force
  configure.ac:30: error: possibly undefined macro: AM_PROG_AR
  If this token and others are legitimate, please use m4_pattern_allow.
  See the Autoconf documentation.
  configure:44072: error: possibly undefined macro: m4_argn
  configure:44072: error: possibly undefined macro: m4_default_nblank_quoted

Note: the issue was created automatically with bugzilla2github tool

Bugzilla Bug ID: 27

Date: 2015-06-03 09:02:29 +0200
From: Bogdan Pricope <[email protected]>
To: Sorin Vultureanu <[email protected]>

Last updated: 2015-06-03 09:02:29 +0200

Bugzilla Comment ID: 32

Date: 2015-06-03 09:02:29 +0200
From: Bogdan Pricope <[email protected]>

Conformance Test TCP protocol

Assigned: Sorin

Status:
Ongoing

Note: the issue was created automatically with bugzilla2github tool

Bugzilla Bug ID: 51

Date: 2015-10-21 11:48:51 +0200
From: Sorin Vultureanu <[email protected]>
To: Bogdan Pricope <[email protected]>

Last updated: 2015-11-05 09:37:19 +0100

Bugzilla Comment ID: 63

Date: 2015-10-21 11:48:51 +0200
From: Sorin Vultureanu <[email protected]>

Title of patch: Updated README, fpm example and example/README
The changes to example/fpm/app_main.c should be migrated to all other applications.
Please find a way to not duplicate code, make some generic function and call it from all applications.

Note: the issue was created automatically with bugzilla2github tool

Bugzilla Bug ID: 35

Date: 2015-06-03 09:13:19 +0200
From: Bogdan Pricope <[email protected]>
To: Andras Berger <[email protected]>
CC: [email protected]

Last updated: 2015-08-18 13:38:41 +0200

Bugzilla Comment ID: 41

Date: 2015-06-03 09:13:19 +0200
From: Bogdan Pricope <[email protected]>

Implement send_frame for L2 output

Bugzilla Comment ID: 54

Date: 2015-07-27 11:19:56 +0200
From: Andras Berger <[email protected]>

Requirements:
send_frame takes a valid packet as parameter with valid ethernet (IP, etc...) headers, and an output device.
The packet's ethernet header is modified to match the output device, MTU is checked before sending.

Note: the issue was created automatically with bugzilla2github tool

Bugzilla Bug ID: 32

Date: 2015-06-03 09:10:06 +0200
From: Bogdan Pricope <[email protected]>
To: Sorin Vultureanu <[email protected]>

Last updated: 2015-06-03 09:10:06 +0200

Bugzilla Comment ID: 38

Date: 2015-06-03 09:10:06 +0200
From: Bogdan Pricope <[email protected]>

Static ARPs configured in Linux should be notified and saved in fastpath

Note: the issue was created automatically with bugzilla2github tool

Bugzilla Bug ID: 52

Date: 2015-10-21 11:51:17 +0200
From: Sorin Vultureanu <[email protected]>
To: Sorin Vultureanu <[email protected]>

Last updated: 2015-10-21 11:51:17 +0200

Bugzilla Comment ID: 64

Date: 2015-10-21 11:51:17 +0200
From: Sorin Vultureanu <[email protected]>

Lint ?

Note: the issue was created automatically with bugzilla2github tool

Bugzilla Bug ID: 53

Date: 2015-10-21 11:52:38 +0200
From: Sorin Vultureanu <[email protected]>
To: Sorin Vultureanu <[email protected]>
CC: [email protected]

Last updated: 2015-11-26 14:49:33 +0100

Bugzilla Comment ID: 65

Date: 2015-10-21 11:52:38 +0200
From: Sorin Vultureanu <[email protected]>

Already started and 4 patches were submitted.

Note: the issue was created automatically with bugzilla2github tool

Bugzilla Bug ID: 49

Date: 2015-10-21 10:06:00 +0200
From: Sorin Vultureanu <[email protected]>
To: Sorin Vultureanu <[email protected]>
CC: [email protected]

Last updated: 2015-11-26 12:20:03 +0100

Bugzilla Comment ID: 61

Date: 2015-10-21 10:06:00 +0200
From: Sorin Vultureanu <[email protected]>

Ex: like the one that change the memory consumption inside the route table.

Create a new issue for each situation identified by review.

Bugzilla Comment ID: 68

Date: 2015-10-21 12:00:43 +0200
From: Sorin Vultureanu <[email protected]>

• hard-coded values such as number of ports (GRE port) and ARP timeout should be configurable.

Bugzilla Comment ID: 89

Date: 2015-11-02 14:35:48 +0100
From: Ciprian Barbu <[email protected]>

ofp_arp.c:411 - ofp_arp_save_ipv4_pkt computes newarp using hardcoded value of 5; although this is inside a sanity check block I think the value should at least be explained in a comment above.

Bugzilla Comment ID: 145

Date: 2015-11-26 12:20:03 +0100
From: Sorin Vultureanu <[email protected]>

Changes were made. We can close this.

Note: the issue was created automatically with bugzilla2github tool

Bugzilla Bug ID: 39

Date: 2015-06-03 15:36:03 +0200
From: Andras Berger <[email protected]>
To: Sorin Vultureanu <[email protected]>

Last updated: 2015-06-16 15:12:25 +0200

Bugzilla Comment ID: 45

Date: 2015-06-03 15:36:03 +0200
From: Andras Berger <[email protected]>

Improve performance and scalability of UDP socket when event interface is used.

Investigate the possibility to use per-flow locking instead of per socket locking to improve scalability. (Idea by Sorin Vultureanu)

Bugzilla Comment ID: 47

Date: 2015-06-03 17:06:44 +0200
From: Sorin Vultureanu <[email protected]>

The socket serialization problem is found here:

src/odpfp_udp_usrreq.c : udp_append()
SOCKBUF_LOCK(&so->so_rcv);
if (odpfp_sbappendaddr_locked(&so->so_rcv, append_sa, n, opts) == 0) {.
src/odpfp_uipc_sockbuf.c : odpfp_sbappendaddr_locked ()
/* Offer to event function */
if (packet_accepted_as_event(sb, pkt))
return 1;

instead:

packet_accepted_as_event() should be processed within read_lock(), before calling odpfp_sbappendaddr_locked() inside the write lock.

The pcb is found with a hash per remote addr, remote port and local port (per-flow).

Bugzilla Comment ID: 51

Date: 2015-06-16 15:11:29 +0200
From: Sorin Vultureanu <[email protected]>

Two commits done to fix this with review and testing from Andras:
b70e14880b4a6f1f7dd2c35977ceee04a7f3dfdc
4df4e624b47b8b422ff28a37caefbfa4e071659e

I've run the successfully below command to make ODP:

./bootstrap
./configure --prefix=/usr/local/odp
make
make install

The build configuration fails for OFP with the below commands:

./bootstrap
./configure --prefix=/usr/local/ofp --with-odp=/usr/local/odp --enable-cunit

Error displayed:

checking for pkg-config... /usr/bin/pkg-config
checking pkg-config is at least version 0.9.0... yes
checking for ODP... no
checking for ODP... no
checking for ODP... no
checking for ODP... no
checking for ODP... no
checking for ODP... no
checking for ODP... no
checking for ODP... no
checking for odp_packet_alloc in -lodp... no
configure: error: "This package needs OpenDataPlane (libodp.a) installed"

Note: the issue was created automatically with bugzilla2github tool

Bugzilla Bug ID: 22

Date: 2015-06-03 08:45:50 +0200
From: Bogdan Pricope <[email protected]>
To: Sorin Vultureanu <[email protected]>

Last updated: 2015-06-03 08:45:50 +0200

Bugzilla Comment ID: 27

Date: 2015-06-03 08:45:50 +0200
From: Bogdan Pricope <[email protected]>

Find a traffic generator

sysctl: cannot stat /proc/sys/net/ipv6/conf/fp0/autoconf: 没有那个文件或目录
Internet Systems Consortium DHCP Client 4.2.4
Copyright 2004-2012 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/

Cannot find device "fp0"
Error getting hardware address for "fp0": No such device

Note: the issue was created automatically with bugzilla2github tool

Bugzilla Bug ID: 23

Date: 2015-06-03 08:46:37 +0200
From: Bogdan Pricope <[email protected]>
To: Sorin Vultureanu <[email protected]>
CC: [email protected]

Last updated: 2015-11-24 11:53:50 +0100

Bugzilla Comment ID: 28

Date: 2015-06-03 08:46:37 +0200
From: Bogdan Pricope <[email protected]>

Tools - Sikuli

Bugzilla Comment ID: 131

Date: 2015-11-24 11:39:14 +0100
From: José Pekkarinen <[email protected]>

I think this should be closed unless anyone is interested in working in the integration of this tool.

Bugzilla Comment ID: 137

Date: 2015-11-24 11:53:50 +0100
From: Sorin Vultureanu <[email protected]>

This tool did not come to discussion since the start of the incubation project.
It can be close as this is not used in ODP and we don't plan to use it.

I am trying to build ofp and getting following compilation error.

It looks like pthread_create function has been changed in odp.

commit 1a7893cf034dcb0045c3f7a08559b0955b3093b5
Date: Wed Dec 16 15:14:14 2015 +0530

helper: linux: add thread type in pthread_create

The exisiting helper routine only create the worker threads.
However there is a need to use the same for creating the control
thread as well. e.g. CLI thread.

build@ubuntu:~/sources/ofp$ make
Making all in src
make[1]: Entering directory `/home/build/sources/ofp/src'
  CC       ofp_avl.lo
  CC       cli/ofp_cli.lo
cli/ofp_cli.c: In function 'ofp_start_cli_thread':
cli/ofp_cli.c:1724:6: error: too few arguments to function 'odph_linux_pthread_create'
  if (odph_linux_pthread_create(&ofp_global_cfg->cli_thread,
      ^
In file included from cli/ofp_cli.c:24:0:
/home/build/installs/odp/include/odp/helper/linux.h:67:5: note: declared here
 int odph_linux_pthread_create(odph_linux_pthread_t *thread_tbl,
     ^
make[1]: *** [cli/ofp_cli.lo] Error 1
make[1]: Leaving directory `/home/build/sources/ofp/src'
make: *** [all-recursive] Error 1

callout_pending is always true in ofp_tcp_timer_rexmt,
so ofp_tcp_timer_rexmt always returns after calling callout_pending.

vi ofp_tcp_timer.c

420 ofp_tcp_timer_rexmt(void * xtp)
.......
446 if ((inp->inp_flags & INP_DROPPED) || callout_pending(&tp->t_timers->tt_rexmt)
447 || !callout_active(&tp->t_timers->tt_rexmt)) {
448 INP_WUNLOCK(inp);
449 INP_INFO_RUNLOCK(&V_tcbinfo);
450 return;
451 }
......

hi,
I used nginx_ofp for proxy mode ,but it doesn't work.
I find that nginx_ofp and upstream has not establishment .(upstream response "syn+ack" but ofp didn't process it),I don't no why ,please help me,thanks

Note: the issue was created automatically with bugzilla2github tool

Bugzilla Bug ID: 28

Date: 2015-06-03 09:05:39 +0200
From: Bogdan Pricope <[email protected]>
To: Bogdan Pricope <[email protected]>

Last updated: 2015-07-27 12:52:49 +0200

Bugzilla Comment ID: 33

Date: 2015-06-03 09:05:39 +0200
From: Bogdan Pricope <[email protected]>

IPv6 UDP output

Assigned: Bogdan

Status:
Ongoing

Note: the issue was created automatically with bugzilla2github tool

Bugzilla Bug ID: 54

Date: 2015-10-21 11:54:29 +0200
From: Sorin Vultureanu <[email protected]>
To: Sorin Vultureanu <[email protected]>
CC: [email protected]

Last updated: 2015-11-26 12:45:56 +0100

Bugzilla Comment ID: 66

Date: 2015-10-21 11:54:29 +0200
From: Sorin Vultureanu <[email protected]>

Code structure:
The current structure is very flat, e.g. object files are placed in the same directory as c-files. A suggestion here is to mimic the ODP structure.

Bugzilla Comment ID: 67

Date: 2015-10-21 11:57:46 +0200
From: Sorin Vultureanu <[email protected]>

o Lightly modified software e.g. AVL, hash, etc. Would it be beneficial to migrate into a third_party/ directory as a pristine copy where it is easy to maintain and upgrade, then have ‘helpers’ in src/ ?

Bugzilla Comment ID: 85

Date: 2015-10-23 15:51:50 +0200
From: Rasmuss <[email protected]>

Created attachment 1
OFP source file structure proposal

Attached OFP source file strucutre proposal

Attached file: ofp_tree_proposal.txt (text/plain, 2205 bytes)
Description: OFP source file structure proposal

Bugzilla Comment ID: 107

Date: 2015-11-13 14:33:43 +0100
From: Sorin Vultureanu <[email protected]>

Created attachment 2
OFP tree proposal sent on mailing list for review

attached OFP tree proposal sent on mailing list for review

Attached file: ofp_tree_proposal.txt (text/plain, 2134 bytes)
Description: OFP tree proposal sent on mailing list for review

Bugzilla Comment ID: 108

Date: 2015-11-13 18:51:14 +0100
From: Rasmuss <[email protected]>

Hi,

Looks good!

My comments

1. Is there a reason for not having a /net/ folder?
2. Is there a reason why ARP isn't it in /netinet/ folder? (ARP is a IPv4 protocol, IPv6 uses NDP)
3. Where will object files and libraries be placed?
4. Is there a reason why the /api/ folder is placed directly in /ofp/ instead of having a /include/api/, as is the case with ODP?
5. I guess the Makefile is located in /OFp project root/ and the location is a typo.

BR
/Rasmuss

Bugzilla Comment ID: 109

Date: 2015-11-13 18:52:12 +0100
From: Rasmuss <[email protected]>

Hi,

Looks good!

My comments

1. Is there a reason for not having a /net/ folder?
2. Is there a reason why ARP isn't it in /netinet/ folder? (ARP is a IPv4 protocol, IPv6 uses NDP)
3. Where will object files and libraries be placed?
4. Is there a reason why the /api/ folder is placed directly in /ofp/ instead of having a /include/api/, as is the case with ODP?
5. I guess the Makefile is located in /OFp project root/ and the location is a typo.

BR
/Rasmuss

Bugzilla Comment ID: 110

Date: 2015-11-16 12:04:15 +0100
From: Sorin Vultureanu <[email protected]>

Hi,

1. There is no /src/net/ folder as it's functionality was not ported from BSD. There are no files that could go in a /net/ similar to BSD code. Discussed with Bogdan that we need to have some files in /src/ as a place to start. The code that is now in /src/ is the init and core of packet processing that is not BSD like.
2. Same reason as above(non BSD) and the fact that ARP is more related to a /net/ folder than a /netinet/ folder

3. Final deliverable destination can be controlled at build time. Now, temporary object files are in the same directory as .c file, while libraries are in /lib/. We could change to have all object files in /obj/, but ODP also has these temporary objects with the c code. This is a simpler change that can be applied in the configure build files.
4. As all headers are with .c files we don't use an include directory as ODP. We have some debate weather to have this directory named api or include. For me it's clearer with "api" that this directory is for external use rather than internal when use "include". include/api will have an empty include directory and it's taking longer to browse through the code.
5. Yes. Makefile remains where it is now in the root.

BR,
Sorin

Bugzilla Comment ID: 112

Date: 2015-11-17 15:53:58 +0100
From: Rasmuss <[email protected]>

Hi,

OK, one minor comment, with the current layout there will be a mix of files belonging to IPv4 and IPv6 in the /src/ folder, e.g. ofp_ndp.c when it is implemented.

BR
/Rasmuss

Bugzilla Comment ID: 146

Date: 2015-11-26 12:45:42 +0100
From: Sorin Vultureanu <[email protected]>

Created attachment 3
OFP tree proposal REVIEWED on the list with Nokia and ARM

On 11/17/2015 10:41 AM, José Pekkarinen wrote:

Hi,

On Monday 16 November 2015 13:29:21 EXT Sorin. Vultureanu wrote:

Hi Brian, all,

Thank you for the input!
Let's continue to discuss and clarify what should be the agreed solution.

Kind Regards,
Sorin

On 11/13/2015 11:44 PM, Brian Brooks wrote:

On Fri, Nov 13, 2015 at 01:31:03PM +0000, Sorin Vultureanu wrote:

OFP project
│ ├── Makefile
├── config
│ │ └── ofp_config.h
├── api

'include' instead of 'api' ?

Not sure which is the best. Let me explain my reasoning and see which is
better. For me using "api" shows that this directory is for external
interface only. When using "include" someone might not realize that this is
an external API. Leaving "include/api" as we have now, will have an empty
"include" directory and it's taking longer to browse through this
directory. Of course ODP has include directory but headers are in
"include/odp/api" directory.
I don't have any specific preference to this either. As a suggest, we can
start using api as you plan, and we can rethink anything later.

BR.

José.

│ │ └── ofp_.h (all files available now in include/api)
├── src
│ ├── ofp_arp.[c|h]
│ ├── ofp_gre.[c|h]
│ ├── ofp_init*.[c|h]
│ ├── ofp_pkt_processing*.[c|h]
│ ├── ofp_portconf.[c|h]
│ ├── ofp_route*.[c|h]
│ ├── ofp_rt_.[c|h]
│ ├── ofp_vxlan.[c|h]
│ ├── uipc
│ │ ├── ofp_errno.[c|h]
│ │ ├── ofp_hook.[c|h]
│ │ ├── ofp_uipc_.[c|h]
│ │ ├── ofp_sys_socket.[c|h]
│ │ ├── ofp_sysctl.[c|h]
│ │ ├── ofp_syscalls.[c|h]
│ │ ├── ofp_subr_hash.[c|h]
│ ├── linux
│ │ ├── ofp_quagga*.[c|h]
│ │ ├── ofp_netlink*.[c|h]
│ │ ├── ofp_tunthread*.[c|h]

Do we think that all code outside of this 'linux' directory is free of
Linux or platform-specific code & assumptions?

Yes. All code outside of linux/ should be free of Linux. All code outside of
this directory should be ODP-only dependent and some standard C
headers(available in all platforms). The only case where this might not be
100% true is the CLI case, where it creates sockets to Linux stack. But
this code is also divided as a cli/ directory and can be easily
disconnected.

│ ├── netinet
│ │ ├── ofp_icmp*.[c|h]
│ │ ├── ofp_ip_init*.[c|h] ->rename to ofp_ip_input.c
│ │ ├── ofp_in_.[c|h]
│ │ ├── ofp_inet.[c|h]
│ │ ├── ofp_igmp.[c|h]
│ │ ├── ofp_reass*.[c|h]
│ │ ├── ofp_udp_.[c|h]
│ │ ├── ofp_tcp_.[c|h]
│ ├── netinet6
│ │ ├── ofp_udp6*.[c|h]
│ │ ├── ofp_icmp6*.[c|h]
│ │ ├── ofp_in6*.[c|h]
│ │ ├── ofp_ip6_init.[c|h] ->rename to ofp_ip6_input.c
│ │ ├── ofp_nd6.[c|h]
│ ├── utils

'util' instead of 'utils' ?

OK.

│ │ ├── ofp_debug*.[c|h]
│ │ ├── ofp_log*.[c|h]
│ │ ├── ofp_util*.[c|h]
│ │ ├── ofp_timer*.[c|h]
│ │ ├── ofp_stat.[c|h]
│ │ ├── 3rd_party

Generally, third party software is located in the top-level level
directory under third_party/. So,

src/third_party/ instead of src/utils/3rd_party ?

OK.

│ │ │ ├── ofp_avl*.[c|h]
│ │ │ ├── ofp_hash*.[c|h]
│ │ │ ├── ofp_md5c.[c|h]
│ │ ├── cli

src/cli/ instead of src/utils/cli ?

To have less directories in src and to show that it can be disconnected from
OFP it was inside the /util/ directory. Also being in util/ directory shows
this CLI to be a useful functionality. Do we still agree to move it in
/src/ folder ?

│ │ │ └── ofp_cli*.[c|h]

test/ or src/test/ ?

test/ as in ODP ?

---

-- IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended
recipient, please notify the sender immediately and do not disclose the
contents to any other person, use it for any purpose, or store or copy
the information in any medium. Thank you.

---

odp-fp mailing list
[email protected]
http://lists.enea.com/mailman/listinfo/odp-fp

Attached file: ofp_tree_proposal_FINAL_REVIEWED.txt (text/plain, 2096 bytes)
Description: OFP tree proposal REVIEWED on the list with Nokia and ARM

Note: the issue was created automatically with bugzilla2github tool

Bugzilla Bug ID: 29

Date: 2015-06-03 09:06:38 +0200
From: Bogdan Pricope <[email protected]>
To: Bogdan Pricope <[email protected]>

Last updated: 2015-07-27 12:53:33 +0200

Bugzilla Comment ID: 34

Date: 2015-06-03 09:06:38 +0200
From: Bogdan Pricope <[email protected]>

IPv6 socket API

Assigned: Bogdan

Status:
Ongoing

Note: the issue was created automatically with bugzilla2github tool

Bugzilla Bug ID: 56

Date: 2015-10-21 12:02:35 +0200
From: Sorin Vultureanu <[email protected]>
To: Bogdan Pricope <[email protected]>
CC: [email protected], [email protected]

Last updated: 2015-11-11 12:32:46 +0100

Bugzilla Comment ID: 70

Date: 2015-10-21 12:02:35 +0200
From: Sorin Vultureanu <[email protected]>

Bugzilla Comment ID: 88

Date: 2015-11-02 14:32:52 +0100
From: Ciprian Barbu <[email protected]>

After reviewing the odp-fp code I think these should be looked at:

ofp_arp.c:477 - show_arp_entry effectively prints to stdout (fd=1), I think a log function should be used instead.

ofp_arp.c:650 - ofp_arp_alloc_shared_memory calls abort and exit
ofp_arp_ck.c:255 - same thing for ofp_arp_alloc_shared_memory

ofp_arp.c:668 - ofp_arp_lookup_shared_memory also calls abort and exit
ofp_arp_ck.c:272 - same thing

Bugzilla Comment ID: 98

Date: 2015-11-05 09:36:35 +0100
From: Sorin Vultureanu <[email protected]>

*** Bug #55 has been marked as a duplicate of this bug. ***

Note: the issue was created automatically with bugzilla2github tool

Bugzilla Bug ID: 48

Date: 2015-10-21 10:02:25 +0200
From: Sorin Vultureanu <[email protected]>
To: Sorin Vultureanu <[email protected]>

Last updated: 2015-11-26 12:19:44 +0100

Bugzilla Comment ID: 60

Date: 2015-10-21 10:02:25 +0200
From: Sorin Vultureanu <[email protected]>

Create a new issue for each situation identified by review.

Bugzilla Comment ID: 144

Date: 2015-11-26 12:19:44 +0100
From: Sorin Vultureanu <[email protected]>

Reviews done. Changes were made. We can close this.

Note: the issue was created automatically with bugzilla2github tool

Bugzilla Bug ID: 31

Date: 2015-06-03 09:08:52 +0200
From: Bogdan Pricope <[email protected]>
To: Bogdan Pricope <[email protected]>

Last updated: 2015-07-27 12:54:17 +0200

Bugzilla Comment ID: 36

Date: 2015-06-03 09:08:52 +0200
From: Bogdan Pricope <[email protected]>

Check ODPFP_INADDR_ANY support

Bugzilla Comment ID: 37

Date: 2015-06-03 09:09:22 +0200
From: Bogdan Pricope <[email protected]>

Assigned: Bogdan

Status: Ongoing

Note: the issue was created automatically with bugzilla2github tool

Bugzilla Bug ID: 43

Date: 2015-06-18 09:42:01 +0200
From: Andras Berger <[email protected]>
To: Andras Berger <[email protected]>

Last updated: 2015-06-26 10:39:15 +0200

Bugzilla Comment ID: 53

Date: 2015-06-18 09:42:01 +0200
From: Andras Berger <[email protected]>

• Move functions used by examples to public API.
• Fix public headers which include private headers
• Move protocol headers to public API

Note: the issue was created automatically with bugzilla2github tool

Bugzilla Bug ID: 42

Date: 2015-06-16 15:31:36 +0200
From: Andras Berger <[email protected]>
To: Andras Berger <[email protected]>

Last updated: 2015-06-24 14:17:26 +0200

Bugzilla Comment ID: 52

Date: 2015-06-16 15:31:36 +0200
From: Andras Berger <[email protected]>

Initial build of CUnit tests fails. Fix & refactor CUnit's automake files.

The README say that ".configure --enable-user-guide" should work.

configure: WARNING: unrecognized options: --enable-user-guide