Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
21 years ago

HTTP server demo not accepting connections

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 'lan91c111_eth0'
 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't set multi-cast mode
 Warning: Driver can't set multi-cast mode
 Warning: Driver can't set multi-cast mode
PING server 10.4.1.2
 Warning: Driver can'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'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'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&#39;m still waiting for my USB Blaster rev. B (sent in the order for the "free" upgrade back in October), however, I&#39;d like to note that I&#39;ve had no problems with the MasterBlaster.

15 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    Sorry to bring this back up again, but it&#39;s a week to ship date and I&#39;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&#39; stack sizes, short of some hacking in ecos-current.

    I&#39;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&#39;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&#39;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&#39;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&#39;d try a reset, but we don&#39;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&#39;ve managed to trace it into the arpintr() function in the common Ethernet driver.

    The big pain with this problem is that it&#39;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&#39;m using Quartus 4.2 and Nios II 1.1, along with the eCos that was released for them. It&#39;s rather late to run the risk of changing development environments, so I&#39;m wondering if anyone found the fix, or has had this problem.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    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's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    That did it. We haven&#39;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's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    --- 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.