Hi,
we have custom PCB based on G400-S with Ethernet connection(more less copy of GHI ENC28 module). This PCB has also possibility(Gadgeteer connector) for direct connection of GHI Wifi RS21 module (thus also GHI ENC28 module).
We are facing quite strange behaviour:
When this PCB is connected through external GHI Ethernet ENC28 module (through Gadgeteer connector) to the TP-Link router provided connection to Internet(cable and also Wifi connection possible) by cable then it is possible to ping(from Windows Wifi host by standard ping xx.xx.xx.xx command) that PCB without any problem.
When this PCB is connected through internal PCB Ethernet connector with ENC28 chip (it is more less copy of GHI ENC28 module) to the TP-Link router by cable then after ping (from Windows host by standard ping xx.xx.xx.xx command) we receive: Reply from yy.yy.yy.yy: Destination host unreachable.
where yy.yy.yy.yy is Windown host IP.
If another simple Ethernet switch(Gembird) is inserted between that custom PCB and TP-Link router then again ping from Windows host is OK. Here only difference is that one extra Ethernet switch is inserted between PCB and TP-Link router.
We have tried both Ethernet cables(crossed and also non-crossed) and the result is always the same:
ping to that PCB with GHI ENC28 Gadgeteer module works without another extra Ethernet switch inserted between PCB and TP-Link
ping to that PCB with connection through internal solution (more less copy of GHI ENC28 Gadgeteer module) works only with another extra Ethernet switch inserted between PCB and TP-Link.
Application software is always the same - we have also tried static IP and DHCP configuration with the same result.
Do you have any idea why our solution with internal ENC28 chip only works with another extra Ethernet switch in between while connection with GHI ENC28 Ethernet module works normally without extra switch?
(My colleague (responsible for HW) already checked schematic because we though that cable signal are switched and extra Ethernet switch swapped them automatically but it seems this is not the reason.)
Do you change the MAC address in these runs? I suspect there might be a switching layer thing going on and the TP-Link either doesn’t like the second MAC address you’re using for the non-module test, or it still has an ARP table entry for the old MAC address on that IP address and it’s not seeing the new device. Try resetting the TP-Link device in your non-working scenario and re-start your test, see if that changes behavior.
@ Gus - Not sure about exact number of Ethernet mag.- I have to ask my colleague but he said he noticed you have some special one with swapped pins or so if I understood correctly (maybe custom one) and as far as I know he also tried to use exactly the same you have but the result was the same.
@ Brett - Not sure if MAC addresses are different, but probably yes.
So what is your suggestion? Should I try to use the same MAC addresses for both tests or should I change MAC addresses so they are different for external ENC28 and internal one?
I am not an expert in these things, I have only basic knowledges about Ethernet things including ARP tables etc.
you should use unique MAC addresses in both scenarios. If you use unique MAC addresses, make sure they’re from valid address pools that can be routed correctly.
@ Brett - I use FEZ Config to “generate” MAC addresses. I thought it is enough to have only all MAC addresses different. Is there also any other rule for MAC addresses range like IP mask?
I don’t know what algorithm Fez Config will use to generate MAC addresses. I have seen some non-enterprise routers not work with specific “faked” MAC addresses, and it’s possible your scenario is like this, which is why you should try other MAC addresses. Perhaps try a couple of random ones from http://www.macvendorlookup.com/
I changed MAC address and also IP address(we use fixed static address), reset TP-Link router and result is still the same:
if directly connected to TP-Link then response to ping from Windows PC host is still “Reply from yy.yy.yy.yy: Destination host unreachable.”
if connected to another Switch(Gembird SN-5P) first and Gembird switch is connected to the TpP-Link router then ping from host PC is OK
This is very strange and I do not understand it. My colleague will try to make different PCB layout for all PCB Ethernet stuff and use the same Ethernet mag. like GHI uses, hope it will help…
Hi again,
my colleague has finished new PCB version and the issue is still here.
This is quite important commercial product and we are still facing the same problem:
1) We are not able to connect to the Ethernet from our embedded ENC28 based on our PCB(with G400-S) through main TP-Link router providing internet connection. - this is of course our preferred solution.
2) but we are able to connect if another simple Ethernet switch(Gembird) is placed in between our embedded ENC28 module and main TP-Link router - this is of course not acceptable for our customer.
We are also able to make connection if we use external GHI ENC28 Ethernet module - instead of embedded ENC28 - connected through Gadgeteer connector SX-X44 with S1.3 set to ON directly to the TP-Link - SX connector is here for future to make WiFi connection and is not supposed to be used for external ENC28 module as we have embedded ENC28 of course.
We use static IP address(but the result is the same if DHCP is used). We have also tried to generate different MAC addresses and resets TP-Link router a lot of time without any success. Also different router(not TP-Link) was used with the same result(including crossed Ethernet cable).
so I hoped this is OK, but now I can see there is written 49.9k. I will contact him regarding this potential issue(it will be nice if the resistor values will solve this problem ).
Unfortunately I think all you’ve done is confirm exactly where the problem lies - in your custom board. Another commercial ENC module works -> problem with your implementation. You may find the resistor issue will solve it, as the reason the intermediate switch is helpful will likely be the tolerances the router and the switch are sufficiently different that the resistor value becomes unimportant.
But, it all just confirms to me, the solution is going to be found in your hardware.