Can anyone advise on the current status of this library?

[actiondannz]

Hi, this is not an issue as such so I apologise... I am committed to using this library and have the experience of the hang on some networks, and in an effort to resolve it over the last few months have come across the tmrh20 release. I am confused first as to where the current stable source is - is it here or the tmrh20 one, and also is that problem fixed or is this an outstanding issue?

If anyone could give their opinion on the status of this library and working with the Enc28J60 could you please let me know?

[TMRh20]

My opinion is there is an issue or issues but what exactly the problem is I don’t know. My fork was an attempt to fix it but I’ve given up on it. I think it is memory related, but not easy to figure out, plus the data sheet and corrections are confusing.

On Dec 18, 2017, at 18:58, actiondannz notifications@github.com wrote:

Hi, this is not an issue as such so I apologise... I am committed to using this library and have the experience of the hang on some networks, and in an effort to resolve it over the last few months have come across the tmrh20 release. I am confused first as to where the current stable source is - is it here or the tmrh20 one, and also is that problem fixed or is this an outstanding issue?

If anyone could give their opinion on the status of this library and working with the Enc28J60 could you please let me know?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[actiondannz]

Thanks for your response.

There are two branches, one is the ntruchsess branch, and one is your tmrh20 branch. Which one should be used? You've got quite a lot of changes in yours - do they have any impact?

With the exception of the module becoming permanently disconnected and needing a reboot to reconnect, the ntruchsess works. If yours does not solve the problem, is it better to simply use ntruchsess and implement some kind of reboot if it is not connecting?

I would appreciate your thoughts on it. Thanks!

[TMRh20]

My changes don’t seem to have an impact. Implementing some kind of reboot is probably your best bet.

On Jan 4, 2018, at 14:19, actiondannz notifications@github.com wrote:

Thanks for your response.

There are two branches, one is the ntruchsess branch, and one is your tmrh20 branch. Which one should be used? You've got quite a lot of changes in yours - do they have any impact?

With the exception of the module becoming permanently disconnected and needing a reboot to reconnect, the ntruchsess works. If yours does not solve the problem, is it better to simply use ntruchsess and implement some kind of reboot if it is not connecting?

I would appreciate your thoughts on it. Thanks! — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[jp-001]

Hi, I too am committed to using this library. In my opinion, it is the best choice for the enc28j60 adapter. Having said that, I have had some serious issues:

1. The enc28j60 becomes apparently disconnected resulting in failure on tcp_client.connect. This may happen because of power issues. Workaround: call "Enc28J60.init(mac_address)" before retrying the connect.
2. When a default gateway is used (on Ethernet.begin), tcp_client.connect will fail. Curiously, when this error occurs, UDP packets can still be sent and received across the gateway. Also, a very small percentage of client connect attempts will still succeed. Workaround: I just don't include DNS, Gateway and Mask on the call to Ethernet.init

I will try to spend some time trying to fix this but I'm confident that Norbert Truchsess will fix it for us.

[actiondannz]

Hi jp-001, The only outstanding issue that we have is that connecting to some switches simply does not work from the start. Just not working. We're not sure why this is but it's outstanding for us and not necessarily due to the library. Otherwise, you are not correct on the default gateway comment, it works fine. The problem will very likely be that you're not allocating enough time to maintain the ethernet connection. Basically, you have to poll the ethernet constantly as much as you can. If you spend any time in your code doing something else you have to poll the ethernet during that code. Otherwise, the packets build up unprocessed in a small buffer then are lost. Your UDP packets are arriving and being lost due to that. Call the polling function (forgot the name of it) constantly and you won't have that problem. The more busy the network with broadcast traffic the more you have this problem. The final thing is that when you initialise the ethernet you can tell the hardware what kind of traffic you are interested in and although you'd have to get into the code to find that, you can use that to make sure the module only looks at relevant traffic - we did not need to do that though. Make sure you're doing the needful on your side. The module does not have it's own tcp/ip stack. I'm leaving this comment here because others might find it helpful as well. Be confident with the library so long as it's up to date.

[jp-001]

Hi actiondannz,

Thank you for your attention. As I stated, my first issue is handled and does not constitute a concern at this point. I would research using an hardware interrupt to trigger the polling function you mentioned. The outstanding issue in my current case does not indicate a problem with a network switch but rather with the configuration of the gateway and network mask. Although the traffic I generate is entirely local, the inclusion of a gateway and mask parameters on the Ethernet.begin call somehow prevents the packets from being sent (I ran the capture at the enc28j60 end). Leaving out those two parameters makes everything work as expected. I don't know how relevant this is but the problem occurs only when I specify a 16 bit mask for my production network. When I run the system (including the two parameters) in my test environment, which is an 8 bit network, it works fine.

Anyone care to comment, please?

[actiondannz]

Hi - me again. This is news to me about the gateway and mask parameters for a 16bit mask. I would like to run a test but I am not sure if we can configure the 16bit mask - does that essentially mean that the network subnet mask is 255.255.0.0 ? In this case maybe our problem with a switch is actually related to this? If you could confirm that perhaps I can do some research here.

[jp-001]

Hi again, actiondannz.

First, it wasn't entirely accurate what I said about only having local traffic, I was sending UDP packets to an external address. Thus the reason for specifying a default gateway. TCP traffic was local. Yes, 16 bit network is 255.255.0.0 (16 = number of non-fixed bits). I looked though the uip-ethernet code and couldn't spot any strange code involving the netmask, but i wasn't very thorough. As in many projects, I really didn't have the time to go very deep. I was using the gateway/mask to be able to go outside the network and query an NTP server (udp). Now, I've modified my TCP server (Windows) to provide a timestamp when requested, which satisfies my needs without having to go across the router.

I'm hoping I can get one of the developers to look into these problems. What is the correct procedure to do this?

Thanks.

[globalcitizen]

@actiondannz

The only outstanding issue that we have is that connecting to some switches simply does not work from the start. Just not working. We're not sure why this is but it's outstanding for us and not necessarily due to the library.

Some switches expect traffic before functioning. In a static IP setup (vs. DHCP) this may not occur. Some switches expect the client to support VLAN election or explicit configuration. You can generally configure them to ignore this. Some switchports are MAC address locked.

FWIW I am using the ENC28J60 Ethercard library successfully. I am able to poll 100 times per second for over 1 week with stable response from an Arduino Nano HTTP server (using httping tool).

IMHO it seems this library is dead.