<html><head></head><body>Yep. That's the state of the connection on it's end.<br><br><div class="gmail_quote">On April 20, 2021 10:36:21 AM EDT, Derek Atkins <derek@ihtfp.com> 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">Gotcha. That makes sense. Would it still report 1000Mb Full Duplex if<br>it's fubar?<br><br>-derek<br><br>On Tue, April 20, 2021 10:32 am, Jim Kinney wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;"> Ethtool reports up on electrical connection, not logical. So port sees<br> voltage >0 on pin1,4 but logical state can be fubar.<br><br> On April 20, 2021 9:17:21 AM EDT, Derek Atkins via Ale <ale@ale.org><br> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #ad7fa8; padding-left: 1ex;">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 #8ae234; 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<br>(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,<br>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 #8ae234; padding-left: 1ex;">To be reliable, (b) and (c) need to be in the same subnet, and (a)<br></blockquote>and<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #8ae234; padding-left: 1ex;">(d) need to be in different subnets. Not necessarily different<br></blockquote>subnets<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #8ae234; padding-left: 1ex;">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<br>the<br>A and B know how to get to each other (via the b/c link). I've done<br>this<br>plenty of times before and it's worked just fine. And indeed, this<br>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<br>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 #8ae234; 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 #fcaf3e; padding-left: 1ex;"> HI.<br><br> I'm having a strange networking issue between two AWOW devices<br></blockquote></blockquote>running<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #8ae234; padding-left: 1ex;"><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #fcaf3e; padding-left: 1ex;">Linux that stopped talking to each other. The devices are<br></blockquote></blockquote>configured as<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #8ae234; padding-left: 1ex;"><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #fcaf3e; padding-left: 1ex;"> 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<br></blockquote></blockquote>crossover<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #8ae234; padding-left: 1ex;"><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #fcaf3e; padding-left: 1ex;"> cable, and no switch.<br><br> The two devices were talking fine for a while and then all of a<br></blockquote></blockquote>sudden<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #8ae234; padding-left: 1ex;"><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #fcaf3e; padding-left: 1ex;">they stopped. Now that won't talk at all. When truing to ping<br></blockquote></blockquote>.7.100<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #8ae234; padding-left: 1ex;"><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #fcaf3e; padding-left: 1ex;">from Box 1, it sends out ARPs but there is no ARP response from Box<br></blockquote></blockquote>2.<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #8ae234; padding-left: 1ex;"><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #fcaf3e; padding-left: 1ex;"> 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<br></blockquote></blockquote>stop<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #8ae234; padding-left: 1ex;"><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #fcaf3e; padding-left: 1ex;"> 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><br>--<br> Derek Atkins 617-623-3745<br> derek@ihtfp.com www.ihtfp.com<br> Computer and Internet Security Consultant<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></blockquote><br> --<br> Computers amplify human error<br> Super computers are really cool<br></blockquote><br></pre></blockquote></div><br>-- <br>Computers amplify human error<br>Super computers are really cool</body></html>