[TriLUG] RAID notion applied to networking

Pete Soper via TriLUG trilug at trilug.org
Mon May 25 15:12:24 EDT 2020


    Wow. To use this I would only need something like a Raspberry Pi
      with WIFI to bridge the cell phone MyFi into a wired ethernet
      connection to a new router (turning the AT&T router into a
      simple source as in the diagram). I have a nice TP-Link router and
      a Raspberry Pi 3 that's felt neglected for a year or more. Whether my
      wife could get Microsoft Teams to work well enough on a Linux
      laptop that she could actually use this solution is the other
      question though. I guess Windows would just use one of the two
      router addresses as its default? 
    
    -Pete
    
    On 5/25/20 1:45 PM, David Brain via
      TriLUG wrote:
    
    
      This projects also looks like promising:

https://lstein.github.io/Net-ISP-Balance/

On Mon, May 25, 2020, 9:24 AM Pete Soper via TriLUG <trilug at trilug.org>
wrote:


      
        On 5/25/20 1:39 AM, Stephen P. Schaefer via TriLUG wrote:


        
          On 5/24/20 8:40 PM, Joseph Mack NA3T via TriLUG wrote:

          
            On Mon, 25 May 2020, Joseph Mack NA3T via TriLUG wrote:

          
          Ssh can do layer 2 tunnelling, and I see no reason in principle you
couldn't put bonding on top of that.  It is conceivable that ssh's
default compression might make up for the extra processing load, but
only experimentation would determine that.



        
        https://angrysysadmins.tech/index.php/2019/12/grassyloki/ssh-tap-vpn-using-ssh-to-create-a-layer-2-vpn-between-two-machines/

        
          The only warning is Kernighan's law: "Debugging is twice as hard as
writing the code in the first place. Therefore, if you write the code as
cleverly as possible, you are, by definition, not smart enough to debug

        
        it."

This really speaks to me, and explains a lot why I was miserable so much
of the time doing only software development. :-) Sometimes the "clever
as possible" is replaced by "problem space difficult as all get out".

In an earlier post there was mention of "long ago when dinosaurs roamed
in 1995". Well, about a generation before that I wrote and debugged an
HDLC implementation from scratch in TI 990 assembly language with no
other implementation as a reference. The spec doesn't come with reality
check remarks, starting with the detail that CRC CCITT could not detect
all the bit stream errors that occur in the real world with
standards-complying packets, no matter how hard you wanted it to. Of all
the code I wrote and debugged in my first career it was datacomm code
that I found the hardest. You mean a 32 bit CRC might not be adequate
for a TCP packet? Depends on whether you're using decent hardware or
using tin cans connected with a piece of string! With the 9600 baud
RS232 cable way WAY longer than spec that Steve Goldman and I had at
Ivey's in Charlotte, it was virtual cans and string and the two virtual
kids on each end were very occasionally hard of hearing. So in addition
to the HDLC spec my implementation had umpteen flavors of defensiveness,
with every more detailed sanity checking of the header fields and more
and more meta-protocol states. Ivey's was deliriously happy in the end,
but my next move was to stupidly join a datacomm startup. (Steve stayed
put and became a compiler writer and I rendezvoused with him three years
later with our roles reversed: he was the lead and I wrote back ends,
happy to let datacomm fade like a bad dream).

With that in mind, although both the Ubiquiti  edge router post and
Linux bonding posts are loud Siren songs, I feel like the custom eye guy
in "Blade Runner" these days, and  "I don''t know such stuff" as
debugging Ubiquity and bonding configurations as they interact with
modern Linux, I just do (other stuff). So I'll probably just show my
wife how to switch between the house router and her phone hot spot.

But this is a fascinating discussion!

Pete


        
               - Stephen


        
        --
This message was sent to: dbrain at gmail.com <dbrain at gmail.com>
To unsubscribe, send a blank message to trilug-leave at trilug.org from that
address.
TriLUG mailing list : https://www.trilug.org/mailman/listinfo/trilug
Unsubscribe or edit options on the web  :
https://www.trilug.org/mailman/options/trilug/dbrain%40gmail.com
Welcome to TriLUG: https://trilug.org/welcome

      
    
  


More information about the TriLUG mailing list