How to implement an ethernet modem

558 Views Asked by At

Okay, what I want to do, as a training exercise, is to implement something like this

client --ethernet--> Modem1 --GPIO--> Modem2 --ethernet--> My Home Router

Where the client connects to Modem1 using an ethernet cable.
Modem1 is a Raberry PI, converting the signal and relaying it via the GPIO
Modem2 is a Raberry PI, receives the data from the GPIO, and send it via the ethernet cable to my home router

I want to implement the Modems, but have little idea where to start.

I have read up a little on ethernet programming, but still can't find answers to the "simple stuff" like.

  1. How do I implement Modem1 so that when its connected to the client, the client discovers it as an internet connection.

  2. On the Modem2 end, how do I make "My Home Router" send packets meant for the "client" to Modem2, so that Modem2 may forward them.

and possibly things I haven't though of....

So, how, concretely, can I implement this? preferably in c.

1

There are 1 best solutions below

4
On BEST ANSWER

I'd venture to say you might be able to write some sort of custom GPIO intermediate layer.

Read Ethernet->Encapsulate->Write GPIO->|->Read GPIO->Decapsulate->Write Ethernet

(and vice versa)

The problem then becomes: How can both modems act as "Ethernet proxies"?

Modem1 acts as a proxy for the router. Modem2 acts as a proxy for the client. If your Raspberry Pi can spoof MAC addresses, you might be able to fool Ethernet peers into communicating with your modems' Ethernet port. The reason why you need to spoof MAC addresses is that in TCP/IP networking, there is the ARP table, which maps remote IP addresses to the MAC address that can route IP packets to/from them. This is what allows your client to communicate to your router over TCP/IP.

Another potential pitfall is where your modem communication introduces delays that interfere with the Ethernet layer's handling of the protocol. For example, the Ethernet protocol may have real-time constraints that could be shattered if you introduce delays...

But let's assume anything is possible in a perfect world...

You'll need to write code for reading/writing Ethernet messages (I've seen open source code for reading/writing Ethernet packets over raw sockets in Linux)

You'll need to write a custom driver for your GPIO comms. This means implementing a carefully thought-out protocol to manage pins state, start-of-message, end-of-message, data-payload, checksum, whatever...

Finally, you'll need to write a top-level communications layer that implements:

Ethernet-to-GPIO process:

a) read from Ethernet port, encapsulates Ethernet packet into a custom message (or message fragments)

b) communicate this custom message, using your custom GPIO protocol driver, to the external GPIO peer

GPIO-to-Ethernet process:

a) Read from GPIO, using your custom driver code b) Decapsulate Ethernet packet c) Write Ethernet packet to Ethernet port.

these two processes run forever...

Again, all hinges on whether or not your modems can insert themselves in an peer-to-peer connection without disturbing the natural flow of the Ethernet protocol...

As for the 'C' part...

If you use open source libraries (or code snippets) for reading/writing raw Ethernet via raw sockets, that is most likely written in C.

Your GPIO code will read write from the GPIO pins in one of two ways: from a memory mapped H/W address, or using ioport calls on that H/W address.

Receive raw Ethernet frames in Linux

Send a raw Ethernet frame in Linux

Good luck