[ECOS] Network problem with eCos 2.0 and Viper

[ECOS] Network problem with eCos 2.0 and Viper

[Paul Randall]

Hi all,

Thanks to Gary Thomas for helping me update RedBoot on my viper.  The
new version is running well.  I can ping to/from the board and also
telnet into the board, both of which I could not do with the version of
RedBoot that shipped with my viper.

After I got the new version of RedBoot running, I tried to run
pingtest.exe on the viper and the test failed.  The output of the test
is:

(gdb) [cyg_net_init] Init: mbinit(0x00000000)
[cyg_net_init] Init: cyg_net_init_devs(0x00000000)
Init device 'fec_eth'
[cyg_net_init] Init: loopattach(0x00000000)
[cyg_net_init] Init: ifinit(0x00000000)
IFP: 0x000858dc, next: 0x000da6c0
IFP: 0x000da6c0, next: 0x00000000
eth0 XXX: driver didn't set ifq_maxlen
[cyg_net_init] Init: domaininit(0x00000000)
[cyg_net_init] Init: cyg_net_add_domain(0x00086690)
New domain internet at 0x00000000
[cyg_net_init] Init: cyg_net_add_domain(0x000860d0)
New domain route at 0x00000000
[cyg_net_init] Init: cyg_route_init(0x00000000)
[cyg_net_init] Done
Start PING test
BOOTP[eth0] op: REPLY
       htype: Ethernet
        hlen: 6
        hops: 0
         xid: 0x0
        secs: 0
       flags: 0x0
       hw_addr: 08:00:3e:28:7a:b8
     client IP: 206.234.219.88
         my IP: 206.234.219.88
     server IP: 206.234.219.89
    gateway IP: 0.0.0.0
  options:
        subnet mask: 255.255.255.224
       IP broadcast: 206.234.219.95
            gateway: 0.0.0.0
PING server 206.234.219.89
recvfrom: Operation timed out
recvfrom: Operation timed out
recvfrom: Operation timed out
recvfrom: Operation timed out
recvfrom: Operation timed out
recvfrom: Operation timed out
sendto: Host is down
sendto: Host is down
sendto: Host is down
sendto: Host is down
sendto: Host is down
sendto: Host is down
sendto: Host is down
sendto: Host is down
sendto: Host is down
sendto: Host is down
Sent 16 packets, received 0 OK, 0 bad
PING server 206.234.219.121
sendto: No route to host
sendto: No route to host
sendto: No route to host
sendto: No route to host
sendto: No route to host
sendto: No route to host
sendto: No route to host
sendto: No route to host
sendto: No route to host
sendto: No route to host
sendto: No route to host
sendto: No route to host
sendto: No route to host
sendto: No route to host
sendto: No route to host
sendto: No route to host
Sent 16 packets, received 0 OK, 0 bad
PASS:<Ping test OK>
EXIT:<done>

The one line that looked strange to me was 'eth0 XXX: driver didn't set
ifq_maxlen' but when I looked at the source the value for ifq_maxlen is
set to 50 if the value is 0.

I traced the ethernet traffic with the Ethereal analyzer which produced
the following output:

    No. Time        Source                Destination           Protocol
Info
      1 0.000000    08:00:3e:28:7a:b8     ff:ff:ff:ff:ff:ff     ARP     
Who has 206.234.219.88?  Tell 206.234.219.88
      2 0.000981    08:00:3e:28:7a:b8     ff:ff:ff:ff:ff:ff     ARP     
Who has 206.234.219.88?  Tell 206.234.219.88
      3 0.028756    08:00:3e:28:7a:b8     ff:ff:ff:ff:ff:ff     ARP     
Who has 206.234.219.89?  Tell 206.234.219.88
      4 116645.841622 00:03:47:02:64:8c     08:00:3e:28:7a:b8    
ARP      206.234.219.89 is at 00:03:47:02:64:8c
      5 0.844230    08:00:3e:28:7a:b8     ff:ff:ff:ff:ff:ff     ARP     
Who has 206.234.219.89?  Tell 206.234.219.88
      6 116646.657181 00:03:47:02:64:8c     08:00:3e:28:7a:b8    
