Forum Discussion
Altera_Forum
Honored Contributor
Honored ContributorHTTP 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>15 Replies
Altera_ForumSorry 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:
i.e. add 14 bytes of padding to the end. Hope that helps!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 }; - 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'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.
<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.
