Main Site Documentation

Hydra and ENC28 lan module questions


#1

Hi, just two quick questions:

  1. 10Mb/s connection is expected?

  2. is it normal to have duplicate ping packets like:

[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

— 10.35.2.77 ping statistics —
15 packets transmitted, 15 received, +5 duplicates, 0% packet loss, time 14012ms
rtt min/avg/max/mdev = 1.118/1.201/2.117/0.214 ms, pipe 2

Hydra is running ethernet firmware v4.2.6.1 and TinyBooter v4.2.6.1.


#2

@ ovivo -

ENC 28 is Effectively 10MB/s, not more.

Concerning the duplicate ping, you can first verify on the switch where you’re connected if it is :

  • Autonegociating speed and duplex,
  • loosing packets (if manageable),

and then try to change params, such as forcing speed to 10Mb and duplex to full, and so on…Or even try another switch that support 10/100Mb…


#3

Thanks for the info, Louis.

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.


#4

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.


#5

If you are using DHCP, perhaps it is related to your IP lease expiring? Try renewing your lease once a day.


#6

I use static IP. Customer says they tried both static and DHCP with same result.


#7

@ ovivo - What version of the firmware are you using?


#8

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).


#9

Related to my first post - finally I found what leads to so many DUP pings (seen with linux ping).

It is when I use CP7 lcd and the flicker fix workaround:

Register LCDCON1 = new Register(0x00500800);
            uint val = LCDCON1.Read();
            val &= ~((uint)(0x1FF << 12));
            val |= (uint)0x1000;
            LCDCON1.Write(val);

#10

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.

Greg


#11

For sure the CP7 flicker fix is not the only reason for DUPs - I get them also without it, but a lot less. Here are 2 ping logs from same project:

with CP7 flicker fix:
https://drive.google.com/file/d/0B1zHz__652kNb2xXaGxlU0xJN0U/edit?usp=sharing

without fix:
https://drive.google.com/file/d/0B1zHz__652kNQ0Z0X282cGo1Sk0/edit?usp=sharing


#12

@ ovivo -

Try with softwareI2C for the CP7 driver to see what happen.


#13

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?


#14

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.


#15

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:
https://drive.google.com/file/d/0B1zHz__652kNVjZ1Y0F1Qmk5ZVk/edit?usp=sharing
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.