ARP      206.234.219.89 is at 00:03:47:02:64:8c
      7 1.659914    08:00:3e:28:7a:b8     ff:ff:ff:ff:ff:ff     ARP     
Who has 206.234.219.89?  Tell 206.234.219.88
      8 116647.472966 00:03:47:02:64:8c     08:00:3e:28:7a:b8    
ARP      206.234.219.89 is at 00:03:47:02:64:8c
      9 2.475597    08:00:3e:28:7a:b8     ff:ff:ff:ff:ff:ff     ARP     
Who has 206.234.219.89?  Tell 206.234.219.88
     10 116648.288733 00:03:47:02:64:8c     08:00:3e:28:7a:b8    
ARP      206.234.219.89 is at 00:03:47:02:64:8c
     11 9.519239    00000000.00034702648c 00000000.ffffffffffff NCP     
[Malformed Packet]

According to this capture, the viper is broadcasting ARP requests and
the 'server' is responding, but the viper is not seeing the response. 
I'm guessing that I don't have eCos configured properly, since ping
works in RedBoot.  Before I upgraded to eCos 2.0, ping_test.exe worked,
but the response time was occasionally very slow.  I have also tried
running ftp_test.exe with the eCos 2.0 code which also fails during the
ARP procedure.

Any suggestions?

Best regards,

Paul Randall
Delta INformation Systems

-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Re: [ECOS] Network problem with eCos 2.0 and Viper

[Gary Thomas]

On Thu, 2002-06-06 at 11:39, Paul Randall wrote:
> Hi all,
> 
> Thanks to Gary Thomas for helping me update RedBoot on my viper.  The
> new version is running well.  I can ping to/from the board and also
> telnet into the board, both of which I could not do with the version of
> RedBoot that shipped with my viper.
> 
> After I got the new version of RedBoot running, I tried to run
> pingtest.exe on the viper and the test failed.  The output of the test
> is:
> 
> (gdb) [cyg_net_init] Init: mbinit(0x00000000)
> [cyg_net_init] Init: cyg_net_init_devs(0x00000000)
> Init device 'fec_eth'
> [cyg_net_init] Init: loopattach(0x00000000)
> [cyg_net_init] Init: ifinit(0x00000000)
> IFP: 0x000858dc, next: 0x000da6c0
> IFP: 0x000da6c0, next: 0x00000000
> eth0 XXX: driver didn't set ifq_maxlen
> [cyg_net_init] Init: domaininit(0x00000000)
> [cyg_net_init] Init: cyg_net_add_domain(0x00086690)
> New domain internet at 0x00000000
> [cyg_net_init] Init: cyg_net_add_domain(0x000860d0)
> New domain route at 0x00000000
> [cyg_net_init] Init: cyg_route_init(0x00000000)
> [cyg_net_init] Done
> Start PING test
> BOOTP[eth0] op: REPLY
>        htype: Ethernet
>         hlen: 6
>         hops: 0
>          xid: 0x0
>         secs: 0
>        flags: 0x0
>        hw_addr: 08:00:3e:28:7a:b8
>      client IP: 206.234.219.88
>          my IP: 206.234.219.88
>      server IP: 206.234.219.89
>     gateway IP: 0.0.0.0
>   options:
>         subnet mask: 255.255.255.224
>        IP broadcast: 206.234.219.95
>             gateway: 0.0.0.0
> PING server 206.234.219.89
> recvfrom: Operation timed out
> recvfrom: Operation timed out
> recvfrom: Operation timed out
> recvfrom: Operation timed out
> recvfrom: Operation timed out
> recvfrom: Operation timed out
> sendto: Host is down
> sendto: Host is down
> sendto: Host is down
> sendto: Host is down
> sendto: Host is down
> sendto: Host is down
> sendto: Host is down
> sendto: Host is down
> sendto: Host is down
> sendto: Host is down
> Sent 16 packets, received 0 OK, 0 bad
> PING server 206.234.219.121
> sendto: No route to host
> sendto: No route to host
> sendto: No route to host
> sendto: No route to host
> sendto: No route to host
> sendto: No route to host
> sendto: No route to host
> sendto: No route to host
> sendto: No route to host
> sendto: No route to host
> sendto: No route to host
> sendto: No route to host
> sendto: No route to host
> sendto: No route to host
> sendto: No route to host
> sendto: No route to host
> Sent 16 packets, received 0 OK, 0 bad
> PASS:<Ping test OK>
> EXIT:<done>
> 
> The one line that looked strange to me was 'eth0 XXX: driver didn't set
> ifq_maxlen' but when I looked at the source the value for ifq_maxlen is
> set to 50 if the value is 0.
> 
> I traced the ethernet traffic with the Ethereal analyzer which produced
> the following output:
> 
>     No. Time        Source                Destination           Protocol
> Info
>       1 0.000000    08:00:3e:28:7a:b8     ff:ff:ff:ff:ff:ff     ARP     
> Who has 206.234.219.88?  Tell 206.234.219.88
>       2 0.000981    08:00:3e:28:7a:b8     ff:ff:ff:ff:ff:ff     ARP     
> Who has 206.234.219.88?  Tell 206.234.219.88
>       3 0.028756    08:00:3e:28:7a:b8     ff:ff:ff:ff:ff:ff     ARP     
> Who has 206.234.219.89?  Tell 206.234.219.88
>       4 116645.841622 00:03:47:02:64:8c     08:00:3e:28:7a:b8    
> ARP      206.234.219.89 is at 00:03:47:02:64:8c
>       5 0.844230    08:00:3e:28:7a:b8     ff:ff:ff:ff:ff:ff     ARP     
> Who has 206.234.219.89?  Tell 206.234.219.88
>       6 116646.657181 00:03:47:02:64:8c     08:00:3e:28:7a:b8    
> ARP      206.234.219.89 is at 00:03:47:02:64:8c
>       7 1.659914    08:00:3e:28:7a:b8     ff:ff:ff:ff:ff:ff     ARP     
> Who has 206.234.219.89?  Tell 206.234.219.88
>       8 116647.472966 00:03:47:02:64:8c     08:00:3e:28:7a:b8    
> ARP      206.234.219.89 is at 00:03:47:02:64:8c
>       9 2.475597    08:00:3e:28:7a:b8     ff:ff:ff:ff:ff:ff     ARP     
> Who has 206.234.219.89?  Tell 206.234.219.88
>      10 116648.288733 00:03:47:02:64:8c     08:00:3e:28:7a:b8    
> ARP      206.234.219.89 is at 00:03:47:02:64:8c
>      11 9.519239    00000000.00034702648c 00000000.ffffffffffff NCP     
> [Malformed Packet]
> 
> According to this capture, the viper is broadcasting ARP requests and
> the 'server' is responding, but the viper is not seeing the response. 
> I'm guessing that I don't have eCos configured properly, since ping
> works in RedBoot.  Before I upgraded to eCos 2.0, ping_test.exe worked,
> but the response time was occasionally very slow.  I have also tried
> running ftp_test.exe with the eCos 2.0 code which also fails during the
> ARP procedure.
> 
> Any suggestions?

Try turning on some debugging in the eCos network stack to see what it's
getting.  I tested the network code (I'm sure I tried the new network 
stack on this board) and it worked fine.

As for your other problems (slow FTP, etc), this will also be fixed if
you want to revert to the "old" network stack.


-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Re: [ECOS] Network problem with eCos 2.0 and Viper

[Paul Randall]

Hi Gary,

I compiled eCos with the "old" network stack (i.e. Open BSD) and I get the
same problem (ARPs are sent out but the responses from the host are not
recognized) that I did with the new network stack.

I set a breakpoint in the fec_eth_int() interrupt processing routine in
if_fec.c and the breakpoint was not hit once during ping_test.exe (for
transmit or receive interrupts).  I figured that this is because the
interrupts were not enabled properly.  While stepping through the
fec_eth_init() function, execution skipped over the section of code that sets
up the interrupts because CYGINT_IO_ETH_INT_SUPPORT_REQUIRED was not defined
for if_fec.c.  CYGINT_IO_ETH_INT_SUPPORT_REQUIRED is defined in
io_eth_drivers.h (because CYGPKG_IO_ETH_DRIVERS_NET implements it), but this
header file is not included in if_fec.c so the creation of interrupts is not
done.

I noticed that a lot of the other if_*.c files have the
<pkgconf/io_eth_drivers.h> include file.  Shouldn't if_fec.c have it too?

