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).
It would be nice if this article defined a "ethernet patch cable". I think he's just using "patch" as a slang term for a short cable and it actually works with any length of standard cable, but I'm not certain.
Traditionally (pre-2000?), one had to use a special "crossover cable" to do direct connections like this, but apparently modern Gigabit ethernet adapters are able to detect this situation automatically?
https://en.wikipedia.org/wiki/Medium-dependent_interface#Aut... is what allowed the switchover to happen automatically, and it got folded into the 1000BASE-T standard. So yes, crossover cables are no longer required because the two Ethernet adapters at either end can negotiate between them to have one of them "flip" the meaning of its Receive (RX) and Transmit (TX) pins.
Back in the day you needed a modified cable for this with RX/TX swapped on one end but nowadays probably all nic chips have auto-detect so you can take a normal patch cable and do it.
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.
For the time spent finding the ethernet adapter, plugging the cable, configuring IP addresses, and testing with pings, any decent portable SSD drives should have finished copying tens of GB of data.
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.
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).
That wasn't that long ago was it..?
/looks longingly out the window, and catch my aging face in the reflection
It would be nice if this article defined a "ethernet patch cable". I think he's just using "patch" as a slang term for a short cable and it actually works with any length of standard cable, but I'm not certain.
Traditionally (pre-2000?), one had to use a special "crossover cable" to do direct connections like this, but apparently modern Gigabit ethernet adapters are able to detect this situation automatically?
https://en.wikipedia.org/wiki/Medium-dependent_interface#Aut... is what allowed the switchover to happen automatically, and it got folded into the 1000BASE-T standard. So yes, crossover cables are no longer required because the two Ethernet adapters at either end can negotiate between them to have one of them "flip" the meaning of its Receive (RX) and Transmit (TX) pins.
The way I learned this, is that patch cables use stranded wires, but ethernet cables use solid wires.
IIRC crossovers are pre-2000, yes. "Fast Ethernet" or 100Base-T adapters usually could talk over straight link.
People discovering that network cables can be used to network things. And then calling it a "trick" (I'm surprised it's not a "hack" actually).
If you're used to a "normal" network with a router, it's a revelation that you can go direct.
Back in the day you needed a modified cable for this with RX/TX swapped on one end but nowadays probably all nic chips have auto-detect so you can take a normal patch cable and do it.
Yeah, I remember those. When setting up an ad-hoc network, you were like; "where the eff is the crossover cable!" :D
it was the red one, right?
Mine was just a custom made gray one, but I have seen those red ones, yes :D
Yeah so called crossover cables. But that's like decades ago.
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.
I am 95% confident you don't actually need to assign IPs. Do this:
And then do your socat/rsync/whatever to the only IP that responds.For the time spent finding the ethernet adapter, plugging the cable, configuring IP addresses, and testing with pings, any decent portable SSD drives should have finished copying tens of GB of data.
As the article says,
> Removable storage is quite slow unless you are willing to spend a lot of money.
An SSD good enough to copy tens of GB quickly is not cheap.
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.
I remember we played warcraft 2 over ~15m of cat3 cable stretched outside between two flats on 6th floor. Those were the times, lol.