Transfer files over an Ethernet patch cable
maurycyz.com
maurycyz.com
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).
/looks longingly out the window, and catch my aging face in the reflection
With 1gig Ethernet it became a requirement, the definite end of existence for crossover cables.
Last time I used a crossover cable I was still using dialup, probably about 20 years ago. Once I had DSL I also had a router, so the crossover cable became redundant.
Although it is super easy to just pop the individual fibres out of the clip holding them together and flip them round.
The biggest polarity issue I see are with mtp/mpo cassettes, especially with multiple spans, you always seem to need to cross something there.
They always seemed a bit pointless, and died out with crossovers I suspect.
# ping all link-local devices on an interface:
ping ff02::1%eth0
I have two USB-C Ethernet adapters laying around that I bought some time ago. I connected one of them to a Linux machine and the other to my MacBook Pro and experimented a little bit.
All of the following commands and outputs are from the MacBook Pro. The USB-C Ethernet interface is en8.
On the macOS side, I can see that a 169.254.xx.xxx/16 IPv4 address has been assigned by macOS as there is no DHCP running on the link, and it has an fe80::xxxx:xxxx:xxxx:xxxx%en8/64 IPv6 address assigned by macOS as well. (The x-es in the aforementioned IPv4 and IPv6 addresses were put there by me in this text. On the system they are decimal and hexadecimal digits in the IPv4 and IPv6 addresses respectively.)
The first attempts, relating to ssh, maybe would not work on any system anyway? Not sure how the ff02 multicast prefix for link-local scope works exactly and what its limitations are.
% ssh ff02::1%en8
ssh: connect to host ff02::1%en8 port 22: Address family not supported by protocol family
% ssh -6 ff02::1%en8
ssh: connect to host ff02::1%en8 port 22: Address family not supported by protocol family
% ssh -B en8 -6 ff02::1%en8
ssh: connect to host ff02::1%en8 port 22: Address family not supported by protocol family
% ssh -B en8 -6 ff02::1
ssh: connect to host ff02::1 port 22: Address family not supported by protocol family
% ping ff02::1%en8
ping: cannot resolve ff02::1%en8: Unknown host
Finally, ping6:
% ping6 ff02::1%en8
PING6(56=40+8+8 bytes) fe80::xxxx:xxxx:xxxx:xxxx%en8 --> ff02::1%en8
16 bytes from fe80::xxxx:xxxx:xxxx:xxxx%en8, icmp_seq=0 hlim=64 time=10.893 ms
16 bytes from fe80::yyy:yyy:yyyy:yyyy%en8, icmp_seq=0 hlim=64 time=14.365 ms
16 bytes from fe80::xxxx:xxxx:xxxx:xxxx%en8, icmp_seq=1 hlim=64 time=0.511 ms
16 bytes from fe80::yyy:yyy:yyyy:yyyy%en8, icmp_seq=1 hlim=64 time=2.467 ms
16 bytes from fe80::xxxx:xxxx:xxxx:xxxx%en8, icmp_seq=2 hlim=64 time=0.440 ms
16 bytes from fe80::yyy:yyy:yyyy:yyyy%en8, icmp_seq=2 hlim=64 time=2.393 ms
^C
--- ff02::1%en8 ping6 statistics ---
3 packets transmitted, 3 packets received, +3 duplicates, 0.0% packet loss
round-trip min/avg/max/std-dev = 0.440/5.178/14.365/5.422 ms
Attempting to ssh to the IPv6 address from the ping6 output, making sure to pick the one that is not the IPv6 address of the ethernet interface that is connected on the MacBook Pro side itself:
ssh fe80::yyy:yyy:yyyy:yyyy%en8
So it seems that having ping6 ff02::1%en8 up the sleeve is useful indeed on macOS too, as long as one knows to use ping6 and not just ping, and that attempting to ssh to ff02::1%en8 does not work directly from macOS at least not for me.
You cannot ssh to a multicast address. More generally, you cannot set up a TCP connection to a multicast address. So that explains why your first ssh attempts failed.
And as you noticed, ping on macOS is IPv4 only, hence the "Unknown host" error, because it actually tries to resolve "ff02::1%en8" as a host name, it doesn't even recognize it as an IPv6 address.
You then ping6 the multicast address and get replies back from all nodes in the multicast group, which includes your MBP.
You then ssh to the link-local unicast address fe80::something, which finally works.
mDNS / Avahi is also great if the machine advertises itself: just use machinename.local after plugging it.
Though the interface needs to be configured for link-local addresses. In my experience, NetworkManager now periodically resets the link if it can't get a DHCP server to respond. I understand the rationale, but it used to be simpler to plug into a headless machine and be confident that you could just ssh in.
If only :)
This should work, but glibc has a bug where it doesn't support communicating a link-local scope ID in its name resolution subsystem. So you will have to first manually resolve the name, and then use the IPv6 LL address with scope ID directly.
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.
And talking about signals, dd(1) can show the amount of data it has processed as well as the throughput. The signal depends on the implementation(e.g. SIGINFO for MacOS, SIGUSR1 for GNU).
If you get away from BASIC commands and copy the tape routines up into RAM you can mess with the timing values, and with care you can get it from an average of 1800bps up to around IIRC 12000bps before things really fall apart. Probably with better interfacing you'd get even faster.
With more conservative values, this is how "speedloaders" worked. In the late 80s or early 90s one publisher released games on CD where it would load in the loader at normal rate then ramp up to some unholy speed that CD had the bandwidth and stability for but tape did not.
Used to play Duke Nukem 3D over a null modem serial cable.
In the days of the spectrum where you loaded via an analog audio input from a tape, and saved via the output, you could move from one to another in the same way, skipping the tape.
Apparently this was about 1kbit per second.
But if you were connecting two terminals directly with no modems, thus the modem was "null", you needed the cable to do the signal swap instead. Hence the name!
Configuring all this manually adds extra complexity when it seems that the goal is simply to connect up your cable and let 'er fly.
Occasionally we had someone who knew what they were doing and had their Windows 95 settings set up correctly, and then all we had to do was activate their room's Ethernet port and add their MAC address to the DHCP server's list of authorized MACs. But most often I or one of the other techs had to head down to the person's dorm room and set up their computer's network settings correctly before it would work. Once the 169.254 address was replaced by 192.168, my job was finally done. But there were times when that took some doing.
Because Quake multiplayer originally used IPX, not TCP. At least, that's why I had IPX loaded...
Also, why is he talking about "ethernet"? Its the IP layer, not the ethernet layer...
Not Warcraft though - some ancient DOS game.
It would still works today if both parties have a landline.
Two letters can have more than one meaning!
But "Ethernet/IP" is not just "two letters", is a trademarked brand.
https://www.odva.org/technology-standards/key-technologies/e...
For every standalone building that has a ground, that building also has an electrical potential. This potential is not necessarily the same between two neighboring buildings. When you stretch a copper line between them, you are tempting fate, electrically, not to mention the dangers of lightning strikes and the elements attacking that connection.
It is generally recognized that fiber optics are not only very efficient and durable, but also impervious to electrical troubles of the type that may plague inter-building connections. Simply grab switches or routers that support at least one fiber-optic connection, and link up!
Besides you worry too much. Entire cities were wired with cat5 hanged off steel cable between 9 to 15 story buildings in early 2000s, before fiber. Nothing burned down.
Unshielded cable is theoretically isolated at both ends but who actually knows with some chinesium equipment?
Because of this they were an early adopter of fiber-based networking. I remember being wowed by ATM over fiber running between closets at a blazing 155Mbps (with tons of 10BASE-T clients connected to FORE chassis switches).
+1 for fiber though. Long fibers are cheaper, SFP connectors and modules are commonplace and have become quite cheap. Just need to learn a few new things, such as simplex/BiDi vs duplex fiber, and multimode vs mono mode.
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?
Patch cables are outside of walls and designed to be moved around and plugged and replugged. They are terminated with 8p8c "male" connectors, commonly called rj45. Stranded cable is used because it's much more flexible.
edit: as for length, it depends. you won't get a gigabit over 150m of crap cat3, but you will get a link, even if it's 10 half-duplex.
My problem with the article was that "patch" doesn't seem to add any useful information. Unless he was using a restrictive definition intending to exclude things like crossover cables (which still work), he could have just as well said "transfer files over a blue Ethernet cable" with equal precision.
If he meant to say that at this point in time "you can use _any_ ethernet cable to transfer files directly between two computers", I think it would have been better to say that rather than appearing to add a restriction on the type of cable required.
In the 1990s I used crossover cable for years with Apple computers that I bought for music production
To keep the disk drives "clean", I never connected these computers to the internet
If I needed to transfer files to or from Apple computers I connected them to a laptop with crossover cable
I grew up using Apple computers that had no internet connection at home and school so this seemed perfectly natural
I used computers running Windows 3.11 that had no internet connection, only LAN
Needless to say, "Big Tech" companies like Apple are not what they used to be
These companies don't really produce anything to be used "offline" anymore. Watching the default network traffic from "Big Tech" marketed computers and software is sad
Not automatically trying to phone home is bad for the "business" of data collection, surveillance and ad services
There used to be a different attitude toward the internet; there was less trust. I can still find traces of this in the archives at textfiles.com
[1]Most people don't realise how much power ethernet consumes. Even 100Mbps ethernet consumes about 0.5W per port and it goes up with higher speeds.
python -m http.server
This isn't to say the way it's done in the OP is wrong, socat is also great, and you can also compress them on the fly by piping through zstd as others mentioned in this thread.
> as long as there's working IP connectivity.
Dont you need to be on a network to get 'IPs'. It is usually a router's job to setup the network, and also provision IPs.
Two devices, not connected to a LAN has nothing. No IP, except 127.0.0.1 and localhost. So then, how do you talk to another device. There isnt an address.
OP's article is essentially setting up a P2P connection when there's no third party (router)
# On sender...
ip address add dev eth0 fd42:dead:beef::1/48
ip link set dev eth0 up
# On receiver...
ip address add dev eth0 fd42:dead:beef::2/48
ip link set dev eth0 up
You only need a router set up to go to a different subnet. If both hosts are in the same subnet then it's just a neighbor resolution (well, you can do neighbor discovery manually too if you really want... but, since it's automatic, no reason too) followed by ethernet bridging.
Two hosts with nothing else just plugged into each other should actually already have assigned themselves IPs you could use for this though. They are known as IPv6's link local addresses and are explicitly meant for communication on the local subnet.
Ethernet & IP are fun abstractions to really get into the weeds about. When it comes to running networks it's actually a bit of a fight to try to make sure only the addresses the router allows can be used! A whole bevy of technologies address that for the different protocols.
https://git.kernel.org/pub/scm/linux/kernel/git/westeri/thun...
"Computer to computer should not be seen without a device in between (unless playing ROTT with your housemates)"
35 years ago maybe :) I had serial and parallel socket, and routerless networking happening on my home systems :)
Use cases? Emergencies and maybe dedicated backup.
> 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.
But also I'd feel weird if I didn't have at least one good flash drive somewhere, so anyone like me would already have it.
I'm going to ignore the part where the USB port described in the article sounds broken. A 100% functioning cable, especially a short one for a drive, is not hard to find.
Something like this should work:
ifconfig enX inet6 fd42:dead:beef::1 prefixlen 48
Then you can go ahead and transfer with socat to your other machine, even if it's a Linux machine. I tend to use nc but socat will definitely be faster.
Why the deadbeef network one might wonder? It's private space so won't conflict with public addresses.
That being said though, in 99% cases of big files I'll just airdrop the files!
AFAIK, "0xDEADBEEF" originated as a "magic number" in systems like IBM RS/6000 and Solaris, and it was a red-flag number! It meant something in your system was wrong and you'd better check it out!
https://en.wikipedia.org/wiki/Magic_number_(programming)#Deb...
Surely there are more pleasant, vegan hex strings to use, if you want to indicate an ephemeral IPv6 address?
Sexist, so thats out.
FACEB00C?
In use.
Darn this is hard.
Was I alone in expecting it to be used in an unconventional way?
Like, MAC level with not a trace of TCP/IP, or not even Ethernet but, say, uart over the wire.
In any event, I'd suggest rsync, webfs, python -mhttp.server or otherwise anything else than dd.
Carry a couple USB-C to RJ-45 dongles ;)
I'm ordering a dozen. Okay, maybe 3. But still, those look amazing.
It'd be super handy to have a wired failsafe while traveling without dragging an ethernet cable around for no reason.
Remove one cable and the network falls flat, or I thinking of another topology?
I do wonder sometimes how the world would be operating if IPX was the primary ethernet. I never got to play with it.
Haven't had any issues with them ever in regular use... So pointless even back then...
(, except if you lack an additional power slot or have no switch available)
Look at you with your fancy red Cat5 ;-)
But GigE uses all four pairs, so the hardware has transceivers behind all four pairs, which means even when they're running at 10 or 100, the chipset can choose which pairs to transmit and receive on. Thus all GigE adapters are Auto-MDIX, and it meant I no longer needed to carry a crossover cable, no matter what other device I was talking to.
It's funny how 10/100 cards with Auto-MDIX capability were exotic and expensive, but once GigE had it by default, it became ubiquitous, cheap, and quickly forgotten.
They'll think hard about a beautiful unrealistic idealisation of the problem, and/or treat a software abstraction as if it's the underlying reality, e.g. (of the latter) thinking networking starts with HTTP and languages start with JavaScript.
And by cheap, any $10 relic will do.
You’ll find their manuals very informative.
Now I still remember when target disk mode over ethernet was being talked about.
Wait there's more: a couple of simple plastic glasses joined with a string under tension also does the trick.
However more seriously, while being snarky about "obvious" things can be fun, we should all remember to acknowledge the xkcd's "Ten Thousand" effect as a very real law of life.
True in general, but Hacker News isn't a school for beginners to technology.
If you know more than others, that's great! but in that case please share some of what you know so the rest of us can learn. Here, for example, it could be possible to add related facts about networking, other ways of connecting computers, obscure details, war stories, bits of history - who knows? All such things could make the discussion more interesting and fun.
(Edit: here's a great example of what I mean. This comment is currently at the top of the thread, which is what we want here: https://news.ycombinator.com/item?id=49506392.)
By contrast, dyspeptic supercilious putdowns do no good, other than perhaps providing a temporary internal status hit (at others' expense).
https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...