NetBurner Community Forum

I am using a MOD54417 and am having trouble sending out a specific nic.
I have disabled the Eswitch.

I have eth0 set to 192.168.100.20 and eth1 set to 192.168.100.40.

here is the block of code I am using to send my packet
UDPPacket pkt;
pkt.SetDestinationPort(m_destPortNum);
pkt.SetSourcePort(m_sourcePortNum);
pkt.AddData((BYTE*)buffer, msgSize);
pkt.SendVia(m_destIpAddress, m_localIpAddress);


m_destPortNum = 27018
m_sourcePortNum = 27018
m_destIpAddress = 192.168.100.19 (converted to IPADDR)
m_localIpAddress= 192.168.100.40 (converted to IPADDR)

I expected this code to send out 192.168.100.40 but this message is sent out 192.168.100.20

Any help would be appreciated.

In the latest release we changed the name of the SendVia...

to be SendViaInterface....

You are passing an IP address, it expects an interface number, not an IP....


IPADDR InterfaceIP( int interface );

Gives you an source IP given interface number....

These list the valid interfaces....
int GetFirstInterface( void );
int GetnextInterface( int lastInterface );

pbreed,

Thanks for the information.

I have one other question with connecting via specific interface for UDP.

I am using the following code

OSFifoInit(&m_udpFifo);
RegisterUDPFifo(m_destPortNum, &m_udpFifo);

UDPPacket upkt(&m_udpFifo, 0);

if (upkt.Validate())
{
m_bytesRcvd = upkt.GetDataSize();
sourceIp = upkt.GetSourceAddress();
m_sourcePortNum = upkt.GetSourcePort();

if(sourceIp == m_destIpAddress)
{
if(m_bytesRcvd > 0)
{
memcpy(m_rcvdBuffer,upkt.GetDataBuffer(), m_bytesRcvd);
return m_bytesRcvd;
}
}
}


If I do not have both nic's physically connect I cannot get the first message. Once I get the first message I can disconnect the non used's nic the communication will continue.

I see there is a recvfrom method but labeled as internal.

Not sure what I am missing. Im sure its something simple as in the sendViaInterface.

Thanks

Are you sure you code is running at all, or just hung waiting for a DHCP address?

If only one port is connected...does the behavior vary by which port is connected?

IE try the left one, try the right one....
Either should work... I'll look at this...

preed,

sorry for the delayed reply. The code is not waiting for a DCHP address. I have to have hard coded ip's for my application. the code blocks on the upkt.Validate() call.

I will check the interaction with the different ports connected.

Jeff

pbreed,


I checked the performance of the netburner. I cannot get any communication to start unless I have both the nic's plugged into a switch.

Jeff

Can the IPSETUP tool see the netburner with just one port plugged in?

Yes it can.

Very strange the validate function is really simple...
It's in nburn\system\udp.cpp....


About the only way that can get messed up is to corrupt the ethernet buffer pool...

Are you sending any UDP output packets?
About the only way to mess up the buffer system is to mismanage UDP send
Are you sending UDP packets?

What else is going on in your code other than the UDP recieve?

Can you please run the following experiment....

boot to the monitor (IE hit 'A' to abort)
type setup

make sure the ethernet switch is disabled
Change the setting to disabled if it is not already.


Now build and run the nburn\examples\standardstack\udp\udpsendreceive example
Using ipsetup make sure BOTH interfaces have static addresses....
(DHCP will work too just the addresses might change during reboot so keep ipsetupopen to monitor addresses)

On the Serial console (from the example program)
Pick a port to receive on...
For this test the transmit address does not matter...

Use UDPTerminal and send packets to each of the interfaces at their static address with both the local and remote port set to
the port you choose in the previous step...

Verify that udpterminal can send to both ports.
IE udpterminal sends and the application displays the received packet

Now disconnect one port
Cycle power
Verify that udpterminal can send to the connected port.
Swap what port is connected...
Cycle power
Verify that udpterminal can send to the connected port.


I just ran this test and it worked flawlessly on both ports... using our unmodified UDPSendRecieve example.