Re: port-amd64/56844

[Robert Elz <kre%munnari.OZ.AU@localhost>]

The following reply was made to PR port-amd64/56844; it has been noted by GNATS.

From: Robert Elz <kre%munnari.OZ.AU@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: ocb%l25.fi@localhost
Subject: Re: port-amd64/56844
Date: Thu, 19 May 2022 22:11:01 +0700

     Date:        Wed, 18 May 2022 21:15:01 +0000 (UTC)
     From:        ocb%l25.fi@localhost
     Message-ID:  <20220518211502.0136F1A923A%mollari.NetBSD.org@localhost>
 
 First, no matter how badly you misconfigure the
 network, NetBSD should not hang/crash, so it looks
 as if something should be investigated here, and fixed.
 
 But you should be easily able to avoid the issue
 by configuring things properly.
 
   |  All devices named below are physical devices.
   |  
   |  192.168.88.1 - mikrotik router
   |  192.168.88.2 - mikrotik antenna connected to PoE port 10 on the router
 
 If the router is really a router, and not a switch (or a switch
 with some routing abilities) then that config is wrong.  In IP
 networking, each link should have its own network number.
 That is, for a device on each link, the IP addr anded with
 the netmask should produce different answers for each link.
 The router interfaces should have an address on each link
 (some point to point links can avoid having network addresses
 at all, but that is a different issue).   In the cases where
 this is not possible, the router must fake it, by pretending
 to be all the devices on one link to devices on the other
 link, and forwarding packets between them (which does not
 work for all protocols)
 
 Routes must always name a destination on the same link as
 the sending device (the one with the route) IP uses hop
 by hop routing, all anything ever does is send packets one
 hop closer to the destination.   It makes no sense to
 specify a next hop for a route which is not on the same
 link as the sender, at best it would mean that every packet
 sent would need to lookup the first route, and then upon
 discovering that the destination is not local (the next
 hop must be a destination we can send to directly) look
 up another route to see where to instead of where the
 first route directed things.  Better to avoid doing that
 for every packet, and instead do it once when installing
 the route.
 
 So, in this case the default route should be 192.168.88.1
 
 
 If the "router" is really a switch, then it has essentially
 no role in IP level packet forwarding at all.  It can have
 ad address (usually does) for admin/stats/... which is best
 viewed as a host connected to the switch.
 
 In that case the default route should be to 192.168.88.2
 and 192.168.88.1 should never be used for anything related
 to routing.
 
 Some devices are both switch and router, those are best
 considered as 2 separate connected devices, if you're on the
 same logical network as the destination you are using the
 switch and the router is not involved.  If you are using
 the router the destination should have a different network
 number, and the route to that network will reference the
 router's address on our network.
 
   |  Network configuration was made according to ifconfig.if(5),
   | and all network connectivity with local devices and remote hosts
   | works as expected.
 
 IP networking can be remarkably resilient.   Lots of things
 often seem to work, when perhaps they shouldn't.
 
 
   |  dc$ cat /etc/ifconfig.wm0
   |  up
   |  inet 192.168.88.252 netmask 255.255.255.0
   |  !route add 192.168.88.2 192.168.88.1
 
 that route with that netmask can never be correct.
 If we know how to reach ...1 (which that implies
 we must) then we know hiw to reach ....2 as that
 is on the same link.
 
 If it isn't on the same link its addr should be changed,
 or the router must do proxy arp for it.
 
   |  dc$ cat /etc/rc.conf | grep -E 'defaultroute'
   |  defaultroute="192.168.88.2"
 
 That is fine if ....2 is on the same link as the
 host, and wrong otherwise.   The next hop must be
 on the same link.  Always.  Otherwise it is not a
 "next" hop, but something later.
 
 
   |  The reason I add '192.168.88.2 192.168.88.1' route is so
   |  that a tap interface (behind 192.168.88.252 which is acting
   |  as hypervisor) from network '192.168.50.0/30' can reach
   |  '192.168.88.2'
 
 Things on 195.168.50/24 should reach devices (any devices)
 on 192.168.88/24 via a route to the router on their local
 link, which will be 192.168.50.xx and be the address on
 the netbsd (base) host for that network.  For this the
 netbsd system is the router (anything which forwards
 packets fron one IP network to another is a router).
 
   |  ICMP Redirect from  for ICMP Echo sent to 192.168.88.2
 
 That suggests to me that the "router" (196.168.88.1) is
 being sent a packet for 192.168.88.2 and it is telling
 you to stop bothering it, send directly to 192.168.88.2
 instead.   That suggests the "router" is acting as a switch,
 not a router (ignore what vendors call their products,
 they call them whatever they think sells best).
 
 NetBSD is probably reacting to that by adjusting the
 route destination from ...1 (you told it) to ...2
 (which ...1 told it).
 
 Now we have a route pointing to itself, which is a perfect
 candidate for infinite loops.
 
 Get the networking config correct, and all these issues will
 simply vanish.
 
 NetBSD probably could do with some improvements, but avoiding
 misconfig errors by the root user typically simply reduces
 flexibility.
 
 kre