From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17129 invoked by alias); 11 Jan 2008 16:39:01 -0000 Received: (qmail 17000 invoked by uid 22791); 11 Jan 2008 16:38:59 -0000 X-Spam-Check-By: sourceware.org Received: from fg-out-1718.google.com (HELO fg-out-1718.google.com) (72.14.220.159) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 11 Jan 2008 16:38:41 +0000 Received: by fg-out-1718.google.com with SMTP id l27so1122854fgb.44 for ; Fri, 11 Jan 2008 08:38:36 -0800 (PST) Received: by 10.86.81.14 with SMTP id e14mr3129576fgb.42.1200069516795; Fri, 11 Jan 2008 08:38:36 -0800 (PST) Received: by 10.86.80.9 with HTTP; Fri, 11 Jan 2008 08:38:36 -0800 (PST) Message-ID: <2cbbd8de0801110838j6528edqa3c81db7bcdc8cf1@mail.gmail.com> Date: Fri, 11 Jan 2008 16:39:00 -0000 From: "Antoine Zen-Ruffinen" To: "Gary Thomas" Cc: "eCos Discussion" In-Reply-To: <2cbbd8de0801110837l18fcd525ub67bb4d8d5b78087@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <2cbbd8de0801100509x43959b34ka8e8e6f35dd081e5@mail.gmail.com> <2cbbd8de0801100732s602930faj583502f8caf2633d@mail.gmail.com> <2cbbd8de0801110047i49478a2fy705443f4505fcd14@mail.gmail.com> <2cbbd8de0801110438ld37c75bpea97698811a5bc5d@mail.gmail.com> <47876536.8070800@mlbassoc.com> <2cbbd8de0801110743q567448d7l872973b5921a2a4@mail.gmail.com> <47879231.7020205@mlbassoc.com> <2cbbd8de0801110807k2800c80fmd6f6b9c6a5717723@mail.gmail.com> <47879930.8010306@mlbassoc.com> <2cbbd8de0801110837l18fcd525ub67bb4d8d5b78087@mail.gmail.com> X-IsSubscribed: yes Mailing-List: contact ecos-discuss-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: ecos-discuss-owner@ecos.sourceware.org Subject: Re: [ECOS] Problem with TCP/IP stack X-SW-Source: 2008-01/txt/msg00069.txt.bz2 Thank you Gary, Thank you Andrew. You saved my week-end!!!! Thank's a lot !! Antoine 2008/1/11, Antoine Zen-Ruffinen : > IT WORK NOW!!!!! > > 2008/1/11, Gary Thomas : > > Antoine Zen-Ruffinen wrote: > > > Yes i have CYGIMP_HAL_INTERRUPTS_CHAIN = true in configtool. Does I > > > need something else ? My target is i386-PC. > > > > That just says that your HAL knows *how* to managed chained interrupts. > > > > You also need CYGIMP_KERNEL_INTERRUPTS_CHAIN, so the kernel will > > support chained interrupts for ISRs. > > > > > 2008/1/11, Gary Thomas : > > >> Antoine Zen-Ruffinen wrote: > > >>> Ok, I am trying to do that. But if the ISR of my fist interface return > > >>> 0, the ISR of the second interface is not called. Does it nead to have > > >>> 2 different ISR routine or the same with different parameter is enough > > >>> ? > > >> You can use the same ISR with different parameters. > > >> > > >> Do you have interrupt chaining enabled? > > >> Does your HAL properly support chained interrupts? (what's your target?) > > >> > > >>> 2008/1/11, Gary Thomas : > > >>>> Antoine Zen-Ruffinen wrote: > > >>>>> Ok, I found the problem but I dont' know how to solve it: My two NIC > > >>>>> are sharing the same interrupt. So when the second NIC do an > > >>>>> interrupt, it is handel like it is the first NIC that interrupt. > > >>>>> > > >>>>> Does someone know how to solve such an issue ? > > >>>>> > > >>>> The key is to make your interrupt handler (ISR) tell the upper > > >>>> layers which board did it. This is reflected in the (struct eth_drv_sc *) > > >>>> parameter that you pass upstream. Somehow, your driver will have > > >>>> to keep track of these (there is one such structure per physical > > >>>> device entity), then determine which board is responsible and > > >>>> use that information to decide which device (i.e. structure) to use. > > >>>> > > >>>> If you're using the same interrupt for both devices, surely you > > >>>> have Interrupt Chaining turned on in eCos? This allows for multiple > > >>>> ISR/DSR pairs to be registered for the same interrupt. eCos will > > >>>> call these ISR functions until one of them returns that it had > > >>>> handled the interrupt. This could be used to easily handle your > > >>>> situation. > > >>>> > > >>>>> 2008/1/11, Antoine Zen-Ruffinen : > > >>>>>> Some new discover : If a use only one of the two NIC I have on my > > >>>>>> system, everything work fine. When using two NIC, interrupts all the > > >>>>>> time, even if no network activity, even if doing nothing and ARP > > >>>>>> response are not catch by network stack. So the problem is a conflict > > >>>>>> between both interfaces. Here is my driver declaration (for the i386 > > >>>>>> platform), maybe something wrong there : > > >>>>>> > > >>>>>> #include > > >>>>>> #include > > >>>>>> > > >>>>>> > > >>>>>> static cyg_bool > > >>>>>> find_dp83816_match_func(cyg_uint16 v, cyg_uint16 d, cyg_uint32 c, void *p) > > >>>>>> { > > >>>>>> return ((v == 0x100B) && (d == 0x0020)); > > >>>>>> } > > >>>>>> > > >>>>>> cyg_pci_device_id devid = CYG_PCI_NULL_DEVID; > > >>>>>> static void > > >>>>>> _i386_pc_eth_init(dp83816_priv_data_t *dp) > > >>>>>> { > > >>>>>> > > >>>>>> cyg_pci_device dev_info; > > >>>>>> > > >>>>>> > > >>>>>> if (cyg_pci_find_matching( &find_dp83816_match_func, NULL, &devid )) { > > >>>>>> cyg_pci_get_device_info(devid, &dev_info); > > >>>>>> cyg_pci_translate_interrupt(&dev_info, &dp->interrupt); > > >>>>>> dp->base = (cyg_uint8 *)(dev_info.base_map[0] & ~1); > > >>>>>> diag_printf("DP83816 at %p, interrupt: %x\n", dp->base, dp->interrupt); > > >>>>>> } > > >>>>>> } > > >>>>>> > > >>>>>> #undef CYGHWR_NS_DP83816_PLF_INIT > > >>>>>> #define CYGHWR_NS_DP83816_PLF_INIT(dp) _i386_pc_eth_init(dp) > > >>>>>> > > >>>>>> // Align buffers on a cache boundary > > >>>>>> #define RxBUFSIZE (CYGNUM_DEVS_ETH_I386_PC_DP83816_RxNUM * _DP83816_BUFSIZE) > > >>>>>> #define TxBUFSIZE (CYGNUM_DEVS_ETH_I386_PC_DP83816_TxNUM * _DP83816_BUFSIZE) > > >>>>>> static unsigned char dp83816_eth0_rxbufs[RxBUFSIZE] > > >>>>>> __attribute__((aligned(HAL_DCACHE_LINE_SIZE))); > > >>>>>> static unsigned char dp83816_eth0_txbufs[TxBUFSIZE] > > >>>>>> __attribute__((aligned(HAL_DCACHE_LINE_SIZE))); > > >>>>>> static dp83816_bd_t > > >>>>>> dp83816_eth0_rxbd[CYGNUM_DEVS_ETH_I386_PC_DP83816_RxNUM] > > >>>>>> __attribute__((aligned(HAL_DCACHE_LINE_SIZE))); > > >>>>>> static dp83816_bd_t > > >>>>>> dp83816_eth0_txbd[CYGNUM_DEVS_ETH_I386_PC_DP83816_TxNUM] > > >>>>>> __attribute__((aligned(HAL_DCACHE_LINE_SIZE))); > > >>>>>> > > >>>>>> static unsigned char dp83816_eth1_rxbufs[RxBUFSIZE] > > >>>>>> __attribute__((aligned(HAL_DCACHE_LINE_SIZE))); > > >>>>>> static unsigned char dp83816_eth1_txbufs[TxBUFSIZE] > > >>>>>> __attribute__((aligned(HAL_DCACHE_LINE_SIZE))); > > >>>>>> static dp83816_bd_t > > >>>>>> dp83816_eth1_rxbd[CYGNUM_DEVS_ETH_I386_PC_DP83816_RxNUM] > > >>>>>> __attribute__((aligned(HAL_DCACHE_LINE_SIZE))); > > >>>>>> static dp83816_bd_t > > >>>>>> dp83816_eth1_txbd[CYGNUM_DEVS_ETH_I386_PC_DP83816_TxNUM] > > >>>>>> __attribute__((aligned(HAL_DCACHE_LINE_SIZE))); > > >>>>>> > > >>>>>> > > >>>>>> // eth0 delacration > > >>>>>> char _i386_pc_eth0_ESA[6]; > > >>>>>> static dp83816_priv_data_t dp83816_eth0_priv_data = { > > >>>>>> "eth0_esa", > > >>>>>> _i386_pc_eth0_ESA, > > >>>>>> CYGNUM_DEVS_ETH_I386_PC_DP83816_RxNUM, // Number of Rx buffers > > >>>>>> dp83816_eth0_rxbufs, // Rx buffer space > > >>>>>> dp83816_eth0_rxbd, // Rx buffer headers > > >>>>>> CYGNUM_DEVS_ETH_I386_PC_DP83816_TxNUM, // Number of Tx buffers > > >>>>>> dp83816_eth0_txbufs, // Tx buffer space > > >>>>>> dp83816_eth0_txbd, // Tx buffer headers > > >>>>>> }; > > >>>>>> > > >>>>>> ETH_DRV_SC(dp83816_sc0, > > >>>>>> &dp83816_eth0_priv_data, // Driver specific data > > >>>>>> "eth0", > > >>>>>> dp83816_start, > > >>>>>> dp83816_stop, > > >>>>>> dp83816_control, > > >>>>>> dp83816_can_send, > > >>>>>> dp83816_send, > > >>>>>> dp83816_recv, > > >>>>>> dp83816_deliver, // "pseudoDSR" called from fast net thread > > >>>>>> dp83816_poll, // poll function, encapsulates ISR and DSR > > >>>>>> dp83816_int_vector); > > >>>>>> > > >>>>>> NETDEVTAB_ENTRY(dp83816_netdev0, > > >>>>>> "eth0", > > >>>>>> dp83816_init, > > >>>>>> &dp83816_sc0); > > >>>>>> > > >>>>>> // eth1 delacration > > >>>>>> char _i386_pc_eth1_ESA[6]; > > >>>>>> static dp83816_priv_data_t dp83816_eth1_priv_data = { > > >>>>>> "eth1_esa", > > >>>>>> _i386_pc_eth1_ESA, > > >>>>>> CYGNUM_DEVS_ETH_I386_PC_DP83816_RxNUM, // Number of Rx buffers > > >>>>>> dp83816_eth1_rxbufs, // Rx buffer space > > >>>>>> dp83816_eth1_rxbd, // Rx buffer headers > > >>>>>> CYGNUM_DEVS_ETH_I386_PC_DP83816_TxNUM, // Number of Tx buffers > > >>>>>> dp83816_eth1_txbufs, // Tx buffer space > > >>>>>> dp83816_eth1_txbd, // Tx buffer headers > > >>>>>> }; > > >>>>>> > > >>>>>> ETH_DRV_SC(dp83816_sc1, > > >>>>>> &dp83816_eth1_priv_data, // Driver specific data > > >>>>>> "eth1", > > >>>>>> dp83816_start, > > >>>>>> dp83816_stop, > > >>>>>> dp83816_control, > > >>>>>> dp83816_can_send, > > >>>>>> dp83816_send, > > >>>>>> dp83816_recv, > > >>>>>> dp83816_deliver, // "pseudoDSR" called from fast net thread > > >>>>>> dp83816_poll, // poll function, encapsulates ISR and DSR > > >>>>>> dp83816_int_vector); > > >>>>>> > > >>>>>> NETDEVTAB_ENTRY(dp83816_netdev1, > > >>>>>> "eth1", > > >>>>>> dp83816_init, > > >>>>>> &dp83816_sc1); > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> 2008/1/10, Antoine Zen-Ruffinen : > > >>>>>>> The previous post "[ECOS] Cannot sendto multicast using FreeBSD stack" > > >>>>>>> put me on the way!! > > >>>>>>> > > >>>>>>> No IP packet are send, but ARP is done. But it seem that the stack > > >>>>>>> doesn't get the ARP reply witch is on the wire. When calling send(), > > >>>>>>> for the fist calls, send() return > 0, but with errno=2 (No such > > >>>>>>> entry) then send() return -1 wiht erron=364 (Host is down). Can this > > >>>>>>> be because I have 2 NIC that share the same interrupt ? > > >>>>>>> > > >>>>>>> 2008/1/10, Antoine Zen-Ruffinen : > > >>>>>>>> Sorry for the preceding message that was not send to the list, little > > >>>>>>>> mistake from me (cliqued "reply" and not "reply to all"). > > >>>>>>>> > > >>>>>>>> Yes my application print about DHCP transaction and it is ok. I have > > >>>>>>>> added some prints in every driver function in order to trace what it > > >>>>>>>> is doing. The output is interesting : > > >>>>>>>> 1) The NIC is making interrupts all the time > > >>>>>>>> 2) The network stack never call the send() function. > > >>>>>>>> > > >>>>>>>> Here is the output : > > >>>>>>>> RedBoot> load -m tftp -h 192.168.165.18 debugProg > > >>>>>>>> Entry point: 0x00200000, address range: 0x00200000-0x00238840 > > >>>>>>>> RedBoot> go > > >>>>>>>> [cyg_net_init] Init: mbinit(0x00000000) > > >>>>>>>> [cyg_net_init] Init: cyg_net_init_devs(0x00000000) > > >>>>>>>> Init device 'eth0' > > >>>>>>>> DP83816 at 0x0000e100, interrupt: 2a > > >>>>>>>> DP83816 - get ESA from EEPROM > > >>>>>>>> DP83816 - ESA: 00:00:24:c8:1d:6c > > >>>>>>>> Init device 'eth1' > > >>>>>>>> DP83816 at 0x0000e200, interrupt: 2a > > >>>>>>>> DP83816 - get ESA from EEPROM > > >>>>>>>> DP83816 - ESA: 00:00:24:c8:1d:6d > > >>>>>>>> [cyg_net_init] Init: loopattach(0x00000000) > > >>>>>>>> [cyg_net_init] Init: ifinit(0x00000000) > > >>>>>>>> [cyg_net_init] Init: domaininit(0x00000000) > > >>>>>>>> [cyg_net_init] Init: cyg_net_add_domain(0x00238000) > > >>>>>>>> New domain internet at 0x00000000 > > >>>>>>>> [cyg_net_init] Init: cyg_net_add_domain(0x002378e0) > > >>>>>>>> New domain route at 0x00000000 > > >>>>>>>> [cyg_net_init] Init: call_route_init(0x00000000) > > >>>>>>>> [cyg_net_init] Done > > >>>>>>>> Network testing program V2 > > >>>>>>>> Thread started > > >>>>>>>> Init network : DP83816 - ISR on eth0 > > >>>>>>>> [eth_drv_ioctl] Warning: Driver can't set multi-cast mode > > >>>>>>>> [eth_drv_ioctl] Warning: Driver can't set multi-cast mode > > >>>>>>>> DP83816 - can_send on eth0 : 16 > > >>>>>>>> DP83816 - send on eth0 > > >>>>>>>> DP83816 - can_send on eth0 : 15 > > >>>>>>>> DP83816 - deliver on eth0 > > >>>>>>>> DP83816 - pool on eth0 > > >>>>>>>> DP83816 - Tx Event on eth0 > > >>>>>>>> DP83816 - Rx event on eth0 > > >>>>>>>> DP83816 - recv on eth0 > > >>>>>>>> DP83816 - recv on eth0 > > >>>>>>>> DP83816 - can_send on eth0 : 16 > > >>>>>>>> DP83816 - send on eth0 > > >>>>>>>> DDP83816 - ISR on eth0 > > >>>>>>>> P83816 - can_send on eth0 : 15 > > >>>>>>>> DP83816 - deliver on eth0 > > >>>>>>>> DP83816 - pool on eth0 > > >>>>>>>> DP83816 - Tx Event on eth0 > > >>>>>>>> DP83816 - Rx event on eth0 > > >>>>>>>> DP83816 - recv on eth0 > > >>>>>>>> BOOTP[eth0] op: REQUEST > > >>>>>>>> htype: Ethernet > > >>>>>>>> hlen: 6 > > >>>>>>>> hops: 0 > > >>>>>>>> xid: 0xec511d6c > > >>>>>>>> secs: 0 > > >>>>>>>> flags: 0x80 > > >>>>>>>> hw_addr: 00:00:24:c8:1d:6c > > >>>>>>>> client IP: 0.0.0.0 > > >>>>>>>> my IP: 192.168.165.254 > > >>>>>>>> server IP: 192.168.165.1 > > >>>>>>>> gateway IP: 0.0.0.0 > > >>>>>>>> file: boots.default > > >>>>>>>> options: > > >>>>>>>> DHCP message: 3 REQUEST > > >>>>>>>> DHCP server id: 192.168.165.1 > > >>>>>>>> DHCP time 51: 43200 > > >>>>>>>> DHCP time 58: 21600 > > >>>>>>>> DHCP time 59: 37800 > > >>>>>>>> subnet mask: 255.255.255.0 > > >>>>>>>> gateway: 192.168.165.1 > > >>>>>>>> domain server: 192.168.165.1 > > >>>>>>>> domain name: v165.itslabb.bth.se. > > >>>>>>>> DHCP option: 37/55.9: 54 51 58 59 1 3 6 15 28 > > >>>>>>>> DHCP option: 39/57.2: 576 > > >>>>>>>> DHCP requested ip: 192.168.165.254 > > >>>>>>>> BOOTP[eth1] op: REPLY > > >>>>>>>> htype: Ethernet > > >>>>>>>> hlen: 6 > > >>>>>>>> hops: 0 > > >>>>>>>> xid: 0x0 > > >>>>>>>> secs: 0 > > >>>>>>>> flags: 0x0 > > >>>>>>>> hw_addr: 00:00:24:c8:1d:6d > > >>>>>>>> client IP: 10.0.0.10 > > >>>>>>>> my IP: 10.0.0.10 > > >>>>>>>> server IP: 0.0.0.0 > > >>>>>>>> gateway IP: 0.0.0.0 > > >>>>>>>> options: > > >>>>>>>> subnet mask: 255.255.255.0 > > >>>>>>>> IP broadcast: 10.0.0.255 > > >>>>>>>> gateway: 0.0.0.0 > > >>>>>>>> DP83816 - ISR on eth0 > > >>>>>>>> [eth_drv_ioctl] Warning: Driver can't set multi-cast mode > > >>>>>>>> DP83816 - can_send on eth0 : 16 > > >>>>>>>> DP83816 - send on eth0 > > >>>>>>>> DP83816 - can_send on eth0 : 15 > > >>>>>>>> [eth_drv_ioctl] Warning: Driver can't set multi-cast mode > > >>>>>>>> DP83816 - can_send on eth0 : 15 > > >>>>>>>> DP83816 - send on eth0 > > >>>>>>>> DP83816 - can_send on eth0 : 14 > > >>>>>>>> [eth_drv_ioctl] Warning: Driver can't set multi-cast mode > > >>>>>>>> DP83816 - can_send on eth1 : 16 > > >>>>>>>> DP83816 - send on eth1 > > >>>>>>>> DP83816 - can_send on eth1 : 15 > > >>>>>>>> [eth_drv_ioctl] Warning: Driver can't set multi-cast mode > > >>>>>>>> [eth_drv_ioctl] Warning: Driver can't set multi-cast mode > > >>>>>>>> DP83816 - can_send on eth1 : 15 > > >>>>>>>> DP83816 - send on eth1 > > >>>>>>>> DP83816 - can_send on eth1 : 14 > > >>>>>>>> [eth_drv_ioctl] Warning: Driver can't set multi-cast mode > > >>>>>>>> Network initalized ! > > >>>>>>>> Eth0 is up ! > > >>>>>>>> Eth1 is up ! > > >>>>>>>> socket() = 3 > > >>>>>>>> It seem that everthing is OK. start sending packets. > > >>>>>>>> A - 0> sendto() = 3 > > >>>>>>>> B - 0> Waiting for a packet > > >>>>>>>> DP83816 - deliver on eth0 > > >>>>>>>> DP83816 - pool on eth0 > > >>>>>>>> DP83816 - Tx Event on eth0 > > >>>>>>>> DP83816 - ISR on eth0 > > >>>>>>>> DP83816 - deliver on eth0 > > >>>>>>>> DP83816 - pool on eth0 > > >>>>>>>> DP83816 - ISR on eth0 > > >>>>>>>> A - 1> sendto() = 3 > > >>>>>>>> DP83816 - deliver on eth0 > > >>>>>>>> DP83816 - pool on eth0 > > >>>>>>>> DP83816 - ISR on eth0 > > >>>>>>>> DP83816 - deliver on eth0 > > >>>>>>>> DP83816 - pool on eth0 > > >>>>>>>> DP83816 - ISR on eth0 > > >>>>>>>> DP83816 - deliver on eth0 > > >>>>>>>> DP83816 - pool on eth0 > > >>>>>>>> DP83816 - ISR on eth0 > > >>>>>>>> A - 2> sendto() = 3 > > >>>>>>>> DP83816 - deliver on eth0 > > >>>>>>>> DP83816 - pool on eth0 > > >>>>>>>> DP83816 - ISR on eth0 > > >>>>>>>> DP83816 - deliver on eth0 > > >>>>>>>> DP83816 - pool on eth0 > > >>>>>>>> DP83816 - ISR on eth0 > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> 2008/1/10, Gary Thomas : > > >>>>>>>>> Please keep your replies on the eCos list! > > >>>>>>>>> > > >>>>>>>>> **EVERYONE** please get this straight. Replies made by me on the > > >>>>>>>>> eCos discussion list must be followed up on the eCos discussion list > > >>>>>>>>> unless I invite private replies. This way everyone benefits, not > > >>>>>>>>> just the interested party. Private email support consultation and > > >>>>>>>>> support is available, but only with a contract. > > >>>>>>>>> > > >>>>>>>>> Antoine Zen-Ruffinen wrote: > > >>>>>>>>>> The target platform is an embed PC with NS dp83816 NIC. I've port the > > >>>>>>>>>> eCos driver my self for the PC platform. > > >>>>>>>>>> > > >>>>>>>>>> I configure eCos with the configtool, just using the template I made > > >>>>>>>>>> and the "net" package. > > >>>>>>>>>> > > >>>>>>>>>> No, I didn't run a standard eCos network test program. But I build an > > >>>>>>>>>> redboot with this configuration. If I type ping -n 1000 -r 1 -h > > >>>>>>>>>> 192.168.165.18 (is my host PC) everything went fine ! > > >>>>>>>>> This is only partly relevant - RedBoot uses a completely different > > >>>>>>>>> network stack than normal eCos applications. Also, RedBoot does > > >>>>>>>>> not use interrupts, which the eCos stacks rely on. > > >>>>>>>>> > > >>>>>>>>>> I know that nothing was send : 1 becose network activity led doesn't > > >>>>>>>>>> blink, 2 I monitor network with Wireshark (Ethereal). the monitoring > > >>>>>>>>>> trace show the TFTP exchange and the DHCP init but nothing more. It > > >>>>>>>>>> look like this : > > >>>>>>>>>> No. Time Source Destination Protocol Info > > >>>>>>>>>> 69504 25.515675 192.168.165.18 192.168.165.253 TFTP > > >>>>>>>>>> Data Packet, Block: 452 > > >>>>>>>>>> 69505 25.516279 192.168.165.253 192.168.165.18 TFTP > > >>>>>>>>>> Acknowledgement, Block: 452 > > >>>>>>>>>> 69506 25.516289 192.168.165.18 192.168.165.253 TFTP > > >>>>>>>>>> Data Packet, Block: 453 > > >>>>>>>>>> 69507 25.516662 192.168.165.253 192.168.165.18 TFTP > > >>>>>>>>>> Error Code, Code: Not defined, Message: redboot > > >>>>>>>>>> tftp_stream_terminate > > >>>>>>>>>> 69508 25.826093 0.0.0.0 255.255.255.255 DHCP > > >>>>>>>>>> DHCP Discover - Transaction ID 0x6c1dfce9 > > >>>>>>>>>> 69511 26.074789 0.0.0.0 255.255.255.255 DHCP > > >>>>>>>>>> DHCP Discover - Transaction ID 0x6c1dfce9 > > >>>>>>>>>> 69512 26.304739 0.0.0.0 255.255.255.255 DHCP > > >>>>>>>>>> DHCP Discover - Transaction ID 0x6c1dfce9 > > >>>>>>>>>> 69514 26.451407 0.0.0.0 255.255.255.255 DHCP > > >>>>>>>>>> DHCP Request - Transaction ID 0x6c1dfde9 > > >>>>>>>>>> 69516 26.839890 Olicom_c8:1d:6c Broadcast ARP > > >>>>>>>>>> Who has 192.168.165.254? Gratuitous ARP > > >>>>>>>>>> > > >>>>>>>>> Did your eCos application print anything about the DHCP transaction? > > >>>>>>>>> I'm betting that it did not (which would imply you are having trouble > > >>>>>>>>> with receive interrupts from your driver) > > >>>>>>>>> > > >>>>>>>>>> 2008/1/10, Gary Thomas : > > >>>>>>>>>>> Antoine Zen-Ruffinen wrote: > > >>>>>>>>>>>> Hi List folks, > > >>>>>>>>>>>> > > >>>>>>>>>>>> I've a problem with the TCP/IP stack: > > >>>>>>>>>>>> - I use TFTP to load my program in redboot. That work fine. > > >>>>>>>>>>>> - My application start, call init_all_network_interfaces(), it do the > > >>>>>>>>>>>> DHCP stuff. That work fine. > > >>>>>>>>>>>> - Then I open a socket and try to send / receive data. No packet is even send. > > >>>>>>>>>>>> > > >>>>>>>>>>>> Does someone has already seen such problem ? > > >>>>>>>>>>>> Any idea ? > > >>>>>>>>>>> We'll need more data than this in order to help. > > >>>>>>>>>>> * What's the target platform? > > >>>>>>>>>>> * How did you configure eCos for your failing application? > > >>>>>>>>>>> * Have you run any of the standard eCos network test programs? > > >>>>>>>>>>> * How do you know nothing was sent? What sort of debugging > > >>>>>>>>>>> have you tried so far? > > >> -- > > >> ------------------------------------------------------------ > > >> Gary Thomas | Consulting for the > > >> MLB Associates | Embedded world > > >> ------------------------------------------------------------ > > >> > > > > > > > > > -- > > ------------------------------------------------------------ > > Gary Thomas | Consulting for the > > MLB Associates | Embedded world > > ------------------------------------------------------------ > > > -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss