G'day, fellow SuSE users. I've got a puzzler concerning ping responses that I hope someone can enlighten me about. I have a piece of industrial equipment that uses a TCP/IP Ethernet interface that I'm trying to troubleshoot at work. Part of the manufacturer's troubleshooting checklist is to "connect an DOS/Windows computer and use the PING command from the command line." Not having a D/W computer handy, I plugged in my SuSE 9.1 Pro laptop, but couldn't get a response. Not even a "connection refused," just silence. After some fairly exhaustive troubleshooting, this is what we found: 1: A DOS ping command, from another computer, using the same IP and netmask, over the same cable, got an immediate response. 2: The SuSE machine could not get a ping response, but *did* see the various open and filtered ports on the inustrial box, on the correct IP, when using nmap. 3: De/Re-activating SuSE Firewall made no difference. 4: The SuSE machine's ping command worked perfectly on a regular network, pinging Windows & *nix computers and various hardware routers without any difficulty. All I can think of is that there must be some minor difference between SuSE pings (or perhaps Linux pings in general) and DOS/Win pings that doesn't matter to most networks, but *does* matter for some reason to this piece of industrial hardware. Thoughts?
On Wednesday 30 November 2005 2:11 pm, David McMillan wrote: > I have a piece of industrial equipment that uses a TCP/IP Ethernet > interface that I'm trying to troubleshoot at work. Part of the > manufacturer's troubleshooting checklist is to "connect an DOS/Windows > computer and use the PING command from the command line." Not having > a D/W computer handy, I plugged in my SuSE 9.1 Pro laptop, but > couldn't get a response. Not even a "connection refused," just silence. > After some fairly exhaustive troubleshooting, this is what we found: > 1: A DOS ping command, from another computer, using the same IP and > netmask, over the same cable, got an immediate response. > 2: The SuSE machine could not get a ping response, but *did* see the > various open and filtered ports on the inustrial box, on the correct > IP, when using nmap. > 3: De/Re-activating SuSE Firewall made no difference. > 4: The SuSE machine's ping command worked perfectly on a regular > network, pinging Windows & *nix computers and various hardware routers > without any difficulty. > > All I can think of is that there must be some minor difference > between SuSE pings (or perhaps Linux pings in general) and DOS/Win > pings that doesn't matter to most networks, but *does* matter for some > reason to this piece of industrial hardware. > Thoughts? When Linux pings another host, it sends out the ICMP message and waits for a response. After some time it should time out. Check the default route. Here are some steps you should look at: 1. Make sure your cables are correct. 2. run netstat -nr on your system. You should have a route to the subnet and a default route. Are you using DHCP or a static IP address? netstat should look sim,ilar to this. Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo 0.0.0.0 192.168.0.1 0.0.0.0 UG 0 0 0 eth0 3. Are you using a name or an IP address to ping the equipment? If you are using a name, are you getting a a resolution to that name? -- Jerry FeldmanBoston Linux and Unix user group http://www.blu.org PGP key id:C5061EA9 PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9
Jerry Feldman wrote:
When Linux pings another host, it sends out the ICMP message and waits for a response. After some time it should time out. Check the default route.
No route. Just a crossover Cat5.
Here are some steps you should look at: 1. Make sure your cables are correct.
Used the same cable for the Windows and SuSE boxes.
2. run netstat -nr on your system. You should have a route to the subnet and a default route. Are you using DHCP or a static IP address? netstat should look sim,ilar to this.
Static IP. No routes, but I'll try netstat on it anyway next chance I get.
3. Are you using a name or an IP address to ping the equipment?
IP. The industrial box doesn't support named access, as far as I know.
On Thursday 01 December 2005 3:06 pm, David McMillan wrote:
No route. Just a crossover Cat5.
Here are some steps you should look at: 1. Make sure your cables are correct.
Used the same cable for the Windows and SuSE boxes.
ok, cable, windows box, industrial box are "known good"
2. run netstat -nr on your system. You should have a route to the subnet and a default route. Are you using DHCP or a static IP address? netstat should look sim,ilar to this.
Static IP. No routes, but I'll try netstat on it anyway next chance I get.
3. Are you using a name or an IP address to ping the equipment?
IP. The industrial box doesn't support named access, as far as I know.
No computers support names on tcp/ip. DNS servers (software), convert names (for humans) to IP addresses (for computers). What the reply was getting at is that if you were pinging a name, first, ping would have to as DNS for IP, then uses IP to do actual ping. e.g. brad@linux64:~/supers/mozilla> ping wtp.net PING wtp.net (216.187.141.20) 56(84) bytes of data. 64 bytes from 180com.net (216.187.141.20): icmp_seq=1 ttl=251 time=14.7 ms 64 bytes from 180com.net (216.187.141.20): icmp_seq=2 ttl=251 time=14.7 ms You can see the name getting converted before the ping, and used for the ping. Anyway, that is now also known good. (We don't need DNS, you know the IP). The only question we have then is, "Is the SuSE box known good?" So, I'll ask. Can you / Have you been able to ping anything with that box? Does it have internet access? (to test a ping like microsoft.com or your isp or gateway or something) Can you Windows box ping the SuSE box? (does it answer?) Does the ping comand even work on the SuSE box? Can it ping itself? e.g. rad@linux64:~/supers/mozilla> ping localhost PING localhost (127.0.0.1) 56(84) bytes of data. 64 bytes from localhost (127.0.0.1): icmp_seq=1 ttl=64 time=0.041 ms 64 bytes from localhost (127.0.0.1): icmp_seq=2 ttl=64 time=0.043 ms This should narrow down the possibilities anyway. Like someone else pointed out. Ping is a TCP/IP protocal / networking thing. It would be like saying Windows HTML is different than Linux's HTML, or Windows Font is different that Linux's font. See what I mean? PING, HTML, FONTS are their own independant things, not tied to any one OS. The software that reads, write, implements uses these standards are tied to their OS though. But, both softwares work right, You shouldn't be able to tell the difference between a ping from a windows box from a ping from a linux box, from a ping from a Mac or a ping from any othere piece of hardware (routers, etc.) Just like a person looking at html code can't tell if the original author wrote the html on a wintel, lintel, or mac box. You should be able to tell what printed a document with fonts on it.... etc. Hope this clears things up and make it easier for you. B-)
Brad Bourn wrote:
ok, cable, windows box, industrial box are "known good"
Yep, verified several different ways.
Anyway, that is now also known good. (We don't need DNS, you know the IP).
The only question we have then is, "Is the SuSE box known good?"
So, I'll ask. Can you / Have you been able to ping anything with that box?
Oh, yes. Ping works fine across the the internet, on my home LAN, on the corporate intranet, and on various WiFi hotspots. Never any trouble.
Does it have internet access? (to test a ping like microsoft.com or your isp or gateway or something)
Can you Windows box ping the SuSE box? (does it answer?)
Hooked up all three machines on a small switch (definitely a switch, not a router -- I checked) to try more testing. XP and SuSE could not ping each other until I killed SuSEFirewall -- after that, perfect pings, both ways. XP could still ping Industrial, but SuSE couldn't.
Does the ping comand even work on the SuSE box? Can it ping itself?
Yep. # ping 172.16.200.241 PING 172.16.200.241 (172.16.200.241) 56(84) bytes of data. 64 bytes from 172.16.200.241: icmp_seq=1 ttl=64 time=0.169 ms 64 bytes from 172.16.200.241: icmp_seq=2 ttl=64 time=0.164 ms Ran an nmap of the subnet: (SuSE is .241, XP is .245, Industrial is .240. Netmasks are all 255.255.0.0): Starting nmap 3.50 ( http://www.insecure.org/nmap/ ) at 2005-12-02 13:43 EST sendto in send_ip_raw: sendto(4, packet, 28, 0, 172.16.200.0, 16) => Operation not permitted Interesting ports on 172.16.200.240: (The 1641 ports scanned but not shown below are in state: closed) PORT STATE SERVICE 23/tcp open telnet 24/tcp filtered priv-mail 137/tcp filtered netbios-ns 273/tcp filtered unknown 334/tcp filtered unknown 517/tcp filtered talk 552/tcp filtered deviceshare 682/tcp filtered unknown 730/tcp filtered netviewdm2 817/tcp filtered unknown 823/tcp filtered unknown 834/tcp filtered unknown 936/tcp filtered unknown 1440/tcp filtered eicon-slp 1532/tcp filtered miroconnect 1650/tcp filtered nkd 3269/tcp filtered globalcatLDAPssl 27003/tcp filtered flexlm3 Interesting ports on 172.16.200.241: (The 1650 ports scanned but not shown below are in state: closed) PORT STATE SERVICE 21/tcp open ftp 22/tcp open ssh 111/tcp open rpcbind 631/tcp open ipp 901/tcp open samba-swat 5800/tcp open vnc-http 5801/tcp open vnc-http-1 5900/tcp open vnc 5901/tcp open vnc-1 Interesting ports on 172.16.200.245: (The 1651 ports scanned but not shown below are in state: closed) PORT STATE SERVICE 21/tcp open ftp 23/tcp open telnet 80/tcp open http 135/tcp open msrpc 139/tcp open netbios-ssn 445/tcp open microsoft-ds 502/tcp open asa-appl-proto 1212/tcp open lupa Nmap run completed -- 256 IP addresses (3 hosts up) scanned in 126.950 seconds
This should narrow down the possibilities anyway.
Like someone else pointed out. Ping is a TCP/IP protocal / networking thing.
It would be like saying Windows HTML is different than Linux's HTML, or Windows Font is different that Linux's font.
I thought "Windows <anything>" was always different than "Standard <anything>," by definition. :) Kidding aside, that's what I believed to be true, as well. But as far as I can tell, from process of elimination, there is *something* different between the two. I'm no low-level protocol guru, but I ran an Ethereal trace just to look at the packet structure. For some reason, I couldn't see the packets passing between XP and the industrial box (the switch's fault?), but I recorded the ping requests between XP and SuSE, and this is what I got (apologies for the lousy formatting): From XP: 0000 00 40 45 12 91 c4 00 11 11 5b fe 4b 08 00 45 00 .@E......[.K..E. 0010 00 3c a2 f6 00 00 80 01 ad c2 ac 10 c8 f5 ac 10 .<.............. 0020 c8 f1 08 00 24 5c 02 00 27 00 61 62 63 64 65 66 ....$\..'.abcdef 0030 67 68 69 6a 6b 6c 6d 6e 6f 70 71 72 73 74 75 76 ghijklmnopqrstuv 0040 77 61 62 63 64 65 66 67 68 69 wabcdefghi From SuSE: 0000 00 09 0f 02 57 09 00 40 45 12 91 c4 08 00 45 00 ....W..@E.....E. 0010 00 54 00 03 40 00 40 01 50 a3 ac 10 c8 f1 ac 10 .T..@.@.P....... 0020 c8 f0 08 00 dc 13 ce 04 00 04 8b 92 90 43 44 0a .............CD. 0030 03 00 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 14 15 ................ 0040 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25 .......... !"#$% 0050 26 27 28 29 2a 2b 2c 2d 2e 2f 30 31 32 33 34 35 &'()*+,-./012345 0060 36 37 67 There is a visible difference, but decoding it is a little beyond my depth. From Ethereal, the two pings are different sizes, have different TTL, and different flags. That's about it.
I see from your next post, that you also tried switching IP addresses from XP to SuSE. That would eliminate the difference between subnets, gateways, or routing problems..... wait, maybe give the industrial box the IP of the XP machine. That was successful before. Then you will have eliminated the routing stuff. Which would leave one basic difference, like you also posted in the next message, that the packets are formed differently. Thinking that the protocol is supposed to be the same (regardless of OS or program making the packets, if done right), Maybe the difference is that the Linux box is implementing it "right" or "current". People complain often about Linux being behind windows in Destop GUI, Hardware Support, Etc. You'll often hear things like "It works with windows, So I know the hardware is OK. Well, this is simply NOT the case. Linux is far more "bleeding edge" than windows. You'll see OS support for "true" hardware / standards implementation FAR before you'll see them in windows. And if the hardware side isn't implemented to the standard, you won't find out about it until you load Linux on the box and let the newest drivers / technology talk to the hardware. A good example is 64 mobo's. Well, there was 64 bit Linux WAAAAAAAAAAAAAAAY before there was 64 bit windows. Some had a 64 bit board with windows loaded on it (32-bit) and then loaded Linux on it (64 bit) and things went bad. (BIOS not up to standards or something) Well, saying that it works in windows isn't accurate. Windows isn't taking full advantage of the hardware like Linux is. Same could be true in your situation. For example, if that industrial piece of hardware is older than your kernel version, the latest Linux kernel may be using a current standard "ping" packet (like with ipv6 stuff in it), where the windows box is still using the old stuff that isn't as bleeding edge. So when these types of problems happen, you can sometimes dumb Linux down to the level of windows to get something to work that windows can do that (bleeding edge) Linux can't. I'm not sure what would be newer with a ping packet. My assumtion would be something with ipv6 maybe? Can someone else on this list clarify? You might want to start checking what options you have for configuring the way the ping packets are constructed....... And dumb it down to the bare minimun (older standard) to give you the most chance of being as dumb as windows. hehehe Just a thought. B-) On Friday 02 December 2005 12:10 pm, David McMillan wrote:
Brad Bourn wrote:
ok, cable, windows box, industrial box are "known good"
Yep, verified several different ways.
Anyway, that is now also known good. (We don't need DNS, you know the IP).
The only question we have then is, "Is the SuSE box known good?"
So, I'll ask. Can you / Have you been able to ping anything with that box?
Oh, yes. Ping works fine across the the internet, on my home LAN, on the corporate intranet, and on various WiFi hotspots. Never any trouble.
Does it have internet access? (to test a ping like microsoft.com or your isp or gateway or something)
Can you Windows box ping the SuSE box? (does it answer?)
Hooked up all three machines on a small switch (definitely a switch, not a router -- I checked) to try more testing. XP and SuSE could not ping each other until I killed SuSEFirewall -- after that, perfect pings, both ways. XP could still ping Industrial, but SuSE couldn't.
Does the ping comand even work on the SuSE box? Can it ping itself?
Yep. # ping 172.16.200.241 PING 172.16.200.241 (172.16.200.241) 56(84) bytes of data. 64 bytes from 172.16.200.241: icmp_seq=1 ttl=64 time=0.169 ms 64 bytes from 172.16.200.241: icmp_seq=2 ttl=64 time=0.164 ms
Ran an nmap of the subnet: (SuSE is .241, XP is .245, Industrial is .240. Netmasks are all 255.255.0.0): Starting nmap 3.50 ( http://www.insecure.org/nmap/ ) at 2005-12-02 13:43 EST sendto in send_ip_raw: sendto(4, packet, 28, 0, 172.16.200.0, 16) => Operation not permitted Interesting ports on 172.16.200.240: (The 1641 ports scanned but not shown below are in state: closed) PORT STATE SERVICE 23/tcp open telnet 24/tcp filtered priv-mail 137/tcp filtered netbios-ns 273/tcp filtered unknown 334/tcp filtered unknown 517/tcp filtered talk 552/tcp filtered deviceshare 682/tcp filtered unknown 730/tcp filtered netviewdm2 817/tcp filtered unknown 823/tcp filtered unknown 834/tcp filtered unknown 936/tcp filtered unknown 1440/tcp filtered eicon-slp 1532/tcp filtered miroconnect 1650/tcp filtered nkd 3269/tcp filtered globalcatLDAPssl 27003/tcp filtered flexlm3
Interesting ports on 172.16.200.241: (The 1650 ports scanned but not shown below are in state: closed) PORT STATE SERVICE 21/tcp open ftp 22/tcp open ssh 111/tcp open rpcbind 631/tcp open ipp 901/tcp open samba-swat 5800/tcp open vnc-http 5801/tcp open vnc-http-1 5900/tcp open vnc 5901/tcp open vnc-1
Interesting ports on 172.16.200.245: (The 1651 ports scanned but not shown below are in state: closed) PORT STATE SERVICE 21/tcp open ftp 23/tcp open telnet 80/tcp open http 135/tcp open msrpc 139/tcp open netbios-ssn 445/tcp open microsoft-ds 502/tcp open asa-appl-proto 1212/tcp open lupa
Nmap run completed -- 256 IP addresses (3 hosts up) scanned in 126.950 seconds
This should narrow down the possibilities anyway.
Like someone else pointed out. Ping is a TCP/IP protocal / networking thing.
It would be like saying Windows HTML is different than Linux's HTML, or Windows Font is different that Linux's font.
I thought "Windows <anything>" was always different than "Standard <anything>," by definition. :) Kidding aside, that's what I believed to be true, as well. But as far as I can tell, from process of elimination, there is *something* different between the two.
I'm no low-level protocol guru, but I ran an Ethereal trace just to look at the packet structure. For some reason, I couldn't see the packets passing between XP and the industrial box (the switch's fault?), but I recorded the ping requests between XP and SuSE, and this is what I got (apologies for the lousy formatting):
From XP: 0000 00 40 45 12 91 c4 00 11 11 5b fe 4b 08 00 45 00 .@E......[.K..E. 0010 00 3c a2 f6 00 00 80 01 ad c2 ac 10 c8 f5 ac 10 .<.............. 0020 c8 f1 08 00 24 5c 02 00 27 00 61 62 63 64 65 66 ....$\..'.abcdef 0030 67 68 69 6a 6b 6c 6d 6e 6f 70 71 72 73 74 75 76 ghijklmnopqrstuv 0040 77 61 62 63 64 65 66 67 68 69 wabcdefghi
From SuSE: 0000 00 09 0f 02 57 09 00 40 45 12 91 c4 08 00 45 00 ....W..@E.....E. 0010 00 54 00 03 40 00 40 01 50 a3 ac 10 c8 f1 ac 10 .T..@.@.P....... 0020 c8 f0 08 00 dc 13 ce 04 00 04 8b 92 90 43 44 0a .............CD. 0030 03 00 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 14 15 ................ 0040 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25 .......... !"#$% 0050 26 27 28 29 2a 2b 2c 2d 2e 2f 30 31 32 33 34 35 &'()*+,-./012345 0060 36 37 67
There is a visible difference, but decoding it is a little beyond my depth. From Ethereal, the two pings are different sizes, have different TTL, and different flags. That's about it.
Odds are it has to do with the ICMP packet size. Linux's default data string for a ping packet is 56 bits, add that to the 8 bit header and you get a 64 bit packet of data. I believe that Windows sends out a data string 24 bits in length, add the 8 bit header and you get a 32 bit packet. Use the -s option to specify the packet size as 24 bits and see if that works. Your equipment probably discards all ICMP packets that do not have a total of 24 bits after stripping the header. Good luck. - James W
James Wright wrote:
Odds are it has to do with the ICMP packet size. Linux's default data string for a ping packet is 56 bits, add that to the 8 bit header and you get a 64 bit packet of data. I believe that Windows sends out a data string 24 bits in length, add the 8 bit header and you get a 32 bit packet. Use the -s option to specify the packet size as 24 bits and see if that works. Your equipment probably discards all ICMP packets that do not have a total of 24 bits after stripping the header. Good luck.
- James W
Someone here has really done their homework. Impressive. ~James
James Wright wrote:
Odds are it has to do with the ICMP packet size. Linux's default data string for a ping packet is 56 bits, add that to the 8 bit header and you get a 64 bit packet of data. I believe that Windows sends out a data string 24 bits in length, add the 8 bit header and you get a 32 bit packet. Use the -s option to specify the packet size as 24 bits and see if that works. Your equipment probably discards all ICMP packets that do not have a total of 24 bits after stripping the header. Good luck.
Well, it ended up being a wild couple of weeks, but I was finally
able to get back to the industrial system in question and try again.
Unfortunately, even changing the ping byte size didn't work. There's
definitely some kind of low-level structural difference between the
Linux and DOS pings -- I hubbed all three units (SuSE, XP, and
Industrial) and ran Ethereal to track pings in all directions. This
is what I got (using -s 32 on SuSE, and default on DOS):
SuSE ping to XP:
0000 00 11 11 5b fe 4b 00 40 45 12 91 c4 08 00 45 00 ...[.K.@E.....E.
0010 00 3c 00 02 40 00 40 01 50 b7 ac 10 c8 f1 ac 10 .<..@.@.P.......
0020 c8 f5 08 00 12 e7 bf 2a 00 03 7c 25 a7 43 11 91 .......*..|%.C..
0030 0c 00 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 14 15 ................
0040 16 17 18 19 1a 1b 1c 1d 1e 1f ..........
and XP's response:
0000 00 40 45 12 91 c4 00 11 11 5b fe 4b 08 00 45 00 .@E......[.K..E.
0010 00 3c ff 88 40 00 80 01 11 30 ac 10 c8 f5 ac 10 .<..@....0......
0020 c8 f1 00 00 1a e7 bf 2a 00 03 7c 25 a7 43 11 91 .......*..|%.C..
0030 0c 00 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 14 15 ................
0040 16 17 18 19 1a 1b 1c 1d 1e 1f ..........
Almost identical. But then there's XP-to-SuSE:
0000 00 40 45 12 91 c4 00 11 11 5b fe 4b 08 00 45 00 .@E......[.K..E.
0010 00 3c ff 76 00 00 80 01 51 42 ac 10 c8 f5 ac 10 .<.v....QB......
0020 c8 f1 08 00 3a 5c 02 00 11 00 61 62 63 64 65 66 ....:\....abcdef
0030 67 68 69 6a 6b 6c 6d 6e 6f 70 71 72 73 74 75 76 ghijklmnopqrstuv
0040 77 61 62 63 64 65 66 67 68 69 wabcdefghi
Same size, different structure. And SuSE's response:
0000 00 11 11 5b fe 4b 00 40 45 12 91 c4 08 00 45 00 ...[.K.@E.....E.
0010 00 3c 3c 45 00 00 40 01 54 74 ac 10 c8 f1 ac 10 .<
Some of the newer nic has autosense for the cable. Perhaps your windows machine has the autosense cable. Try a standard cable. David McMillan wrote:
Jerry Feldman wrote:
When Linux pings another host, it sends out the ICMP message and waits for a response. After some time it should time out. Check the default route.
No route. Just a crossover Cat5.
Here are some steps you should look at: 1. Make sure your cables are correct.
Used the same cable for the Windows and SuSE boxes.
2. run netstat -nr on your system. You should have a route to the subnet and a default route. Are you using DHCP or a static IP address? netstat should look sim,ilar to this.
Static IP. No routes, but I'll try netstat on it anyway next chance I get.
3. Are you using a name or an IP address to ping the equipment?
IP. The industrial box doesn't support named access, as far as I know.
-- Joseph Loo jloo@acm.org
On Thu, 2005-12-01 at 17:28 -0800, Joseph Loo wrote:
Some of the newer nic has autosense for the cable. Perhaps your windows machine has the autosense cable. Try a standard cable.
David McMillan wrote:
Jerry Feldman wrote:
When Linux pings another host, it sends out the ICMP message and waits for a response. After some time it should time out. Check the default route.
No route. Just a crossover Cat5.
Here are some steps you should look at: 1. Make sure your cables are correct.
Used the same cable for the Windows and SuSE boxes.
2. run netstat -nr on your system. You should have a route to the subnet and a default route. Are you using DHCP or a static IP address? netstat should look sim,ilar to this.
Static IP. No routes, but I'll try netstat on it anyway next chance I get.
3. Are you using a name or an IP address to ping the equipment?
IP. The industrial box doesn't support named access, as far as I know.
-- Joseph Loo jloo@acm.org
Just a comment, in linux it will automatically resolve the ip, in windows yo have run a ping -a Linux has a better ping... :) Chadley
Use ethereal to look at the packets. Indeed, use ethereal to see if the
ping is actually leaving the SuSE box; perhaps it has a freak
misconfiguration you've overlooked?
BTW, don't forget that ethereal snoops ports, so if you see something
come into your machine you're seeing it before the firewall gets at it.
So if you see a ping response in ethereal but you don't see it, then
the firewall probably killed it.
HTH
Cheers,
Simon
--- David McMillan
G'day, fellow SuSE users. I've got a puzzler concerning ping responses that I hope someone can enlighten me about.
I have a piece of industrial equipment that uses a TCP/IP Ethernet interface that I'm trying to troubleshoot at work. Part of the manufacturer's troubleshooting checklist is to "connect an DOS/Windows computer and use the PING command from the command line." Not having
a D/W computer handy, I plugged in my SuSE 9.1 Pro laptop, but couldn't get a response. Not even a "connection refused," just silence. After some fairly exhaustive troubleshooting, this is what we found: 1: A DOS ping command, from another computer, using the same IP and
netmask, over the same cable, got an immediate response. 2: The SuSE machine could not get a ping response, but *did* see the various open and filtered ports on the inustrial box, on the correct IP, when using nmap. 3: De/Re-activating SuSE Firewall made no difference. 4: The SuSE machine's ping command worked perfectly on a regular network, pinging Windows & *nix computers and various hardware routers without any difficulty.
All I can think of is that there must be some minor difference between SuSE pings (or perhaps Linux pings in general) and DOS/Win pings that doesn't matter to most networks, but *does* matter for some reason to this piece of industrial hardware. Thoughts?
-- Check the headers for your unsubscription address For additional commands send e-mail to suse-linux-e-help@suse.com Also check the archives at http://lists.suse.com Please read the FAQs: suse-linux-e-faq@suse.com
"You can tell whether a man is clever by his answers. You can tell whether a man is wise by his questions." Naguib Mahfouz __________________________________ Start your day with Yahoo! - Make it your home page! http://www.yahoo.com/r/hs
David McMillan wrote:
G'day, fellow SuSE users. I've got a puzzler concerning ping responses that I hope someone can enlighten me about.
I have a piece of industrial equipment that uses a TCP/IP Ethernet interface that I'm trying to troubleshoot at work. Part of the manufacturer's troubleshooting checklist is to "connect an DOS/Windows computer and use the PING command from the command line." Not having a D/W computer handy, I plugged in my SuSE 9.1 Pro laptop, but couldn't get a response. Not even a "connection refused," just silence. After some fairly exhaustive troubleshooting, this is what we found: 1: A DOS ping command, from another computer, using the same IP and netmask, over the same cable, got an immediate response. 2: The SuSE machine could not get a ping response, but *did* see the various open and filtered ports on the inustrial box, on the correct IP, when using nmap. 3: De/Re-activating SuSE Firewall made no difference. 4: The SuSE machine's ping command worked perfectly on a regular network, pinging Windows & *nix computers and various hardware routers without any difficulty.
All I can think of is that there must be some minor difference between SuSE pings (or perhaps Linux pings in general) and DOS/Win pings that doesn't matter to most networks, but *does* matter for some reason to this piece of industrial hardware. Thoughts?
There is no difference. Ping is ping. It's a standard ICMP message, which originated in the Unix world. It sounds like perhaps your interface isn't configured properly.
participants (9)
-
Brad Bourn
-
Chadley Wilson
-
David McMillan
-
James Knott
-
James Parra
-
James Wright
-
Jerry Feldman
-
Joseph Loo
-
Simon Roberts