<html><head></head><body>Ethtool reports up on electrical connection, not logical. So port sees voltage >0 on pin1,4 but logical state can be fubar.<br><br><div class="gmail_quote">On April 20, 2021 9:17:21 AM EDT, Derek Atkins via Ale <ale@ale.org> wrote:<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<pre class="k9mail">Hi,<br><br>On Tue, April 20, 2021 8:52 am, Phil Turmel via Ale wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;">I would not expect that layout to work except by chance.  With those<br>subnet masks, each box is free to send any packet to 172.16.x.y out<br>either interface at any time.  Specifying an interface for ping won't<br>prevent the other box from replying out the wrong interface.<br></blockquote><br>The routing table is set up such that they know where to send it.  The (a)<br>and (d) links have a single-host route on them but no network-route, so<br>the machines definitely know to reach each other via (b)/(c).  There is<br>nothing about "chance" here, it's basic IP routing (well, okay, advanced<br>IP routing).  But certainly nothing out of the ordinary, and stuff I've<br>done for 25 years.<br><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;">To be reliable, (b) and (c) need to be in the same subnet, and (a) and<br>(d) need to be in different subnets.   Not necessarily different subnets<br>from each other, but definitely different from the b/c subnet.<br></blockquote><br>That's not at all true.  It's all about the routing table and ensuring the<br>A and B know how to get to each other (via the b/c link).  I've done this<br>plenty of times before and it's worked just fine.  And indeed, this setup<br>was working just fine for a week or two before it suddenly stopped<br>working.<br><br>My leading theory right now is what Jim suggested, that the Ethernet<br>autoconfig is going into a tizzy because the two computers are directly<br>connected via a patch cable and not a crossover cable, and the r8129<br>chipsets are getting locked out which is preventing ARP replies.<br><br>Granted, if this WERE the case, I'm not sure why ethtool is reporting link<br>up, and there's nothing in the demsg log about the link going down.<br><br>I've suggested to the person I'm helping to put a switch between these<br>devices, even though it's adding yet another "thing" in there.<br><br>Thanks,<br><br>-derek<br><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;">On 4/19/21 1:06 PM, Derek Atkins via Ale wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #ad7fa8; padding-left: 1ex;"> HI.<br><br> I'm having a strange networking issue between two AWOW devices running<br> Linux that stopped talking to each other.  The devices are configured as<br> below:<br><br> --(a)[Box 1](b) ----- (c)[Box 2](d)--<br><br> Where:<br> (a) is 172.16.5.0/16<br> (b) is 172.16.5.1/16<br> (c) is 172.16.7.100/16<br> (d) is 172.16.7.0/16<br><br> The (b)/(c) link is a direct link between the devices, not a crossover<br> cable, and no switch.<br><br> The two devices were talking fine for a while and then all of a sudden<br> they stopped.  Now that won't talk at all.  When truing to ping .7.100<br> from Box 1, it sends out ARPs but there is no ARP response from Box 2.<br> Similarly, on Box 2 trying to ping .5.1 results in no ARP responses.<br><br> Both devices show the (b)/(c) link as up.  Running ethtool shows the<br> link<br> is detected.  However arp -an shows an incomplete response (no<br> surprise).<br><br> The dmesg output doesn't show anything.<br><br> I am at a loss. I don't understand how or why the two devices would stop<br> talking, and why neither will pick it up again.<br><br> Any suggestions for where to look or how else to debug this?<br><br> Thanks,<br><br> -derek<br><br></blockquote><hr> Ale mailing list<br> Ale@ale.org<br> <a href="https://mail.ale.org/mailman/listinfo/ale">https://mail.ale.org/mailman/listinfo/ale</a><br> See JOBS, ANNOUNCE and SCHOOLS lists at<br> <a href="http://mail.ale.org/mailman/listinfo">http://mail.ale.org/mailman/listinfo</a><br><br></blockquote><br></pre></blockquote></div><br>-- <br>Computers amplify human error<br>Super computers are really cool</body></html>