UDP Socket on Loopback address 127.0.0.1

[Neetika02]

Hello,

I am trying to bind a UDP Socket on loopback address 127.0.0.1 using ofp_socket and ofp_bind. I have created the local interface by calling: ofp_config_interface_up_local(0, 0, inet_addr("127.0.0.1"), 8); and then I call ofp_scoket and ofp_bind I receive an error: "Cannot assign requested address" Am I missing something?

Regards, Neetika

[bogdanPricope]

Hmm... I may need this feature. I'll have a look.

[bogdanPricope]

Do you have SP enabled? So far, my best guess is that is waiting for a message from netlink (ofp_netlink.c) before setting the address ...and for some reason is not arriving.

[Neetika02]

Yes, I have SP enabled, and from the traces it seemed to me that the IP Address gets plumbed OK But it refuses to let me create a UDP socket on the same.

On Wed, Aug 19, 2020 at 4:05 AM Bogdan Pricope notifications@github.com wrote:

Do you have SP enabled? So far, my best guess is that is waiting for a message from netlink (ofp_netlink.c) before setting the address ...and for some reason is not arriving.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/OpenFastPath/ofp/issues/257#issuecomment-675753275, or unsubscribe https://github.com/notifications/unsubscribe-auth/AQB7SBSKRDEIWVD7N56KPTLSBL63VANCNFSM4PP2CEGQ .

[bogdanPricope]

The logic around loopback interface is a little bit odd: probably netlink was responding differently in the past. Logic is like this:

• add an interface
• wait for netlink to inform you about link up and new address being set on linux 'lo' interface.

Now, 'link up' does not arrive (interface index under Linux is not set) and 'new address' does not arrive for 127.0.0.1 as it is already set (by Linux).

The best workaround so far:

1. flush 127.0.0.1 address from linux 'lo' ip addr flush dev lo
2. Modify code to set the 'correct' (in my case) linux interface index ofp_config_interface_up_local() { ... data->linux_index = 1; ofp_update_ifindex_lookup_tab(data); ... }
3. configure through ofp cli file the loopback interface $ cat ./ofp_lo.cli loglevel set debug ifconfig fp0 192.168.100.10/24 ifconfig lo0 127.0.0.1/8

Now, I can see address 127.0.0.1 set on the lo0 in the CLI ... don't know yet about bind.

[Neetika02]

Thanks Bogdan,

I will try these :-) Could you suggest me if we should be using the development branch of OFP? We are currently using the release 3.0.0 which as per the details got published in Dec 2018. We are facing a few issues in our IPv6 testing and we feel that it could be since we are using a very old code base. Is there any stability issues in the development branch. Also, is any new release expected soon?

[bogdanPricope]

Hi Neetika,

I am trying to find complete fix for this problem but basically I don't have enough time.

Please take a look at last commit from https://github.com/bogdanPricope/ofp/tree/loopifs Basically it gets the interface index (as reported by linux) and set it on the interface. You still need to:

1. flush 'lo' before starting ofp application ip addr flush dev lo
2. configure the ip on the interface in cli: ifconfig lo0 127.0.0.1/8 or with ofp_config_interface_up_local(...)

With that you should be able to bind and send/receive packets.

Note: my branch has some more commits .. you will need to integrate the last commit in your branch.

[bogdanPricope]

1. I am (from the beginning of 2020) an independent contributor to ofp... so all opinions are my own and not 'official'.
2. My opinion is that current version of development branch is better (fixes, etc.) but it requires an update of odp / dpdk. I know that not all the project owners are willing to do that.
3. IPv6 was not requested by many customers... so was not fully developed or tested.
4. I have no idea when the next release will take place (Nokia & friends can answer to this question).

I am contributing to the OFP (and to my own forked version of it) in my spare time but if your company is willing to pay for support and development we can discuss.