LinuxQuestions.org
Register a domain and help support LQ
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Networking
User Name
Password
Linux - Networking This forum is for any issue related to networks or networking.
Routing, network cards, OSI, etc. Anything is fair game.

Notices

Reply
 
Search this Thread
Old 06-13-2008, 04:30 PM   #1
jc2it
LQ Newbie
 
Registered: Jan 2004
Posts: 29

Rep: Reputation: 15
Pinging across Router causes "(DUP!)" ping & No gdm login on thin clients


So, we have been having problems with getting thin clients to display a gdm login at remote sites.

Background:
Several years ago I upgraded our phone/data network. In the process our vendor specified a 1721 Cisco router at remote sites to connect to a 1841 at our main location. There are 3 remote locations connected via point to point clear channel T1 circuits.

The 1721 has a 10 mbs Ethernet connection, a 100 mbs Ethernet connection, and a serial connection for the T1. Data travels to the Main site via the 10mbs connection, and voice over IP interfaces with the local PBX via the 100 mbs port. While Troubleshooting a network upgrade at a remote site in March, I discovered that the 10 mbs connection had significant CRC errors. I found these errors on the switch and realized the Switch was set to auto negotiate and the router was coded to 10mbs Full-Duplex. The switch could not auto negotiate and then defaulted to half duplex. The immediate result was problemmatic connections (this consists of much jerky and hesitant responses) for our Telnet sessions to our ERP software. This was fixed by changing the managed switch port to 10mbs Full-duplex.

I then obtained some managed switches for my other two remote sites. Since I have made these changes I have alleviated the CRC errors and the jerky telnet sessions to our ERP software. PCAnywhere works much faster now as well.

The Problem:

At these other two remote sites I have a total of 4 thin clients. There are no thin clients at the first remote site. They have been working great for two years plus. Since the change only 1 will display a gdm login, and I am seeing duplicate ping responses. When I run wireshark at the Thin Client Server (Red Hat EL4) I see Duplicate packets often from the remote sites only. Also note that I have about 22 thin clients running, most are local. I am only experiencing this problem remotely.

When I ping to a local address everything appears normal.
Code:
# ping 192.168.2.170
PING 192.168.2.170 (192.168.2.170) 56(84) bytes of data.
64 bytes from 192.168.2.170: icmp_seq=0 ttl=64 time=0.134 ms
64 bytes from 192.168.2.170: icmp_seq=1 ttl=64 time=0.192 ms
64 bytes from 192.168.2.170: icmp_seq=2 ttl=64 time=0.221 ms
64 bytes from 192.168.2.170: icmp_seq=3 ttl=64 time=0.150 ms
64 bytes from 192.168.2.170: icmp_seq=4 ttl=64 time=0.226 ms
64 bytes from 192.168.2.170: icmp_seq=5 ttl=64 time=0.212 ms
64 bytes from 192.168.2.170: icmp_seq=6 ttl=64 time=0.115 ms

--- 192.168.2.170 ping statistics ---
7 packets transmitted, 7 received, 0% packet loss, time 6000ms
rtt min/avg/max/mdev = 0.115/0.178/0.226/0.044 ms, pipe 2
When I ping a remote IP address I get a duplicate.
Code:
# ping 192.168.11.89
PING 192.168.11.89 (192.168.11.89) 56(84) bytes of data.
64 bytes from 192.168.11.89: icmp_seq=0 ttl=126 time=26.1 ms
64 bytes from 192.168.11.89: icmp_seq=0 ttl=126 time=26.1 ms (DUP!)
64 bytes from 192.168.11.89: icmp_seq=1 ttl=126 time=11.4 ms
64 bytes from 192.168.11.89: icmp_seq=1 ttl=126 time=11.4 ms (DUP!)
64 bytes from 192.168.11.89: icmp_seq=2 ttl=126 time=11.5 ms
64 bytes from 192.168.11.89: icmp_seq=2 ttl=126 time=11.5 ms (DUP!)
64 bytes from 192.168.11.89: icmp_seq=3 ttl=126 time=24.3 ms
64 bytes from 192.168.11.89: icmp_seq=3 ttl=126 time=24.3 ms (DUP!)

