Would it be possible with today's crop of ethernet NICs to use then as serial ports for plain point-to-point communications, without the 14 byte header (e.g. just start sending the data payload)? This would mean any bit states would be possible in the space normally used for ethernet headers, sending and receiving. I'd also like to send rather large frames. I know there are jumbo frames being done now, so how far can that go when done in the raw?

Also, how tightly can I send multiple frames back-to-back where the physical layer is operating in full duplex (e.g. 100 mbps ethernet's physical layer)?

Not possible, and not very productive. Consider that a NIC adheres to the OSI standard, where the hardware (the physical layer as it is called) plays an important role in the communications.

What keeps you from using the serial port as it is? Unless your box does'nt have it (anymore)...

I think that it would'nt be worth the effort...honestly.

Thor

you can do that.
Just implement a TCP/IP stack on your own.

Hint: First three layers should be enough.
Design carefully the interface between layer three and four.

Hmm, would'nt that boil down to re-inventing sliced bread? I fail to see the usefullness...but, an interesting topic, I'm convinced.

That's for sure, Thor_2.0

But consider:
If people developing things like that, they are not likely to spoil real networks.

Touché

I'm interested to see where OP ends up with that...more in particular: the code (if any)...

Easier to use slip.

Not fast enough. I want to do up to 100 mbps (and more at some point). And how do you put it in a laptop?

The separate serial port would not be worth the effort. Besides, I don't know of any that can approach the 92 mbps I can get out of 100 mbps ethernet.

If the ethernet NIC can be made to not send those 14 bytes, or send them with my data instead, and receiving accordingly, then it simplifies my project. If not, then I waste 14 bytes in transmission bandwidth and have to make sure the other end won't cough on whatever is sent there. I'm hoping raw mode can somehow do this. If not, then I'll try it some other way.

So the SLIP developers have figured out how to tell the 100 mbps NIC card to skip sending and receiving the 14 byte IEEE 802.3 headers? All I need to do is look at the SLIP source and see how they get the NIC to do that?

I'm not specifically trying to use TCP/IP, although if I can make this work, I might try some form of point-to-point IP-over-thisweirdthing. What I'm trying to do is avoid wasting 112 bits that are useless for this, so that the ethernet point can be used as a framed serial link. Then it would be a matter of setting up a proper driver for it and create a device node so I don't have to pretend it's a network when it isn't.

Hmm, okay, now I'm getting an interesting picture. My bad, I did'nt know just what the goal was here....lemme think out loud here, but, is a 1000Mb/s card an option? I'd even dare to look into FDDI cards...fiber, ya know.

Edit
It can be done...if you'd write directly into the memory map of the card...but this would involve some machine code, a bit of protocolling from your part...and some time. But, now I do see some sunlight...am I allowed to "meditate" along side with you?

Thor

100mb/s is sufficient for now. Ethernet parallels over 4 twisted pairs with half-duplex for 1000mb/s. The 100mb/s is one pair for one direction, another pair for another direction.

But the big questions are:

1. Cost. A 100 mb/s serial card is likely intended for serial connectors and other things like getting clocking from a modem. Serial tends to not come self-clocked.

2. Doing it on a laptop.

Sure, mediate.

I'm just seeing a cheap way to serialize data using twisted pair ethernet. It would be cleaner if I can get rid of those 14-byte headers, too. Otherwise I'd have to put something in there that always works no matter where connected, and that can be hard, too. For example should I read in promiscuous mode? Send with broadcast addresses to be sure the other end will get it?

I THINK this is just a case of trying to get the PHY layer by itself.

I'm wanting to explore how I can make devices that need a lot of data and connect them into computers. I really don't want the mess that is USB or the mess that is Firewire (I was kinda expecting someone to suggest USB in this thread). I'm thinking about some audio and/or video devices.

But I did also think of trying raw IPv6 over this, too, on a point-to-point basis. Since this would not be ethernet, anymore, the IPv6-over-ethernet rules won't apply. There would be no IPv6 type code this way ... it would just be assumed IPv6. And that could only work point-to-point since a switch would not handle it (unless I redesigned the switch firmware to become an IPv6 router).

What's interesting is that no one really uses what ethernet was designed for on a physical basis, anymore. We simulate a bus network with hubs and switches.

That small amount of overhead is nothing.

If you knew enough about a specific card and you also knew that you could write a new driver that did what you want, you then might be able to get it to allow you to write some new network stack or add to a stack to allow this.

You will never get this working since you ask. I played with this a very long time ago and I can assure you there is a lot going on.

I suggested the most easy solution. Use slip.

The second most easy way is to get a specialized card. These cards are like universal communication cards. They tend to be a very specialized device for some special uses. One buys this card and then programs it to do what they want. We used to have small 386 processors on the board that would basically be a small embedded OS. Then you selected the communication method, you then connected the special connector to the back to allow the correct pigtails. IBM and some other companies have made them.

Agreed. But it's the principle of the thing. If it CAN bey removed, I want to.

How about just my specific data stream? Maybe I don't want to do a network stack.

What about forcing specific header contents? Maybe I can't set the source MAC, but can set the destination MAC to some arbitrary bit pattern?

SLIP over ethernet? What's that get me?

Ethernet is ubiquitous. It's commodity. And it's built in, in so many places. Anything else is just too expensive (whether I can get those 14 bytes out or not).

Forget slip. It is backwards from what you want.

Peek that this for some clues. http://electronics.stackexchange.com...with-no-encaps