I looked back to the if_fec.c in eCos version 1.3.1 and the creation of
interrupts only depends on the CYGPKG_NET define which is probably why the
ping_test worked for me with that version.

Best regards,

Paul Randall
Delta Information Systems



Gary Thomas wrote:

> On Thu, 2002-06-06 at 11:39, Paul Randall wrote:
> > Hi all,
> >
> > Thanks to Gary Thomas for helping me update RedBoot on my viper.  The
> > new version is running well.  I can ping to/from the board and also
> > telnet into the board, both of which I could not do with the version of
> > RedBoot that shipped with my viper.
> >
> > After I got the new version of RedBoot running, I tried to run
> > pingtest.exe on the viper and the test failed.  The output of the test
> > is:
> >
> > (gdb) [cyg_net_init] Init: mbinit(0x00000000)
> > [cyg_net_init] Init: cyg_net_init_devs(0x00000000)
> > Init device 'fec_eth'
> > [cyg_net_init] Init: loopattach(0x00000000)
> > [cyg_net_init] Init: ifinit(0x00000000)
> > IFP: 0x000858dc, next: 0x000da6c0
> > IFP: 0x000da6c0, next: 0x00000000
> > eth0 XXX: driver didn't set ifq_maxlen
> > [cyg_net_init] Init: domaininit(0x00000000)
> > [cyg_net_init] Init: cyg_net_add_domain(0x00086690)
> > New domain internet at 0x00000000
> > [cyg_net_init] Init: cyg_net_add_domain(0x000860d0)
> > New domain route at 0x00000000
> > [cyg_net_init] Init: cyg_route_init(0x00000000)
> > [cyg_net_init] Done
> > Start PING test
> > BOOTP[eth0] op: REPLY
> >        htype: Ethernet
> >         hlen: 6
> >         hops: 0
> >          xid: 0x0
> >         secs: 0
> >        flags: 0x0
> >        hw_addr: 08:00:3e:28:7a:b8
> >      client IP: 206.234.219.88
> >          my IP: 206.234.219.88
> >      server IP: 206.234.219.89
> >     gateway IP: 0.0.0.0
> >   options:
> >         subnet mask: 255.255.255.224
> >        IP broadcast: 206.234.219.95
> >             gateway: 0.0.0.0
> > PING server 206.234.219.89
> > recvfrom: Operation timed out
> > recvfrom: Operation timed out
> > recvfrom: Operation timed out
> > recvfrom: Operation timed out
> > recvfrom: Operation timed out
> > recvfrom: Operation timed out
> > sendto: Host is down
> > sendto: Host is down
> > sendto: Host is down
> > sendto: Host is down
> > sendto: Host is down
> > sendto: Host is down
> > sendto: Host is down
> > sendto: Host is down
> > sendto: Host is down
> > sendto: Host is down
> > Sent 16 packets, received 0 OK, 0 bad
> > PING server 206.234.219.121
> > sendto: No route to host
> > sendto: No route to host
> > sendto: No route to host
> > sendto: No route to host
> > sendto: No route to host
> > sendto: No route to host
> > sendto: No route to host
> > sendto: No route to host
> > sendto: No route to host
> > sendto: No route to host
> > sendto: No route to host
> > sendto: No route to host
> > sendto: No route to host
> > sendto: No route to host
> > sendto: No route to host
> > sendto: No route to host
> > Sent 16 packets, received 0 OK, 0 bad
> > PASS:<Ping test OK>
> > EXIT:<done>
> >
> > The one line that looked strange to me was 'eth0 XXX: driver didn't set
> > ifq_maxlen' but when I looked at the source the value for ifq_maxlen is
> > set to 50 if the value is 0.
> >
> > I traced the ethernet traffic with the Ethereal analyzer which produced
> > the following output:
> >
> >     No. Time        Source                Destination           Protocol
> > Info
> >       1 0.000000    08:00:3e:28:7a:b8     ff:ff:ff:ff:ff:ff     ARP
> > Who has 206.234.219.88?  Tell 206.234.219.88
> >       2 0.000981    08:00:3e:28:7a:b8     ff:ff:ff:ff:ff:ff     ARP
> > Who has 206.234.219.88?  Tell 206.234.219.88
> >       3 0.028756    08:00:3e:28:7a:b8     ff:ff:ff:ff:ff:ff     ARP
> > Who has 206.234.219.89?  Tell 206.234.219.88
> >       4 116645.841622 00:03:47:02:64:8c     08:00:3e:28:7a:b8
> > ARP      206.234.219.89 is at 00:03:47:02:64:8c
> >       5 0.844230    08:00:3e:28:7a:b8     ff:ff:ff:ff:ff:ff     ARP
> > Who has 206.234.219.89?  Tell 206.234.219.88
> >       6 116646.657181 00:03:47:02:64:8c     08:00:3e:28:7a:b8
> > ARP      206.234.219.89 is at 00:03:47:02:64:8c
> >       7 1.659914    08:00:3e:28:7a:b8     ff:ff:ff:ff:ff:ff     ARP
> > Who has 206.234.219.89?  Tell 206.234.219.88
> >       8 116647.472966 00:03:47:02:64:8c     08:00:3e:28:7a:b8
> > ARP      206.234.219.89 is at 00:03:47:02:64:8c
> >       9 2.475597    08:00:3e:28:7a:b8     ff:ff:ff:ff:ff:ff     ARP
> > Who has 206.234.219.89?  Tell 206.234.219.88
> >      10 116648.288733 00:03:47:02:64:8c     08:00:3e:28:7a:b8
> > ARP      206.234.219.89 is at 00:03:47:02:64:8c
> >      11 9.519239    00000000.00034702648c 00000000.ffffffffffff NCP
> > [Malformed Packet]
> >
> > According to this capture, the viper is broadcasting ARP requests and
> > the 'server' is responding, but the viper is not seeing the response.
> > I'm guessing that I don't have eCos configured properly, since ping
> > works in RedBoot.  Before I upgraded to eCos 2.0, ping_test.exe worked,
> > but the response time was occasionally very slow.  I have also tried
> > running ftp_test.exe with the eCos 2.0 code which also fails during the
> > ARP procedure.
> >
> > Any suggestions?
>
> Try turning on some debugging in the eCos network stack to see what it's
> getting.  I tested the network code (I'm sure I tried the new network
> stack on this board) and it worked fine.
>
> As for your other problems (slow FTP, etc), this will also be fixed if
> you want to revert to the "old" network stack.


