NetBurner Community Forum

So I've been trying to figure out how to work with the second ethernet interface on the MOD54417 and I'm having a little trouble. I'm surprised the latest NNDK didn't come with an example on how to differentiate between the two.

I tried to make a test setup where it would act as a DHCP client through one port and set a static address on the other and act as a DHCP server. I couldn't find much to go on so I took a shot in the dark.

I started out getting the DHCP address like normal and I tried adding a static interface based on the interface number returned by Add2ndEthernet(). Then I started a DHCP server on that interface. Up to this point everything appears to be working. It assigns addresses out the second port and accepts incoming connections to the static address on the port. The problem comes when I try to make an outgoing connection on that port using the static address I set up. This times out. The destination adress and port are all correct and the other processor is listening for the connection.

So my question is how to I distinguish which of the ethernet ports to use for a connect call.

What is the address reported by IPsetup for the 2nd interface?
This is the IP address you need to use in the via call...

IPSetup correctly reports Ethernet2 as 192.168.1.2
Before the static address is assigned it shows the AutoIP address for it as 169.254.187.71
Neither of these addresses appear to work.

After I set the static address I iterate through all the interfaces with GetFirstInterface and GetnextInterface and then I print out the IP and other information about it. For reference, the Add2ndEthernet(); call returns the root_if 5 for Ethernet2. I tried the connectvia call with all non-zero addresses below and still was not able to establish an outgoing connection on the second port.

To clarify: I am considering the ethernet port on the left to be the first, and the port on the right to be the second. I am testing with it connected to a MOD54415 via a crossover cable. Incoming connections over the second port and assigning DHCP addresses over the second port are both working.

For the first 100 MOD54417-100IR units shipped in development kits, the first port is in the center, and the 2nd port is toward the outside edge.

However, one of the product goals is to enable someone to design a carrier board that can take either a Mod54415 or a Mod54417. In order to do that, especially with the -200 versions with headers instead of RJ-45 jacks, the first port must be on the outside edge so it will match up with a single port Mod54415 device.

Ok. Here's a placeholder post. I'm working a writeup to explain the hardware and software design methodologies when working with the MOD54417. I would have liked to responded when this post went up originally, but I was working on other issues.

-Dan

TL;DR
-----

Don't use Add2ndEthernet in the initializaton code for a MOD54417; it's already used
when necessary internally. Just treat the MOD54417 as you would a MOD54415. For rev 1.1 port 0 is in
the center of the board and port 1 is on the edge; they will switch places on rev 1.2+. Port 0 will
be interface 1 in independent mode and port 1 will be interface 2 in independent mode

Overview
---------

The MOD54417 was designed first and foremost to be fully compatible with the MOD54415. This includes
not only the hardware pins, but the software application you write as well. The motivating reason
for creating the MOD54417 was the desire for a second ethernet interface for either daisy-chaining
or separate data/control or priviledged/unpriviledged communication ports/channels.

Hardware
--------

The MOD54417 is fully pin compatible with the MOD54415 for the J1 and J2 connectors. The Ethernet
jacks are a little bit of a different matter. In the initial release (rev 1.1) of the MOD54417, the
layout has the Ethernet jack for port 0 located near the center of the board and port 1 near the
edge. This fits how you would read the port numbers from left to right on a backpanel. However,
this causes a problem if a customer wants to design a single carrier board to accept either module,
since on a MOD54415 port 0 would be located on the outside edge (where port 1 is on the MOD54417).

As a result, we have modified the design of the MOD54417 to switch the Ethernet ports so that port 0
is near the outside edge, and port 1 is near the center. All modules of revision 1.2 or later will
have this configuration.

Now, why did we change this after release? We changed this after release because we had a few
different options for correcting the "flaw":

1. Scrap the boards/only use internally and delay release until it has been corrected.
   Unfortunately, the implications of the port swap weren't realized until the initial board run was
   complete. As such, this would require waiting for an entire purchase cycle for the dual ethernet
   jacks, as this is the first product we have that uses them. The lead time on the part would mean a
   rather significant delay on us being able to get these to developers.
2. Let it be and don't change anything. This is/was certainly an option. However, as previously
   stated, we wanted 100% software compatibility between the 54415 and the 54417. If we left the jacks
   swapped, then for the -200 version (headers instead of jacks) a board designed to accept both the
   54415 and the 54417, the primary interface would be wrong.
3. Swap it in software. Again, this was considered. It's actually pretty simple to do. The problem
   is that if anyone ever creates a derivative design (aka, a custom board), the derivative would
   either have to carry forward the flaw, or the driver gets really screwy. Still not a good idea.
4. We release the module as is for DEVELOPMENT and notify people of the issue (what we're doing
   here).

Isn't product design and release fun? XD

Software
--------

Continuing with the full compatibility thread, let's discuss the networking software. Here's where
there's likely to be the most confusion. The MOD54417's Ethernet driver is designed such that it
will configure both network interfaces according to the hardware mode (switched vs. independent)
automatically with only the single call to InitializeStack(). Moving a little further,
GetDHCPAddressIfNecessary() has been modified to support this process. Previously, the default call
to GetDHCP... would only configure the first interface in the system. Now, the default call will
perform the check and negotiation process on ALL network interfaces in existance at the time of the
call.

Going back a bit, I mentioned that InitialeStack() will configure the interfaces properly according
to the hardware mode. The question is, how is that mode set? There are three ways to do that: set it
in the monitor with the 'E' command in the Setup menu, use the 'ESwitch Enable' checkbox under 'Advanced' in
IPSetup 2.3+, or directly set the flag in the primary ConfigRecord and save it in your application.

Now, what does this mean for the actual code you need to write to work with both interfaces? Are you
simply sitting on two different LANs? Are you just running with the switch? Are you doing anything
other than targeting a specific hardware interface? If any of these are true, you don't need to do
anything. The network stack will setup the IP address according to the normal process and route
connections accordingly. Just have the normal InitializeStack() and GetDHCPAddressIfNecessary()
calls.

We'll go a little more into detail for working with different interfaces in a followup.

-Dan