Bug 426979 - TAHI--DNSv6--TN can't Receive SYN Packet
Summary: TAHI--DNSv6--TN can't Receive SYN Packet
Keywords:
Status: CLOSED DUPLICATE of bug 428446
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: bind
Version: 5.1
Hardware: All
OS: Linux
urgent
medium
Target Milestone: rc
: ---
Assignee: Adam Tkac
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks: 253764
TreeView+ depends on / blocked
 
Reported: 2007-12-29 07:37 UTC by Zhiyong Wu
Modified: 2013-04-30 23:37 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2008-01-14 10:00:45 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Zhiyong Wu 2007-12-29 07:37:00 UTC
Description of problem:

  When having DNSv6 tests in the server mode,we found that TN can't Receive SYN
Packet.

Version-Release number of selected component (if applicable):

  kernel-2.6.18-53.el5

Software Environment:   
  Testee(NUT):   
    RHEL5 
    Kernel:2.6.18-53.el5 
   
  Tester(TN):   
    FreeBSD6.2
    v6eval-3.0.12.tar.gz
   
TAHI package:    
  DNS_Self_Test_1-1-1.tgz

How reproducible:
  every time

Steps to Reproduce:    
  1. Configure TAHI test environment.     
  2. Run the TAHI test suite     
  3. After the test completes, check for the results 
  
Actual results:

   TN can't Receive SYN Packet.

Expected results:

   TN can Receive SYN Packet.

Additional info:
  
   please refer to

   NUT is set to be the client mode

http://focus.brisbane.redhat.com/~zwu/RHEL5.1-Server-20071017.0/20071220/DNS_Self_Test_1-1-1_client/index.html

   (1) 89	Returning of answer

   (2) 91	Priority comparison

   (3) 92	Priority comparison (round-robin)

   (4) 93	Weight comparison

Comment 1 RHEL Program Management 2007-12-30 23:54:39 UTC
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.

Comment 3 Adam Tkac 2008-01-11 10:09:28 UTC
I've started testing (by hand, of course) of problem 1 (Returning of answer) and
found some strange configuration mistakes.
Machine 1: IPV6tester, FreeBSD, 10.66.65.104
Machine 2: IPv6testee, RHEL 5.1, 10.66.65.103

First, network configuration (from
http://focus.brisbane.redhat.com/~zwu/RHEL5.1-Server-20071017.0/20071220/DNS_Self_Test_1-1-1_client/CL/CL_RFC2782_SRV_return_answer.html)
should have this topology:

Machine 1: IPv6 addr 3ffe:501:ffff:101::20
                            |
                      router 3ffe:501:ffff:100::1
                            |
Machine 2: IPv6 addr 3ffe:501:ffff:100:XXXX


Machine 2 has correct configuration (ifconfig eth0 says inet6
3ffe:501:ffff:100:21a:a0ff:febd:5d1/64) but I'm pretty unsure about machine 1.
It doesn't have any IPv6 address assigned. Also I'm not able ping6 router.
Please tell me if network configuration is set as expected. Looks it isn't for me.

Comment 4 Adam Tkac 2008-01-14 10:00:45 UTC

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

Comment 5 Zhiyong Wu 2008-01-14 10:30:28 UTC
Machine 1: IPV6tester, FreeBSD, 10.66.65.104
Machine 2: IPv6testee, RHEL 5.1, 10.66.65.103

(1) the two interfaces is not used for testing DNSv6, but used for your remotely 

login.

(2) the two interfaces used for testing DNSv6 are rl0(192.168.0.10 freebsd6.2)
and eth0 (192.168.0.11 rhel5.1)

(3) the topology above is a logical topology, TAHI test suites will create it 

automatically.

note that the network configuration you saw last time is used for IPv6 DNS test.

now, you can login IPV6tester by ssh 10.66.65.104 and IPV6testee by ssh 

10.66.65.103, and look at the ipv6 DNS test environment. 

Comment 6 Zhiyong Wu 2008-01-14 10:40:47 UTC
the two interfaces used for ipv6 DNS test are:

Machine 1: IPV6tester, FreeBSD, rl0 , 192.168.0.11
Machine 2: IPv6testee, RHEL 5.1, eth0, 192.168.0.10


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