-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Re: [ECOS] Network problem with eCos 2.0 and Viper

[Gary Thomas]

On Fri, 2002-06-07 at 12:45, Paul Randall wrote:
> Hi Gary,
> 
> I compiled eCos with the "old" network stack (i.e. Open BSD) and I get the
> same problem (ARPs are sent out but the responses from the host are not
> recognized) that I did with the new network stack.
> 
> I set a breakpoint in the fec_eth_int() interrupt processing routine in
> if_fec.c and the breakpoint was not hit once during ping_test.exe (for
> transmit or receive interrupts).  I figured that this is because the
> interrupts were not enabled properly.  While stepping through the
> fec_eth_init() function, execution skipped over the section of code that sets
> up the interrupts because CYGINT_IO_ETH_INT_SUPPORT_REQUIRED was not defined
> for if_fec.c.  CYGINT_IO_ETH_INT_SUPPORT_REQUIRED is defined in
> io_eth_drivers.h (because CYGPKG_IO_ETH_DRIVERS_NET implements it), but this
> header file is not included in if_fec.c so the creation of interrupts is not
> done.
> 
> I noticed that a lot of the other if_*.c files have the
> <pkgconf/io_eth_drivers.h> include file.  Shouldn't if_fec.c have it too?
> 
> I looked back to the if_fec.c in eCos version 1.3.1 and the creation of
> interrupts only depends on the CYGPKG_NET define which is probably why the
> ping_test worked for me with that version.
> 

This is a recent change (not by me) which may have broken some drivers.
Does adding the include file <pkgconf/io_eth_drivers.h> fix the problem?

