[Bug 1139983] New: MOTD/Banner displays incorrect temporary ipv6 address
http://bugzilla.suse.com/show_bug.cgi?id=1139983 Bug ID: 1139983 Summary: MOTD/Banner displays incorrect temporary ipv6 address Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Kubic Assignee: kubic-bugs@opensuse.org Reporter: william.brown@suse.com QA Contact: qa-bugs@suse.de Found By: --- Blocker: --- Welcome to openSUSE MicroOS (x86_64) - Kernel 5.1.10-1-default (ttyS0). SSH host key: SHA256:6QuFaJra32Q8YuDkPOAvBPuacPy/LTCfsXHyJyylX8c (RSA) SSH host key: SHA256:4k9o1M7R+Udl45mZ22fbh8zE8V4Euldaa+zwW6OpTC8 (DSA) SSH host key: SHA256:owuHie1/KxmL5AakWgsUCnMFUTZWbg5FUeuZmCgZ6oo (ECDSA) SSH host key: SHA256:f/etHr1/kSajCkJJifh+tfD0M+txifFYTIy9yJDGOLc (ED25519) ens3: 172.24.15.18 2001:44b8:2155:2c15:b920:673c:ab7a:e897 linux-om6d login: root Password: linux-om6d:~ # 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: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether 52:54:00:12:22:b9 brd ff:ff:ff:ff:ff:ff inet 172.24.15.18/24 brd 172.24.15.255 scope global ens3 valid_lft forever preferred_lft forever inet6 2001:44b8:2155:2c15:b920:673c:ab7a:e897/64 scope global temporary dynamic valid_lft 86366sec preferred_lft 14366sec inet6 2001:44b8:2155:2c15:5054:ff:fe12:22b9/64 scope global dynamic mngtmpaddr valid_lft 86366sec preferred_lft 14366sec inet6 fe80::5054:ff:fe12:22b9/64 scope link valid_lft forever preferred_lft forever Note that the banner is displaying the global temporary address, rather than the dynamic mngtm address which is fixed. This means that if someone was to copy-paste from the banner to their DNS they would be registering an ephemeral address rather than the correct one. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1139983 http://bugzilla.suse.com/show_bug.cgi?id=1139983#c1 Thorsten Kukuk <kukuk@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|kubic-bugs@opensuse.org |sbrabec@suse.com --- Comment #1 from Thorsten Kukuk <kukuk@suse.com> --- That's getty displaying the addresses. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1139983 http://bugzilla.suse.com/show_bug.cgi?id=1139983#c2 Stanislav Brabec <sbrabec@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |CONFIRMED --- Comment #2 from Stanislav Brabec <sbrabec@suse.com> --- This is done by heuristic in util-linux/term-utils/agetty.c:output_iface_ip() -> print_addr() -> inet_ntop(3) It needs to be improved for IPv6. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1139983 http://bugzilla.suse.com/show_bug.cgi?id=1139983#c3 --- Comment #3 from Stanislav Brabec <sbrabec@suse.com> --- Actually, the whole heuristic just picks a proper interface. It contains no heuristic for a proper IP address of the interface. It just prints the first one. getifaddrs() returns linked list of struct ifaddrs. for (p = addrs; p; p = p->ifa_next) goex through addresses, but once any single address is found (if (addr)), it is printed and function returns. If I comment out the "return" there, it will print all addresses. We always need to go through all returned addresses and pick the most proper one. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1139983 http://bugzilla.suse.com/show_bug.cgi?id=1139983#c4 --- Comment #4 from Stanislav Brabec <sbrabec@suse.com> --- Created attachment 811237 --> http://bugzilla.suse.com/attachment.cgi?id=811237&action=edit addr.c: Address reporting as command line tool Address reporting extracted from agetty.c and others as a separate command line tool. Usage: addr Reports the same like \6 addr eth0 Reports the same like \6{eth0} -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1139983 http://bugzilla.suse.com/show_bug.cgi?id=1139983#c5 Stanislav Brabec <sbrabec@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|CONFIRMED |IN_PROGRESS CC| |jbohac@suse.com, | |mkubecek@suse.com Flags| |needinfo?(mkubecek@suse.com | |), | |needinfo?(jbohac@suse.com) --- Comment #5 from Stanislav Brabec <sbrabec@suse.com> --- I spent two days in learning of the network code. As far as I understand, the current agetty code (see comment 4) is not capable to discriminate between global, link and ephemeral IPv6 address as well as it is not capable to discriminate between primary and secondary IPv4 address. If I read the documentation correctly, there are at least three completely different implementations of IP addresses interface: - POSIX getifaddrs() used by agetty. - sockios ioctl() and its SIOC* commands, used by the old net-tools, e. g. ifconfig. - NETLINK_ROUTE netlink messages, used by iproute2, e. g. ip. Only the first one is portable. And probably only the last one is capable to provide ifaddrmsg, the structure that reports type of the IP address as well as lifetime for ephemeral addresses. (For the first one I am pretty sure that it is not possible, as the documented part does not contain it, and ifa_data is unused by kernel and set to zero in glibc. I am not sure for the second interface.) The third interface is used by ip, and so it seems to be possible to get the requested information in that way. Could you confirm that I have to rewrite the agetty to NETLINK_ROUTE to fix this bug? Are you aware of any sample code that is more readable than iproute2? In case of rewrite to NETLINK_ROUTE, it could make sense to parse network change messages, but it would require even larger rewrite of agetty. Note that it is a bit confusing that linux/if_addr.h refer to ifa_flags, which are part of struct ifaddrs from getifaddrs(). It is probably recycled in more interfaces. So, I definitely see that ifa_flags contains items starting with IFF_. And that starting with IFA_F_ is surely not part of ifa_flags from getifaddrs(), but probably returned in netlink messages. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1139983 http://bugzilla.suse.com/show_bug.cgi?id=1139983#c6 Stanislav Brabec <sbrabec@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |kukuk@suse.com Flags|needinfo?(mkubecek@suse.com | |), | |needinfo?(jbohac@suse.com) | --- Comment #6 from Stanislav Brabec <sbrabec@suse.com> --- After a discussion with jbohac and mkubecek, I realized that there is indeed no easy fix for this bug. Fixing this bug means migrating of this code from POSIX getifaddrs() to NETLINK_ROUTE netlink messages. As another part of agetty.c already uses NETLINK_ROUTE netlink messages (the changes monitor), it makes sense to write and use address parser in both cases. The current implementation is incredibly ugly: 1. issue-generator listens to udev to monitor new network devices. 2. Dedicated code in the issue-generator generated an updated issue file which lists network devices that are considered as relevant (text match is use for this). 3. agetty reload feature reloads issue file. 4. agetty listens to NETLINK_ROUTE netlink messages and monitors all network changes (new addresses, removed addresses, router advertisement, devices added,...) 5. Whenever any netlink message is received, it is discarded, and getifaddrs() is used to resolve IP addresses. 6. After receiving of any netlink messages, the whole issue file is rendered to the memory, compared with the previous one, and if there is any text change and users did not start to type yet, issue is re-rendered. Caveats: - However there are two processes monitoring interfaces changes, agetty always does full evaluation of the issue file and evaluation of all addresses. - agetty does full evaluation of all addresses even if no change in interfaces or IP addresses appears (e. g. for every IPv6 RaS). It also has some ugly aspects: - On a very large router systems (thousands of IP addresses), NETLINK_ROUTE netlink monitor messages can appear several times in a second, which can cause unwanted load (or even getifaddrs() may fail). - If there is a large number of interfaces, agetty may scroll. So I am proposing some additional changes: - Parse netlink messages in the monitor and ignore those that does not cause IP address list or interface list change as soon as possible. - Improve the special char format to implement for-all-relevant-network-devices{write foo\n}. It would obsolete issue-generator. - Add an interfaces counter and IP addresses counter. - If the number of relevant interfaces exceeds some limit (e. g. 5 interfaces), skip IP listing at all, as it is probably a router system. - If the number of global IP addresses exceed some limit (e. g. 3), write just "multihoming". Otherwise type all global addresses (or primary addresses in case of IPv4). If none,exists, use heuristic to get a best fit (link address, ephemeral address with a longest validity time). -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1139983 https://bugzilla.suse.com/show_bug.cgi?id=1139983#c7 Stanislav Brabec <sbrabec@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|IN_PROGRESS |RESOLVED Resolution|--- |WONTFIX --- Comment #7 from Stanislav Brabec <sbrabec@suse.com> --- Fixing thus bug would require rewrite of a large part of agetty.c. I doubt that it will be done anytime soon. Closing as WONTFIX. Anyway, the process of fixing is well described for anybody who would want to do that. -- You are receiving this mail because: You are on the CC list for the bug.
participants (2)
-
bugzilla_noreply＠novell.com -
bugzilla_noreply＠suse.com