Bug 804314

Summary: telnet fails with DISPLAY set to :0.0
Product: [Fedora] Fedora Reporter: Fernando Herrera <fherrera>
Component: glibcAssignee: Adam Tkac <atkac>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 16CC: atkac, fweimer, jakub, law, ovasik, schwab
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-03-18 05:31:35 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Fernando Herrera 2012-03-17 18:54:47 UTC 
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 19:26:15 UTC 
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 19:28:32 UTC 
actualy both, usb0 and tun0 interfaces need to be up to get the assertion.
Comment 3 Jeff Law 2012-03-18 05:31:35 UTC 

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