> Best regards,
> 
> Paul Randall
> Delta Information Systems
> 
> 
> 
> Gary Thomas wrote:
> 
> > On Thu, 2002-06-06 at 11:39, Paul Randall wrote:
> > > Hi all,
> > >
> > > Thanks to Gary Thomas for helping me update RedBoot on my viper.  The
> > > new version is running well.  I can ping to/from the board and also
> > > telnet into the board, both of which I could not do with the version of
> > > RedBoot that shipped with my viper.
> > >
> > > After I got the new version of RedBoot running, I tried to run
> > > pingtest.exe on the viper and the test failed.  The output of the test
> > > is:
> > >
> > > (gdb) [cyg_net_init] Init: mbinit(0x00000000)
> > > [cyg_net_init] Init: cyg_net_init_devs(0x00000000)
> > > Init device 'fec_eth'
> > > [cyg_net_init] Init: loopattach(0x00000000)
> > > [cyg_net_init] Init: ifinit(0x00000000)
> > > IFP: 0x000858dc, next: 0x000da6c0
> > > IFP: 0x000da6c0, next: 0x00000000
> > > eth0 XXX: driver didn't set ifq_maxlen
> > > [cyg_net_init] Init: domaininit(0x00000000)
> > > [cyg_net_init] Init: cyg_net_add_domain(0x00086690)
> > > New domain internet at 0x00000000
> > > [cyg_net_init] Init: cyg_net_add_domain(0x000860d0)
> > > New domain route at 0x00000000
> > > [cyg_net_init] Init: cyg_route_init(0x00000000)
> > > [cyg_net_init] Done
> > > Start PING test
> > > BOOTP[eth0] op: REPLY
> > >        htype: Ethernet
> > >         hlen: 6
> > >         hops: 0
> > >          xid: 0x0
> > >         secs: 0
> > >        flags: 0x0
> > >        hw_addr: 08:00:3e:28:7a:b8
> > >      client IP: 206.234.219.88
> > >          my IP: 206.234.219.88
> > >      server IP: 206.234.219.89
> > >     gateway IP: 0.0.0.0
> > >   options:
> > >         subnet mask: 255.255.255.224
> > >        IP broadcast: 206.234.219.95
> > >             gateway: 0.0.0.0
> > > PING server 206.234.219.89
> > > recvfrom: Operation timed out
> > > recvfrom: Operation timed out
> > > recvfrom: Operation timed out
> > > recvfrom: Operation timed out
> > > recvfrom: Operation timed out
> > > recvfrom: Operation timed out
> > > sendto: Host is down
> > > sendto: Host is down
> > > sendto: Host is down
> > > sendto: Host is down
> > > sendto: Host is down
> > > sendto: Host is down
> > > sendto: Host is down
> > > sendto: Host is down
> > > sendto: Host is down
> > > sendto: Host is down
> > > Sent 16 packets, received 0 OK, 0 bad
> > > PING server 206.234.219.121
> > > sendto: No route to host
> > > sendto: No route to host
> > > sendto: No route to host
> > > sendto: No route to host
> > > sendto: No route to host
> > > sendto: No route to host
> > > sendto: No route to host
> > > sendto: No route to host
> > > sendto: No route to host
> > > sendto: No route to host
> > > sendto: No route to host
> > > sendto: No route to host
> > > sendto: No route to host
> > > sendto: No route to host
> > > sendto: No route to host
> > > sendto: No route to host
> > > Sent 16 packets, received 0 OK, 0 bad
> > > PASS:<Ping test OK>
> > > EXIT:<done>
> > >
> > > The one line that looked strange to me was 'eth0 XXX: driver didn't set
> > > ifq_maxlen' but when I looked at the source the value for ifq_maxlen is
> > > set to 50 if the value is 0.
> > >
> > > I traced the ethernet traffic with the Ethereal analyzer which produced
> > > the following output:
> > >
> > >     No. Time        Source                Destination           Protocol
> > > Info
> > >       1 0.000000    08:00:3e:28:7a:b8     ff:ff:ff:ff:ff:ff     ARP
> > > Who has 206.234.219.88?  Tell 206.234.219.88
> > >       2 0.000981    08:00:3e:28:7a:b8     ff:ff:ff:ff:ff:ff     ARP
> > > Who has 206.234.219.88?  Tell 206.234.219.88
> > >       3 0.028756    08:00:3e:28:7a:b8     ff:ff:ff:ff:ff:ff     ARP
> > > Who has 206.234.219.89?  Tell 206.234.219.88
> > >       4 116645.841622 00:03:47:02:64:8c     08:00:3e:28:7a:b8
> > > ARP      206.234.219.89 is at 00:03:47:02:64:8c
> > >       5 0.844230    08:00:3e:28:7a:b8     ff:ff:ff:ff:ff:ff     ARP
> > > Who has 206.234.219.89?  Tell 206.234.219.88
> > >       6 116646.657181 00:03:47:02:64:8c     08:00:3e:28:7a:b8
> > > ARP      206.234.219.89 is at 00:03:47:02:64:8c
> > >       7 1.659914    08:00:3e:28:7a:b8     ff:ff:ff:ff:ff:ff     ARP
> > > Who has 206.234.219.89?  Tell 206.234.219.88
> > >       8 116647.472966 00:03:47:02:64:8c     08:00:3e:28:7a:b8
> > > ARP      206.234.219.89 is at 00:03:47:02:64:8c
> > >       9 2.475597    08:00:3e:28:7a:b8     ff:ff:ff:ff:ff:ff     ARP
> > > Who has 206.234.219.89?  Tell 206.234.219.88
> > >      10 116648.288733 00:03:47:02:64:8c     08:00:3e:28:7a:b8
> > > ARP      206.234.219.89 is at 00:03:47:02:64:8c
> > >      11 9.519239    00000000.00034702648c 00000000.ffffffffffff NCP
> > > [Malformed Packet]
> > >
> > > According to this capture, the viper is broadcasting ARP requests and
> > > the 'server' is responding, but the viper is not seeing the response.
> > > I'm guessing that I don't have eCos configured properly, since ping
> > > works in RedBoot.  Before I upgraded to eCos 2.0, ping_test.exe worked,
> > > but the response time was occasionally very slow.  I have also tried
> > > running ftp_test.exe with the eCos 2.0 code which also fails during the
> > > ARP procedure.
> > >
> > > Any suggestions?
> >
> > Try turning on some debugging in the eCos network stack to see what it's
> > getting.  I tested the network code (I'm sure I tried the new network
> > stack on this board) and it worked fine.
> >
> > As for your other problems (slow FTP, etc), this will also be fixed if
> > you want to revert to the "old" network stack.