--- 192.168.11.89 ping statistics ---
4 packets transmitted, 4 received, +4 duplicates, 0% packet loss, time 3005ms
rtt min/avg/max/mdev = 11.454/18.378/26.149/6.917 ms, pipe 2
When I ping my gateway to the remote sites I get a duplicate.
Code:
# ping 192.168.2.200
PING 192.168.2.200 (192.168.2.200) 56(84) bytes of data.
64 bytes from 192.168.2.200: icmp_seq=0 ttl=255 time=0.737 ms
64 bytes from 192.168.2.200: icmp_seq=0 ttl=255 time=0.752 ms (DUP!)
64 bytes from 192.168.2.200: icmp_seq=1 ttl=255 time=0.488 ms
64 bytes from 192.168.2.200: icmp_seq=1 ttl=255 time=0.494 ms (DUP!)
64 bytes from 192.168.2.200: icmp_seq=2 ttl=255 time=0.541 ms
64 bytes from 192.168.2.200: icmp_seq=2 ttl=255 time=0.547 ms (DUP!)
64 bytes from 192.168.2.200: icmp_seq=3 ttl=255 time=0.577 ms
64 bytes from 192.168.2.200: icmp_seq=3 ttl=255 time=0.583 ms (DUP!)

--- 192.168.2.200 ping statistics ---
4 packets transmitted, 4 received, +4 duplicates, 0% packet loss, time 3003ms
rtt min/avg/max/mdev = 0.488/0.589/0.752/0.100 ms, pipe 2
When I ping remotely with a -R I fget this result:
Code:
# ping -R 192.168.11.89
PING 192.168.11.89 (192.168.11.89) 56(124) bytes of data.
64 bytes from 192.168.11.89: icmp_seq=0 ttl=126 time=19.8 ms
NOP
RR:     192.168.2.15
        11.11.11.1
        192.168.11.200
        192.168.11.89
        11.11.11.2
        192.168.2.200
        192.168.2.15

64 bytes from 192.168.11.89: icmp_seq=0 ttl=126 time=19.9 ms (DUP!)
NOP     (same route)
64 bytes from 192.168.11.89: icmp_seq=1 ttl=126 time=19.2 ms
NOP     (same route)
64 bytes from 192.168.11.89: icmp_seq=1 ttl=126 time=19.2 ms (DUP!)
NOP     (same route)
64 bytes from 192.168.11.89: icmp_seq=2 ttl=126 time=26.2 ms
NOP     (same route)
64 bytes from 192.168.11.89: icmp_seq=2 ttl=126 time=26.2 ms (DUP!)
NOP     (same route)

--- 192.168.11.89 ping statistics ---
3 packets transmitted, 3 received, +3 duplicates, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 19.253/21.804/26.257/3.159 ms, pipe 2
What I have tried:

- Remove new network switch.
o No change.

- Swap ports of thin clients.
o No change. Working client does not move.

- Swap thin clients.
o Thin Client that was working doesn't. Non-working Thin Client now gets login. Is this a Magic Spot in the organization?

- Remove dhcpd.leases file. Restart dhcpd
o No Change.

- Clean out /tmp and /usr/tmp and /var/gdm on thin client server. Reboot.
o No change.

- Flush ARP tables on switches and routers. Restart Switches and Routers.
o No Change.

- Ship Thin Client to main site. Try out without making any config changes.
o Works great Here. In process of shipping back to remote site.

HELP ME!
 
Old 06-13-2008, 05:49 PM   #2
jc2it
LQ Newbie
 
Registered: Jan 2004
Posts: 29

Original Poster
Rep: Reputation: 15
more pings and "(DUP!)"

I remembered that yesterday I logged into one of the Thin Clients via SSH (They boot from CD-ROM into a Custom PXES Distro (Red Hat I think)), and I saw some interesting diagnostic info. I think it points to the Cisco 1841 192.168.2.200 as the cause of my duplicate packets across the WAN, but I am not sure WHAT on the Cisco would cause this.

Code:
# ping 192.168.8.228
PING 192.168.8.228 (192.168.8.228): 56 data bytes
64 bytes from 192.168.8.228: icmp_seq=0 ttl=64 time=0.4 ms
64 bytes from 192.168.8.228: icmp_seq=1 ttl=64 time=0.1 ms
64 bytes from 192.168.8.228: icmp_seq=2 ttl=64 time=0.1 ms
64 bytes from 192.168.8.228: icmp_seq=3 ttl=64 time=0.1 ms
64 bytes from 192.168.8.228: icmp_seq=4 ttl=64 time=0.1 ms

--- 192.168.8.228 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max = 0.1/0.1/0.4 ms
# ping 192.168.8.200
PING 192.168.8.200 (192.168.8.200): 56 data bytes
64 bytes from 192.168.8.200: icmp_seq=0 ttl=255 time=1.0 ms
64 bytes from 192.168.8.200: icmp_seq=1 ttl=255 time=1.0 ms
64 bytes from 192.168.8.200: icmp_seq=2 ttl=255 time=1.0 ms
64 bytes from 192.168.8.200: icmp_seq=3 ttl=255 time=1.1 ms

--- 192.168.8.200 ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max = 1.0/1.0/1.1 ms
# ping 192.168.2.200
PING 192.168.2.200 (192.168.2.200): 56 data bytes
64 bytes from 192.168.2.200: icmp_seq=0 ttl=254 time=12.5 ms
64 bytes from 192.168.2.200: icmp_seq=1 ttl=254 time=12.3 ms
64 bytes from 192.168.2.200: icmp_seq=2 ttl=254 time=12.3 ms
64 bytes from 192.168.2.200: icmp_seq=3 ttl=254 time=12.3 ms
64 bytes from 192.168.2.200: icmp_seq=4 ttl=254 time=12.3 ms

--- 192.168.2.200 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max = 12.3/12.3/12.5 ms
# ping 192.168.2.15
PING 192.168.2.15 (192.168.2.15): 56 data bytes
64 bytes from 192.168.2.15: icmp_seq=0 ttl=62 time=16.7 ms
64 bytes from 192.168.2.15: icmp_seq=0 ttl=62 time=17.2 ms (DUP!)
64 bytes from 192.168.2.15: icmp_seq=1 ttl=62 time=16.6 ms
64 bytes from 192.168.2.15: icmp_seq=1 ttl=62 time=17.0 ms (DUP!)
64 bytes from 192.168.2.15: icmp_seq=2 ttl=62 time=16.8 ms
64 bytes from 192.168.2.15: icmp_seq=2 ttl=62 time=17.3 ms (DUP!)
64 bytes from 192.168.2.15: icmp_seq=3 ttl=62 time=29.1 ms
64 bytes from 192.168.2.15: icmp_seq=3 ttl=62 time=30.0 ms (DUP!)

--- 192.168.2.15 ping statistics ---
4 packets transmitted, 4 packets received, 4 duplicates, 0% packet loss
round-trip min/avg/max = 16.6/20.0/30.0 ms
 
Old 06-13-2008, 06:22 PM   #3
jc2it
LQ Newbie
 
Registered: Jan 2004
Posts: 29

Original Poster
Rep: Reputation: 15
After reading this web page I remembered that in March we had turned on the port monitor to watch the router traffic across the remote network.

After disabling this port I do not have DUP! pings to remote sites from my main switch. What really cemented this in my mind was the fact that I did not get a DUP! from my remote site to the Cisco 1841. I then realized it had to be in the switch, or attached to the switch.

I then started looking for causes in switches that would result in DUP! pings. The website above takes about an IDS implementation. Way back in March we set up the Monitor port, but did not experience problems with it until about a week ago, and at the same time we changed out our network switches at the 2 remote sites. \

My theory is XDMCP was failing the Magic Cookie Authentication, because of the Duplicate packets generated by the Switch's Monitor Port. I don't know why it only affected 3 out of 4 Thin Clients or why the long delay from March till about a week ago, but perhaps you can shed some light on this.
 
Old 06-17-2008, 11:35 AM   #4
jc2it
LQ Newbie
 
Registered: Jan 2004
Posts: 29

Original Poster
Rep: Reputation: 15
Quote:
My theory is XDMCP was failing the Magic Cookie Authentication, because of the Duplicate packets generated by the Switch's Monitor Port. I don't know why it only affected 3 out of 4 Thin Clients or why the long delay from March till about a week ago, but perhaps you can shed some light on this.
Anyone out there understand the relationships of the Magic Cookie packet and Duplicate packets caused by a switch port in Monitor mode? Perhaps it is caused by the way the HP Procurve switch monitors traffic?
 
  


Reply

Tags
clients, gdm, login, ping


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
how to disable "last login log" & disable "last login message" when start login. hocheetiong Linux - Newbie 4 02-08-2011 05:35 AM
IPTABLES: interface on "192.168.1.0/24" won't route clients from "10.65.0.0" zivota Linux - Networking 2 06-09-2008 01:35 PM
"dig mx" and "ping google" do not work when bind9 runs.. why? alexxxis Linux - Software 4 01-07-2007 03:16 AM
a/p connected, route correct, ping router: "Destination Host Unreachable". DebianEtch shinyblue Linux - Wireless Networking 1 08-29-2006 09:34 PM
My clients "can browse" outside but "can't ping" outside mrnoe Linux - Networking 1 09-05-2003 02:55 PM


All times are GMT -5. The time now is 02:01 AM.

Main Menu
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration