From: Gary Thomas <gary@mlbassoc.com>
To: Antoine Zen-Ruffinen <antoine.zen@gmail.com>
Cc: eCos Discussion <ecos-discuss@ecos.sourceware.org>
Subject: Re: [ECOS] Problem with TCP/IP stack
Date: Fri, 11 Jan 2008 16:46:00 -0000 [thread overview]
Message-ID: <47879D3C.6050300@mlbassoc.com> (raw)
In-Reply-To: <2cbbd8de0801110838j6528edqa3c81db7bcdc8cf1@mail.gmail.com>
Antoine Zen-Ruffinen wrote:
> Thank you Gary, Thank you Andrew. You saved my week-end!!!! Thank's a lot !!
Applause not necessary :-) A 2005 Bordeaux premier-cru will do nicely!
> 2008/1/11, Antoine Zen-Ruffinen <antoine.zen@gmail.com>:
>> IT WORK NOW!!!!!
>>
>> 2008/1/11, Gary Thomas <gary@mlbassoc.com>:
>>> 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 <gary@mlbassoc.com>:
>>>>> 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 <gary@mlbassoc.com>:
>>>>>>> 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 <antoine.zen@gmail.com>:
>>>>>>>>> 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 <cyg/hal/hal_cache.h>
>>>>>>>>> #include <cyg/io/pci.h>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 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 <antoine.zen@gmail.com>:
>>>>>>>>>> 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 <antoine.zen@gmail.com>:
>>>>>>>>>>> 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 <gary@mlbassoc.com>:
>>>>>>>>>>>> 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 <gary@mlbassoc.com>:
>>>>>>>>>>>>>> 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
------------------------------------------------------------
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
next prev parent reply other threads:[~2008-01-11 16:46 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-01-10 13:09 Antoine Zen-Ruffinen
2008-01-10 13:18 ` Gary Thomas
[not found] ` <2cbbd8de0801100544j62d5b5ecl75969aaec1da5122@mail.gmail.com>
2008-01-10 13:55 ` Gary Thomas
2008-01-10 14:15 ` Antoine Zen-Ruffinen
2008-01-10 15:32 ` Antoine Zen-Ruffinen
2008-01-11 8:48 ` Antoine Zen-Ruffinen
2008-01-11 12:38 ` Antoine Zen-Ruffinen
2008-01-11 12:47 ` Gary Thomas
2008-01-11 12:52 ` Andrew Lunn
2008-01-11 15:43 ` Antoine Zen-Ruffinen
2008-01-11 15:59 ` Gary Thomas
2008-01-11 16:08 ` Antoine Zen-Ruffinen
2008-01-11 16:29 ` Gary Thomas
2008-01-11 16:38 ` Antoine Zen-Ruffinen
2008-01-11 16:39 ` Antoine Zen-Ruffinen
2008-01-11 16:46 ` Gary Thomas [this message]
-- strict thread matches above, loose matches on Subject: below --
2002-07-18 22:44 [ECOS] Problem with TCP/IP Stack Your Name
2001-01-26 10:47 [ECOS] problem with TCP/IP stack Gary Guangyu Pei
2001-01-26 13:46 ` Gary Thomas
2001-01-26 16:39 ` Gary Guangyu Pei
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=47879D3C.6050300@mlbassoc.com \
--to=gary@mlbassoc.com \
--cc=antoine.zen@gmail.com \
--cc=ecos-discuss@ecos.sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).