-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Re: [ECOS] Network problem with eCos 2.0 and Viper

[Paul Randall]

Gary Thomas wrote:

> On Fri, 2002-06-07 at 12:45, Paul Randall wrote:
> > Hi Gary,
> >
> > I compiled eCos with the "old" network stack (i.e. Open BSD) and I get the
> > same problem (ARPs are sent out but the responses from the host are not
> > recognized) that I did with the new network stack.
> >
> > I set a breakpoint in the fec_eth_int() interrupt processing routine in
> > if_fec.c and the breakpoint was not hit once during ping_test.exe (for
> > transmit or receive interrupts).  I figured that this is because the
> > interrupts were not enabled properly.  While stepping through the
> > fec_eth_init() function, execution skipped over the section of code that sets
> > up the interrupts because CYGINT_IO_ETH_INT_SUPPORT_REQUIRED was not defined
> > for if_fec.c.  CYGINT_IO_ETH_INT_SUPPORT_REQUIRED is defined in
> > io_eth_drivers.h (because CYGPKG_IO_ETH_DRIVERS_NET implements it), but this
> > header file is not included in if_fec.c so the creation of interrupts is not
> > done.
> >
> > I noticed that a lot of the other if_*.c files have the
> > <pkgconf/io_eth_drivers.h> include file.  Shouldn't if_fec.c have it too?
> >
> > I looked back to the if_fec.c in eCos version 1.3.1 and the creation of
> > interrupts only depends on the CYGPKG_NET define which is probably why the
> > ping_test worked for me with that version.
> >
>
> This is a recent change (not by me) which may have broken some drivers.
> Does adding the include file <pkgconf/io_eth_drivers.h> fix the problem?

Yes.  The Viper can now see the response to the ARP using either stack.

However, I think I found another problem.  When I configure eCos with the old
network stack, the stack gets a response to all of the pings.  With the new stack,
every other ping times out.  I can see all the ICMP replies with the Ethereal
analyzer, but the stack indicates a timeout for half of them.

Best regards,

Paul Randall
Delta Information Systems


-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss