Birbla

Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

Sign in
  • Hacker News
  • It seems a strange choice, for the demo and for the script, to manually configure addresses on both ends. If your TCP/IP stack is functioning properly, this will not be necessary. Once DHCP fails, you should get a pair of 169.254.0.0/16 (APIPA) addresses, and then Bob's your uncle.

    Configuring all this manually adds extra complexity when it seems that the goal is simply to connect up your cable and let 'er fly.

    by ButlerianJihad
  • "Plug two computers into each other with a network cable and staticly configure the IP addresses" should not be a novel or notable enough idea to trend on HN! This is boggling.
    by theodric
  • I literally had to cross over the cable once. It was some sort of demo and the cross over cable was missing. The local computer stores didn’t have one and under the time pressure … I have used the pocket knife and convert the cable. It was before 2000 so the speed was limited to 10/100 Mbit - ifconfig did’t report errors and demo went smooth.
    by awruko
  • This remind myself the good old 8bit days of using a cross-over RS232 cable to send a file from one computer to another. even at 30bps, it was much more reliable than write my data to a cassette tape on one computer and then reading on the other.
    by yitchelle
  • I wonder how we managed to invent the Internet before this trick. Next week's front page will be "Amazing trick: connect two wheels with a platform and you can ride instead of walk"
    by brandolini10x
  • You can also pipe it through zstd on the fly, for data that compresses well you'll often see 1.5 to 3× the raw throughput, so a gigabit link can effectively move 165–330MB/s.

    Receiver: socat -u TCP6-LISTEN:1234,reuseaddr STDOUT | zstd -d -c | tar -xpf - -C /destination

    Sender: tar -C /source -cf - directory | zstd -T0 -6 -c | socat -u STDIN 'TCP6:[fd42:dead:beef::2]:1234'

    -T0 uses all cores. Bump the level above -6 for more compression, drop it for more speed, but if your CPU can't keep up, high levels will actually slow it down. Already compressed data won't see much benefit.

    by SillyUsername
  • I am 95% confident you don't actually need to assign IPs. Do this:

      # ping all link-local devices on an interface:
  ping ff02::1%eth0
    And then do your socat/rsync/whatever to the only IP that responds.
    by yjftsjthsd-h
  • That used to require a crossover cable; I've done precisely that (with a crossover cable) back before https://en.wikipedia.org/wiki/Medium-dependent_interface#Aut... became widespread. With a straight-through cable, you'd be connecting the Transmit (TX) pin of one adapter to the TX pin of the other one, and the Receive (RX) pin of one to the RX pin of the other — and neither device would "hear" the messages the other one was sending. A crossover cable flipped those wires, so each device's TX pin was connected to the RX pin on the other end, and both devices could "hear" each other.

    But with auto MDI-X, each device would notice "hey, I'm sending but not receiving anything," and would try flipping its Transmit and Receive functions around (transmitting on the RX pin and receiving on the TX pin). Since each device waited a random period before doing that, it was very unlikely (nigh-impossible) that they would both flip at the exact same moment. And if they did, the second interval would most likely not be identical either.

    I'm simplifying a bit in the explanation above, but that's the broad strokes. And that's how my carefully-labeled crossover cables started gathering dust. (And then I realized "hey wait, I can just use these as normal cables now", and pulled them back out of storage and mixed them with my normal patch cables).

    by rmunn

Explore Birbla archives