Bug 59 - pasta --config-net -a <address> doesn't seem to set the address properly
Summary: pasta --config-net -a <address> doesn't seem to set the address properly
Status: RESOLVED FIXED
Alias: None
Product: passt
Classification: Unclassified
Component: pasta (show other bugs)
Version: unspecified
Hardware: All Linux
: Normal quite bad
Assignee: David Gibson
URL:
Depends on:
Blocks:
 
Reported: 2023-06-27 05:17 UTC by David Gibson
Modified: 2023-06-28 03:15 UTC (History)
1 user (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Description David Gibson 2023-06-27 05:17:07 UTC 
Discovered this while tracking down some errors in podman tests.

To reproduce:

$ ./pasta --config-net -a 192.0.2.1 -- ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: enp34s0u2u1u2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 65520 qdisc fq_codel state UNKNOWN group default qlen 1000
    link/ether f2:1b:03:90:37:c0 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::f01b:3ff:fe90:37c0/64 scope link tentative 
       valid_lft forever preferred_lft forever


Note that no (global) addresses are configured on the pasta interface.  They shou up correctly if using the default address assignment (no -a option).
Comment 1 Stefano Brivio 2023-06-27 05:26:04 UTC 
Do you have commit d034fb698f23 ("conf: Make -a/--address really imply --no-copy-addrs")? That fixes the issue for me:

$ ./pasta --config-net -a 192.0.2.1 -- ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: enp9s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 65520 qdisc fq_codel state UNKNOWN group default qlen 1000
    link/ether 1e:83:08:f6:5a:ce brd ff:ff:ff:ff:ff:ff
    inet 192.0.2.1/24 scope global enp9s0
       valid_lft forever preferred_lft forever
    inet6 2a01:4f8:222:904::2/64 scope global nodad 
       valid_lft forever preferred_lft forever
    inet6 fe80::1c83:8ff:fef6:5ace/64 scope link tentative 
       valid_lft forever preferred_lft forever
Comment 2 David Gibson 2023-06-27 06:12:46 UTC 
This is a regression with a brief but complicated history:

e89da3cf "netlink: Add functionality to copy addresses from outer namespace"
   This first introduced the bug, after this, the interface doesn't get an address configured at all.

cc9d1675 "conf, pasta: With --config-net, copy all addresses by default"
   This enabled the previous patch by default - even when it shouldn't.  After this, the interface gets an address copied from the host, even with -a set.

d034fb69 "conf: Make -a/--address really imply --no-copy-addrs"
    Fix for the previous, we no longer copy addresses when we shouldn't.  Unfortunately this just re-exposes the original bug and we get no address configured at all.
Comment 3 David Gibson 2023-06-27 06:15:29 UTC 
Sent that history before I saw your reply.  So, yes, I have that patch.  I've found the problem and it's different - we're setting the wrong interface index on NL_SET operations.  I suspect you're getting away with it because you happen to have the same index (2) for the interface you need in both host and guest.
Comment 4 David Gibson 2023-06-27 06:23:28 UTC 
I have a patch which I'm testing now, expect to post soon.
Comment 5 David Gibson 2023-06-28 03:15:46 UTC 
Fix is now merged and release.
Note You need to log in before you can comment on or make changes to this bug.