Oh, interesting ... EtherSound.

This seems to be focusing on a modified hardware design. That can reveal interesting tidbits about Ethernet. But I want to find out what can be done with existing hardware in most PCs, laptops, netbooks, servers, etc. What I'm hoping is ethernet cards can do some degree of removing the MAC layer, such as promiscuous mode. PM might be essential if I can do significant changes to the MAC address.

I do want to get as much of that 100mbps speed as I can, so those serial-to-ethernet adapters won't be it. I want the data on that 100mbps signaling rate. I know I can't get around the framing (packets). I would have framing even if I designed something all new.

The framing itself wastes some time. I just figured if it can do raw promiscuous mode, maybe it can treat the first 14 bytes as raw, too. But in any case, I want to do it all in software to use existing hardware.

Is NETBEUI a solution? I am not familiar with the protocol, but I do remember it was very simple and non-routable. Hence overhead should be less? It is available for Linux.

jlinkels

I would think it still needs the MAC layer so it can send a frame to a specific host/NIC. If it is to be used on a LAN of 3 or more hosts, that's clearly needed (unless you provide your own addressing means ... but why do that when ethernet already provides one).

What I'm thinking about is strictly a point-to-point situation with exactly 2 "hosts" (one of them might be a raw device like a high speed D/A converter). Point to point does not need addresses to communicate (though in many cases it can be useful to know what has been connected). Such a device will already need ethernet framing logic. I'm just wondering if there is a way to avoid also needing to remove the 14 byte header since that's not needed in a point to point scenario.

But the objective is to design a device on one end that can be made to work with a computer on the other end that uses commodity ethernet hardware with just a software change.

The primary goal is NOT doing networking (so any network protocol makes no sense). However, an interesting secondary goal (if the first can be achieved) is to do a point-to-point network link without the MAC layer. That won't be much gain since there isn't a savings in hardware (both ends are ethernet). But if I can do this for the primary goal, I would also look at doing this for the secondary goal to see how that works.

Clear now.

Do you want to do this asynchrounous or synchronous? If it is asynchrounous, you would have quite some overhead in start/stop bits. If it is synchronous, you'd still have some overhead in signalling bits and so.

I wonder if there is some of the layer 2 logic implemented in the hardware of the chip. If so, that would make your plans impossible to realize.

jlinkels

Whatever ethernet does now. The PHY layer seems to be what I want to use. The MAC layer can get in the way and force insertion/interpretation of the 14 byte header. But if there is a way to configure the registers to let me set any of the 112 bits the way I want, and to ignore those bits and copy transparently on receive, it would to be doable.

If I were designing a PHY layer on my own, I'd do something quite different.

Studied a datasheet of the RTL8029. Very interesting.

As it seems, the MAC and PHY layer are connected to each other on the chip. Which renders your idea impossible. You simply cannot access the PHY layer. At least not in an RTL8029. But this is a very low level chip, chips used nowadays are even less likely to have the PHY layer accessible.

This might be an interesting document: ww1.microchip.com/downloads/en/AppNotes/01120a.pdf

jlinkels

For a reference, there are many ways to connect computers. The most common today is tcp/ip but the list includes stuff that has been out there for decades. Novell, Banyon Vines, DEC and a maybe 20 more come to mind. Almost all of them could be run on common nic cards. Most N2K cards and older DEC chips and SMC should have support for all the old stuff. Might look to an old communication form. We still use DEC stuff and Novell stuff. I see it on sweeps still.

OK, poor wording. I mean "access the PHY layer" by setting things so the MAC layer doesn't affect things. If the chip has a way to turn off the MAC layer, I'm done. If not, maybe some way to work around it can be done, like faking MAC addresses for send, promiscuous mode for receive (so it lets frames in no matter what).

"Use the PHY layer by itself by making the MAC layer transparent" might be better wording.

I could just not worry about the 14 bytes and send everything as a MAC broadcast, and every NIC would pass that to its driver.

The first idea is that ethernet in its point to point form is a "cheap commodity" way to deliver high data rates to external devices without modifying the computer hardware. The external device must still deal with ethernet framing. I would use some kind of framing even if I were designing a whole new signaling to begin with. But by sticking to ethernet framing, potentially an ethernet chip can be used in the device.

Potentially, USB can be used. But there are more complications to that. I like ethernet's simplicity.

I've also had the idea that since virtually all ethernet is now point to point to switches (or hubs), we really don't need its bus technology. We have a big frame switching technology, basically. We don't really need the MAC addresses if we can teach the switches to use the IP addresses instead. Transmitting a frame over a point to point link is basically saying "here, YOU have it now" where "you" is whatever is connected at the other end. How much do YOU use ethernet in ways that can't be done over IPv4 or IPv6?

No, it was not poor wording. I understood exactly what you meant, and we are talking about the same. Making an upper layer transparent is basically the same as accessing the lower layer. Still I am afraid it is not possible. I didn't study the RTL datasheet in depth (after all, it is your project ) but in my idea it is not possible. Ethernet chips are designed to do ethernet and seem to implement that. Since it also looked like the access of different chips is vastly different any solution would be very non-portable to any other NIC.

It just popped to my mind: might FireWire be an option for you? Interface cards are available and many laptops are provided with this interface. IEEE1394c is even designed for Ethernet cabling.

jlinkels

This is a reply to post #1, which I take it is an engineering project for next year. The idea of such projects, btw, is that you display your genius, novelty & skill like I will be trying to. You should credit helpful advice from members who contribute to your project (Steer you on/off ideas) in your final report.

You're failing feasibility here for doing it over software with unmodified hardware. Which headers are you dropping?
1.Ethernet header & trailer - necessary for routing and difficult to convince a nic not to send
2. IP header - difficult to use an unmodified driver without these.
3.udp(shorter than tcp)


What you want exists, and is out there in laptops. It's called firewire. You can go to fibre with that.

In the "computer connected to device" scenario, making hardware modifications really isn't an option. The objective is to be able to connect the device to almost any computer, especially laptops. So if you buy some new device, and it includes a new chip you replace your NIC's chip with (get out the soldering iron and the magnifying glasses), wouldn't you be a bit upset? I know I would. I don't want my laptop/netbook NIC to be modified.

The IP layer is pretty much a given to be modified, or just outright ignored. You can send anything you want as the ethernet payload. A raw socket does what one needs here. A replacement driver could do other means.

The MAC layer has issues. While software MUST be able to send to any MAC it wants to, there might be a few bits that are special and must be 0 or 1 for valid MAC. But FF:FF:FF:FF:FF:FF is certainly allowed and would be used if bypassing the headers can't be done, as that avoids the next issue. Getting the NIC to accept frames destined to any MAC might be hard. Promiscuous mode?

Getting rid of the type field could be harder.

So it is probably the case that the external device to be connect will just need to send destination and source MAC as FF:FF:FF:FF:FF:FF and I'm not sure what in the type field. Maybe FF:FF. Then after that, whatever I want goes (unless I'm doing IP, it won't be IP). For the external device receiving, it would skip the first 14 bytes and take the ethernet payload as the data.



What you want exists, and is out there in laptops. It's called firewire. You can go to fibre with that.[/QUOTE]

How to add that to a laptop with no extra dangling parts could be the issue. I've never seen a laptop, and only a few desktops, with built-in Firewire.

FireWire used to be pretty standard on laptops. My Lenovo T61 has one, which is by no means an exceptional machine. When I googled for the presence of FireWire interfaces on new laptops, it seems that it is still available, but mainstream disappearing in favor of USB 2.0.

So since FireWire is non-existent, USB too complicated, RS232 too slow, I think you are more or less sentenced to use the lowest layer of your ethernet network interface and implement a driver for each specific chip. Please report back how you proceed.

jlinkels

It does look like I'll be wasting 14 bytes. But even that is OK given that this makes use of a very commodity (cheap and everywhere) technology, however poorly it was done. But when ethernet was invented we didn't have the practical means to implement some of the more advanced line coding methods (so "poorly" is only today's perspective) we have today (even if we had known them back then). The cost of 14 bytes, especially for jumbo frames, is not that much.

I think you will agree that using the existing ethernet drivers and losing 14 bytes is more practical than implementing a suite of new drivers to gain that 14 bytes.

At least ethernet does let me get down to the PHY (line coding) level in a certain way. I can transmit all data as broadcast and a generic type. This way I won't need to know the MAC address of either end to transmit data, either by configuration or discovery. I just count the 14 bytes as part of all the framing overhead. That did not appear to even be possible in USB, and I suspect it could be a problem in Firewire.

Ethernet will let me send a frame with my payload even if nothing is on the other end (I just need to make the link appear to be in an up state). Legacy RS-232 will, too, with the right states on control lines (which are really a waste of conductor geometry). Can USB or Firewire do that?