Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Altera_Forum
Honored Contributor I
1,225 Views

DHCP Timed Out problem in simple socket server

Hi, 

 

I am running simple socket server for rgmii from Nios2 Eclipse template. 

I could get the Auto negotiation passed and Link established successfully. However the DHCP server fails to acquire an IP address. The program prompts me DHCP Timed Out and back to static IP address. 

Anyone knows what could bring to this problem? Any way to debug? 

 

Thanks, 

-Carid
0 Kudos
11 Replies
Altera_Forum
Honored Contributor I
72 Views

Do you have a DHCP server in your network?

Altera_Forum
Honored Contributor I
72 Views

Yes I have. I tried on Cyclone III development kit and I was able to obtain an IP address. Telnet is successful. For this kind issue, what could be the problem? 

 

Thanks, 

-Carid
Altera_Forum
Honored Contributor I
72 Views

When DHCP server fails to acquire an IP address, could it be something wrong with the flash? In fact, i am a lil confused on how the SSS program actually generate the M number if AC and IP addresses based on the board serial number if the flash is absolutely empty.  

 

One more culprit is that I am using 125MHz on board clock and scale it down to 50MHz using PLL in my Qsys system. Timing constraint has been done, yet there are still some violations.  

 

Thanks.
Altera_Forum
Honored Contributor I
72 Views

Sorry, typo here 

** how the SSS generates the MAC and IP addresses based on the board serial number.
Altera_Forum
Honored Contributor I
72 Views

IIRC, when you have a blank flash memory, SSS uses a default MAC address or prompts the user to enter it at the console. 

IP address is not relevant in your case, since it should be assigned by DHCP server. 

I suggest you perform a preliminary test with dhcp disabled, so you can make sure hw and sw are working correctly. I also suggest you return fixed and well known addresses in get_ip_addr() and get_board_mac_addr(), thus excluding a possibly bad flash memory content.
Altera_Forum
Honored Contributor I
72 Views

Thanks Cris. I've just performed the SSS using static IP address and apparently, it still fails to 'telnet' using the static IP address defined in the sss.h header file. As of now what I could think of this issue could be related to unconstrainted design. I am using RGMII interface. 

 

Thanks, 

-Carid
Altera_Forum
Honored Contributor I
72 Views

telnet involves a tcp connection and may be affected by flaws in your application.  

You'd better start with a simple: ping <IP_address>  

Anyway if you have concerns on ethernet interface and fpga configuration and timing, you need more specific tests. 

What are you using, Nichestack? uC/OS2 or superloop?
Altera_Forum
Honored Contributor I
72 Views

Hi Cris, what did you mean by flaws in my application? I got this unique static IP address my IT departmentand I assume it should be able to "telnet" if my design is working. By the way, other than defining the IP address in the simple socket server.h file and disabling the DHCP Server through BPS Editor, what se should I do to configure the system to be using Static IP address? 

 

As I am using the simple socket server from template in Nios2 SBT Eclipse, it is using Nichestack TCP/IP Stack and MicroCOS II software packages. 

 

Do you think that unconstraint design will cause DHCP Server fails to acquire an IP address?
Altera_Forum
Honored Contributor I
72 Views

 

--- Quote Start ---  

what did you mean by flaws in my application? 

 

--- Quote End ---  

 

I meant the Nios application, not your telnet client. 

I suggested you use ping instead of telnet, because ping use only a minimal part of the network stack, so it's less prone to any software/driver problem. In other words, ping always works when telnet (or generic tcp connection) does; the reverse is not true. 

 

 

--- Quote Start ---  

 

By the way, other than defining the IP address in the simple socket server.h file and disabling the DHCP Server through BPS Editor, what se should I do to configure the system to be using Static IP address? 

 

--- Quote End ---  

 

Ok. This is enough. 

 

 

--- Quote Start ---  

 

Do you think that unconstraint design will cause DHCP Server fails to acquire an IP address? 

