[root@ mail ~]# ping 10.35.2.77
PING 10.35.2.77 (10.35.2.77) 56(84) bytes of data.
64 bytes from 10.35.2.77: icmp_seq=0 ttl=255 time=2.11 ms
64 bytes from 10.35.2.77: icmp_seq=1 ttl=255 time=1.12 ms
64 bytes from 10.35.2.77: icmp_seq=1 ttl=255 time=1.22 ms (DUP!)
64 bytes from 10.35.2.77: icmp_seq=2 ttl=255 time=1.13 ms
64 bytes from 10.35.2.77: icmp_seq=2 ttl=255 time=1.22 ms (DUP!)
64 bytes from 10.35.2.77: icmp_seq=3 ttl=255 time=1.13 ms
64 bytes from 10.35.2.77: icmp_seq=4 ttl=255 time=1.12 ms
64 bytes from 10.35.2.77: icmp_seq=5 ttl=255 time=1.12 ms
64 bytes from 10.35.2.77: icmp_seq=5 ttl=255 time=1.22 ms (DUP!)
64 bytes from 10.35.2.77: icmp_seq=6 ttl=255 time=1.13 ms
64 bytes from 10.35.2.77: icmp_seq=7 ttl=255 time=1.12 ms
64 bytes from 10.35.2.77: icmp_seq=8 ttl=255 time=1.12 ms
64 bytes from 10.35.2.77: icmp_seq=9 ttl=255 time=1.11 ms
64 bytes from 10.35.2.77: icmp_seq=10 ttl=255 time=1.13 ms
64 bytes from 10.35.2.77: icmp_seq=10 ttl=255 time=1.22 ms (DUP!)
64 bytes from 10.35.2.77: icmp_seq=11 ttl=255 time=1.13 ms
64 bytes from 10.35.2.77: icmp_seq=12 ttl=255 time=1.13 ms
64 bytes from 10.35.2.77: icmp_seq=13 ttl=255 time=1.12 ms
64 bytes from 10.35.2.77: icmp_seq=13 ttl=255 time=1.21 ms (DUP!)
64 bytes from 10.35.2.77: icmp_seq=14 ttl=255 time=1.12 ms
I didn’t see a way to change my switch settings, so I tried direct cable connection between Hydra and my PC.
ethtool command shows that the only “partner advertised speed” is 10baseT/Half.
If I use ethtool to force auto negotiation OFF then I can set 10baseT/Full, but DUPs are still there.
Anyway I think that duplex half is not the problem, because just now I flashed very old GHI firmware and TinyBooter - v4.1.3.1. Speed is still 10baseT/Half, but no DUP ping packets with no matter if using direct connection or through switch.
Has someone seen a problem with no ping response from Hydra enc28 IP after long power on idle period? Like after leaving Hydra on for 2-3 days while connected to the LAN (via switch). By idle I mean no TCP communication with hydra.
The program running on Hydra is still responding (Glide project with CP7 lcd), but there is no ping to Hydra anymore. Normal power off/on or reset does not fix it (at least not immediately). Because of this I always thought that this is fault of our LAN switch. But now I get reports from customer who has the same problem.
To restore the ping and TCP connection to Hydra I usually disconnect the LAN cable, power off/on the switch, power off hydra for 1-2 minutes, then power on.
v4.2.6.2, but it’s not a new problem for me, I just didn’t pay much attention to it previously. Can’t say when it started. Not sure if it happened with the old NETMF 4.1 firmwares (was too long ago).
I get DUP pings with my Raptor/ENC28 as well. It hasn’t caused any real issues so I have not worried about it too much. I just figured it was due to half duplex being used. I really wish the driver was a bit more robust to allow you to control those type of settings.
Is it possible to change Hydra mac address from Windows command line?
I saw somewhere MFDeploy source code and was going to check if it’s easy to add such command line option to it, but maybe there is already something available?
Yes, you can but you have to write these wrapper class by self. Few days of work if start from scratch.
I haven’t seen any available software that support command line at this moment.
Customer found that executing several times the command nmap under linux:
nmap -v -sW hydra_ip_addr
sometimes leads to loss of ping to Hydra. Reset is needed to restore ping.
First I tried nmap under Windows 7 and did not manage to reproduce no matter now many times I ran nmap. After that I tried it under Ubuntu and indeed it happens - sometimes more nmap calls are needed.
To be sure that it is not related to the project I erased everything on Hydra - connecting the socket 3 pins for 5s at power on, then running “UpdateFEZHydra.bat” and flashing GHI firmware 4.2.6.2. I set static IP by using MFdeploy. Did not upload anything else. Only T43 display was connected to Hydra.
Here is terminal log:
On line 148 I stopped nmap, because it hanged.
Don’t know if this forcing of network problem with nmap is related to the other network issues the customer is having.