Bug 804314 - telnet fails with DISPLAY set to :0.0
telnet fails with DISPLAY set to :0.0
Status: CLOSED DUPLICATE of bug 739743
Product: Fedora
Classification: Fedora
Component: glibc (Show other bugs)
16
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Adam Tkac
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-03-17 14:54 EDT by Fernando Herrera
Modified: 2016-11-24 10:49 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-03-18 01:31:35 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Fernando Herrera 2012-03-17 14:54:47 EDT
After a recent update in Fedora 16, telnet client is failing when DISPLAY env variable is set to :0.0
[fer@dyckola ~]$ DISPLAY=:0.0 telnet 192.168.4.1
telnet: ../sysdeps/posix/getaddrinfo.c:1662: rfc3484_sort: Assertion `src->results[i].native == -1 || src->results[i].native == a2_native' failed.
Abortado
[fer@dyckola ~]$ DISPLAY=localhost:0.0 telnet 192.168.4.1
Trying 192.168.4.1...
Connected to 192.168.4.1.
Escape character is '^]'.

Samsung login:
Comment 1 Fernando Herrera 2012-03-17 15:26:15 EDT
Looks like a problem in glibc getaddrinfo function:
(gdb) p src->results[9]
$25 = {dest_addr = 0x55555577e190, source_addr = {sin6_family = 10, sin6_port = 29340, sin6_flowinfo = 0, sin6_addr = {__in6_u = {
        __u6_addr8 = "\376\200\000\000\000\000\000\000\002%\"\377\376\263\301\"", __u6_addr16 = {33022, 0, 0, 0, 9474, 65314, 46078, 8897}, 
        __u6_addr32 = {33022, 0, 4280427778, 583119870}}}, sin6_scope_id = 2}, source_addr_len = 28 '\034', got_source_addr = true, 
  source_addr_flags = 0 '\000', prefixlen = 64 '@', index = 2, native = -1}

this is unrelated to telnet, as I can reproduce it with a simple test case. It happens only when the interface tun0 (openvpn) is up.
Comment 2 Fernando Herrera 2012-03-17 15:28:32 EDT
actualy both, usb0 and tun0 interfaces need to be up to get the assertion.
Comment 3 Jeff Law 2012-03-18 01:31:35 EDT

*** This bug has been marked as a duplicate of bug 739743 ***

Note You need to log in before you can comment on or make changes to this bug.