--- Quote End ---  

 

Timing problems can lead to very subtle defects, not easy to identify and reproduce. 

From your description the problem seems to be located at the mac/phy level, but I can't say if due to timing or any logic error. I'd exclude any error on Nios sw/driver side, since you said you are using the sss template with nearly no changes. 

Timing: make sure you have at least the minimal (core) constraints; you should have time quest analysis enabled, timing driven synthesis option checked and your project must include the .sdc file generated by sopc builder / Qsys 

Logic: check if the RGMII signals are correctly routed to the proper fpga pins connected to ethernet phy. Also check in the Nios terminal log: it should report the ethernet phy has been identified, initialized and ethernet link established.
Altera_Forum
Honored Contributor I
72 Views

Hi Cris, 

 

I did try "ping" but I have request timed out, it seems that "ping" was not successful from the command response as shown:- 

 

request timed out. 

request timed out. 

request timed out. 

request timed out. 

ping statistics for 137.57.118.41: 

packets: sent = 4, received = 0, lost = 4 (100% loss), 

 

As for "telnet", I can't get an IP address from DHCP server:- 

 

your ethernet mac address is 00:07:ed:7f:6b:47 

prepped 1 interface, initializing... 

[tse_mac_init] 

info : tse mac 0 found at address 0x08003000 

info : phy marvell 88e1111 found at phy address 0x00 of mac group[0] 

info : phy[0.0] - automatically mapped to tse_mac_device[0] 

info : phy[0.0] - restart auto-negotiation, checking phy link... 

info : phy[0.0] - auto-negotiation passed 

marvell : mode changed to rgmii/modified mii to copper mode 

marvell : enable rgmii timing control 

marvell : phy reset 

info : phy[0.0] - checking link... 

info : phy[0.0] - link not yet established, restart auto-negotiation... 

info : phy[0.0] - restart auto-negotiation, checking phy link... 

info : phy[0.0] - auto-negotiation passed 

info : phy[0.0] - link established 

info : phy[0.0] - speed = 100, duplex = full 

ok, x=0, cmd_config=0x00000000 

mac post-initialization: cmd_config=0x04000203 

[tse_sgdma_read_init] rx descriptor chain desc (1 depth) created 

mctest init called 

ip address of et1 : 0.0.0.0 

dhcp timed out, going back to default ip address(es) 

 

simple socket server starting up 

[sss_task] simple socket server listening on port 30 

created "simple socket server" task (prio: 4) 

 

---------------------- 

 

Let me narrow down the possible root causes for this issue as follow:- 

a) Timing 

b) Logic 

c) Software 

 

b) is out since I am porting over the previous working design on Arria V to this project. I am pretty sure the RGMII signals are connected correctly and so on. 

 

c) is out too since as you said I am using the ready template from SBT for Eclipse software, the drivers should be no problem. 

 

As of now, the possible cause would be timing. Any other causes you may think of? Please do let me know. 

 

Thanks, 

-Carid
Altera_Forum
Honored Contributor I
72 Views

The following can help you better understanding where the problem is. 

 

Browse the Nios sw library and locate the file ipnet.c. It should be in: 

<altera_directory>\nios2eds\components\altera_iniche\UCOSII\src\ip 

Look for the pktdemux() function and place a breakpoint here.  

Compile the whole project and bsp in debug mode and start a debug session. 

Your code should hit the breakpoint whenever an ethernet packet is received. 

At this point you can follow the execution and find out where it fails. 

For a ping packet, the flow should lead to the entry: case ARPTP 

 

If pktdemux is not reached at all, you have a problem at a lower level. 

Are you using tse, isn't it? Then you can place a breakpoint in tse_mac_rcv()  

(file ins_tse_mac.c) and check if execution at least gets here. 

Another good method is using tse_mac_raw_send() to manually transmit a packet and check if it's actually transmitted, using any network analyzer program (i.e. WireShark)