HTTP server demo not accepting connections

[Altera_Forum]

I've been trying the HTTP server demo, and haven't had any luck getting the demo board to accept connections from outside. 

 I built it according to the directions in kits/nios2/components/ecos/eCos%20for%20Nios%20II.htm, section 8, and when I ran it (using either the "hello" or "twothreads" example programs), it would successfully DHCP, obtaining the right address, servers, gateway, etc., and run the demo program. However, any connection attempt to port 80 would time out (even tried telnet).  I added an FTP server, rebuilt/reinstalled, and tried to connect to port 21; nothing.  Now I'm using the "ping test" ethernet test program shipped with eCos, and switched to manually configured eth0, with the same results. Here's the output from that test:  nios2-terminal: connected to hardware target using JTAG UART on cable nios2-terminal: "MasterBlaster ", device 1, instance 0 nios2-terminal: starting in terminal mode (Control-C exits) Init: mbinit(0x00000000) Init: cyg_net_init_devs(0x00000000) Init device &#39;lan91c111_eth0&#39; Init: loopattach(0x00000000) Init: ifinit(0x00000000) Init: domaininit(0x00000000) Init: cyg_net_add_domain(0x01061cb0) New domain internet at 0x00000000 Init: cyg_net_add_domain(0x0106166c) New domain route at 0x00000000 Init: call_route_init(0x00000000) Done Start PING test BOOTP op: REPLY       htype: Ethernet        hlen: 6        hops: 0         xid: 0x0        secs: 0       flags: 0x0       hw_addr: 00:07:ed:0b:08:85     client IP: 10.8.1.62         my IP: 10.8.1.62     server IP: 10.4.1.2    gateway IP: 10.8.254.254  options:        subnet mask: 255.255.0.0       IP broadcast: 10.8.255.255            gateway: 10.8.254.254 Warning: Driver can&#39;t set multi-cast mode Warning: Driver can&#39;t set multi-cast mode Warning: Driver can&#39;t set multi-cast mode PING server 10.4.1.2 Warning: Driver can&#39;t set multi-cast mode recvfrom: Operation timed out 64 bytes from 10.4.1.2: icmp_seq=1, time=20ms 310 bytes from 10.4.1.2: icmp_seq=2, time=20ms 556 bytes from 10.4.1.2: icmp_seq=3, time=20ms 802 bytes from 10.4.1.2: icmp_seq=4, time=30ms Warning: Driver can&#39;t set multi-cast mode recvfrom: Operation timed out 64 bytes from 10.4.1.2: icmp_seq=6, time=20ms 310 bytes from 10.4.1.2: icmp_seq=7, time=10ms 556 bytes from 10.4.1.2: icmp_seq=8, time=20ms 802 bytes from 10.4.1.2: icmp_seq=9, time=20ms Warning: Driver can&#39;t set multi-cast mode recvfrom: Operation timed out Route - dst: 0.0.0.0, mask: 0.0.0.0, gateway: 10.8.254.254 recvfrom: Operation timed out recvfrom: Operation timed out recvfrom: Operation timed out recvfrom: Operation timed out recvfrom: Operation timed out Sent 16 packets, received 8 OK, 0 bad PING server 10.4.1.34 recvfrom: Operation timed out recvfrom: Operation timed out recvfrom: Operation timed out recvfrom: Operation timed out recvfrom: Operation timed out recvfrom: Operation timed out recvfrom: Operation timed out recvfrom: Operation timed out recvfrom: Operation timed out recvfrom: Operation timed out recvfrom: Operation timed out recvfrom: Operation timed out recvfrom: Operation timed out recvfrom: Operation timed out recvfrom: Operation timed out recvfrom: Operation timed out Sent 16 packets, received 0 OK, 0 bad PASS:<Ping test OK> EXIT:<done>  Any ideas? Is there a simple socket-litener-echo test program, and if so, what is it called and what port does it listen on?  And I'm still waiting for my USB Blaster rev. B (sent in the order for the "free" upgrade back in October), however, I'd like to note that I've had no problems with the MasterBlaster.

[Altera_Forum]

Mike, 

 My guess is this is a networking configuration problem. The fact that your server is on the 10.4 subnet and the client on the 10.8 makes me suspicious. I would start with logging the packets being sent, use Ethereal or your favourite sniffer program.  Hope that helps.

[Altera_Forum]

The eth0 settings are set in the nios2configtool, though configuring it for DHCP worked the same way. 

 We use the 10.x.x.x range for internal IP addresses, and the second octet is based on the department. 10.4.x.x is the IT department, 10.8.x.x is mine. All my incoming connection attempts were from 10.8.x.x addresses. I didn't know what it was asking for for "Server IP address for 'eth0'", so I put in the IP of one of our nameservers.  Anyway, this morning it's decided on a new behavior. It accepts connections and replies to pings after the "recvfrom: Operation timed out", but the HTTP server doesn't return any data; it just leaves the connection open. I'm wondering if it got killed when the ping test ended...

[Altera_Forum]

Found another clue. It has to do with the programming procedure. 

 Run program_flash, then download the .sof file, then run nios2-terminal... fail.  Run program_flash, press the power-on reset button, then download the .sof file before the board goes into safe mode, then run nios2-terminal... success after net threads running.

[Altera_Forum]

