Timeline for How to debug an unstable connection in a P2P configuration
Current License: CC BY-SA 3.0
5 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Apr 3, 2018 at 7:26 | comment | added | Steven | As it turns out it was the coax connection. The bottleneck was the quality of the coax cable. The hardware was unable to transmit over such a long distance with the quality of coax we used. | |
| Apr 3, 2018 at 7:25 | vote | accept | Steven | ||
| Mar 15, 2018 at 11:51 | comment | added | Zac67♦ | A static ARP entry will only help if ARP is the problem (rather unlikely) - I rather suspect the C1-C2 transmission is unreliable. You can run e.g. iperf to produce and gauge traffic and monitor the switches/ports for anomalies (FCS, runts, ...). If the converter-converter link shows up fine the C2 device is pretty much what's left, possibly it has problems receiving traffic. | |
| Mar 15, 2018 at 8:15 | comment | added | Steven | Thank you for the response. I have found that the arp mapping has to be updated every five minutes or so, that explains why I see this coming up every now and then. Would a manually static arp entry help? What kind of tests could I do? Should I just check the number of packets being transmitted? And the problem could be the C2 device, in what way? It's justing emitting packets. | |
| Mar 14, 2018 at 19:59 | history | answered | Zac67♦ | CC BY-SA 3.0 |