So now I can connect to the HTTP server, but my coworker can't. Strange. There is one thing I don't understand; in the Network Monitor page it's giving me: 

 Network Monitor Interfaces Interface Status eth0  Flags UP BROADCAST RUNNING SIMPLEX MULTICAST Address 10.8.1.62 Mask 10.8.1.62 Broadcast 10.8.255.255 lo0  Flags UP LOOPBACK RUNNING MULTICAST Address 127.0.0.1 Mask 127.0.0.1  Is the mask supposed to equal the address? Or is it a subnet mask set wrong? And what is "SIMPLEX" referring to?

[Altera_Forum]

Mike, 

 I'm afraid I'm not familiar with the Network Monitor Page. Have you thought about trying the eCos mailing lists, as this is not specific to our port.   As for Simplex that means communicate in one direction at a time, as oposed to Duplex which is bi-directional simultaneously

[Altera_Forum]

I seem the be having the exact same issues that you're facing. Have you managed to get any further with this situation? 

 --Nate

[Altera_Forum]

I also am having the same issues. I've got a simple linxsys router (192.168.1.x) with no WAN connected. Just trying to talk to a laptop plugged in. The router's DHCP table shows the nios, but nothing works. Doing the power on reset thing doesn't work for me. I keep getting  

 [eth_drv_ioctl] Warning: Driver can't set multi-cast mode  Any help would be appreciated.  Scott

[Altera_Forum]

The message: 

 [eth_drv_ioctl] Warning: Driver can't set multi-cast mode  is normal, since the LAN91C111 driver doesn't support multicast unless explicitly enabled. This shouldn't be related to the problem that you're seeing.

[Altera_Forum]

I've just run into what seems to be a very similar situation with a development version of the eCos kernel. After a little investigation, I found that the HTTPD stack size was too small when running DHCP (it worked using a static IP address). By default this stack is set to 2K, and it really needs to be more like 5K. 

 To change this in configtool, go to "Basic network framework"->"HTTP Daemon" and set "HTTPD thread stack size" to 5120.  To measure stack usage, go to "eCos kernel"->"Thread-related options" and select "Measure stack usage". The stack usage information will then be available through the web server monitor pages (once you've got them working).  Hope that solves your problem!

[Altera_Forum]

That worked! 

 Thanks, Scott

[Altera_Forum]

Sorry to bring this back up again, but it's a week to ship date and I'm getting desperate. 

 The HTTP thread stack size was an issue, just not the only issue, apparently. My stack is set to 8192, and the thread monitor (when i can get to it) shows about 2.7K of stack used. I see that there is no way to change the network threads' stack sizes, short of some hacking in ecos-current.  I've managed to trace the problem down to this: sometimes the system boots fine, but other times it gets in a mode where it doesn't notice ARP replies that it should. Say you ping the demo board from some other machine. The demo board sends out an ARP request asking for the Ethernet MAC address of the machine doing the ping. The pinging machine sends an ARP reply. However, the demo board doesn't send the ping reply, like it does when it works. The pinging machine times out and sends another ping. The whole process repeats; it's like the demo board did not see the ARP reply from the pinging machine. Cycling power tends to make the problem go away. I'd try a reset, but we don't have a reset button on this machine.  I have turned on debug messages with verbosity level 2 in the Common Ethernet part of the I/O subsystem section of the nios2configtool window. I can see the dumps of the packets being sent and received coming across the JTAG UART. I have verified that the stack is getting the ARP packet, that it recognizes it as an ARP packet; I've managed to trace it into the arpintr() function in the common Ethernet driver.  The big pain with this problem is that it's difficult to reproduce, and adding the diag_printf calls to debug it is changing its behavior, making the bug less likely to occur.  I'm using Quartus 4.2 and Nios II 1.1, along with the eCos that was released for them. It's rather late to run the risk of changing development environments, so I'm wondering if anyone found the fix, or has had this problem.

[Altera_Forum]

I may be able to hold out some hope to you. There was a posting recently on the eCos mailing list which describes something that sounds very like the problem you are describing: http://www.spinics.net/lists/ecos/msg27032.html (http://www.spinics.net/lists/ecos/msg27032.html) 

 Following this, it seems that a fix is to change the definition of sockaddr_inarp in packages\net\bsd_tcpip\current\include\netinet to:  struct sockaddr_inarp {     u_char    sin_len;     u_char    sin_family;     u_short sin_port;     struct    in_addr sin_addr;     struct    in_addr sin_srcaddr;     u_short    sin_tos;     u_short    sin_other;     u_char     pad;# define SIN_PROXY 1 };  i.e. add 14 bytes of padding to the end.  Hope that helps!

[Altera_Forum]

That did it. We haven't seen that bug resurface in about three days now, through several power-cycle events. 

 Is that bug fix in the eCos for Quartus II 5.0 install? If not, one of us should post a patch script or something.

[Altera_Forum]

No, this fix isn't in the 5.0 release.

[Altera_Forum]

--- Quote Start ---  originally posted by monkeyboy@Mar 23 2005, 06:08 AM the message:  [eth_drv_ioctl] warning: driver can&#39;t set multi-cast mode  is normal, since the lan91c111 driver doesn&#39;t support multicast unless explicitly enabled. this shouldn&#39;t be related to the problem that you&#39;re seeing. <div align='right'><{post_snapback}> (index.php?act=findpost&pid=5617)  --- quote end ---    --- Quote End ---    Could you tell me how can I enable multicast support for LAN91C111, thanks.