You can subscribe to this list here.
2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(2) |
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2001 |
Jan
(1) |
Feb
|
Mar
|
Apr
(5) |
May
(23) |
Jun
(26) |
Jul
(26) |
Aug
(9) |
Sep
(8) |
Oct
(2) |
Nov
(8) |
Dec
(2) |
2002 |
Jan
(6) |
Feb
(1) |
Mar
(1) |
Apr
(1) |
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
(3) |
Nov
(2) |
Dec
|
2003 |
Jan
(1) |
Feb
(1) |
Mar
(3) |
Apr
(2) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(3) |
Nov
|
Dec
|
2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
2009 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
From: Ormund W. <or...@pa...> - 2004-11-20 05:58:28
|
On Fri, 2004-07-02 at 06:55, Fredrik wrote: > We have ported uC/IP to eCos which is a smallish TCP/IP stack developed > in ANSI C for embedded systems. > It supports e.g. PPP and we have been using it successfully for more > than a year. > During this time fixed some really serious bugs and now it seems to work > very well. We have been using PPP/TCP/IP over a GPRS modem (it works > fine in the contries we have tried, e.g. Sweden, UK, even Brazil!). > > If anyone are interested, we would like to contribute the bugfixes and > eCos port. The licence is BSD since the code is based on the BSD stack. > The project is hosted at "http://sourceforge.net/projects/ucip/" but > unfortunately nothing seems to have happend for the last few years. > Maybe its better to contribute the code to the eCos repository? Maybe > the existing BSD-based eCos stacks and the Siemens stack make this stack > superfluous? > > Here follows a simple example of a memory benchmark for the files in > uC/IP for different sections (using arm-elf-gcc 3.4.0) to compare with > other BSD-based stacks perhaps. > (The stack does not allocate any dynamic memory, it handles all memory > allocation internally with static memory, which is a feature.) > > File name text data bss rodata > ------------------------------ ---------- ---------- ---------- ---------- > net_uCIP_InetAddr.o 568 0 0 0 > net_uCIP_devio.o 16 0 0 0 > net_uCIP_net.o 592 22 1293 44 > net_uCIP_netaddrs.o 172 28 0 0 > net_uCIP_netarp.o 2564 4 1680 116 > net_uCIP_netauth.o 2840 2 284 328 > net_uCIP_netbootp.o 0 0 0 0 > net_uCIP_netbuf.o 6012 0 69640 224 > net_uCIP_netchap.o 3340 76 176 420 > net_uCIP_netchat.o 1408 0 4 0 > net_uCIP_netchpms.o 0 0 0 0 > net_uCIP_netconf.o 0 0 0 0 > net_uCIP_netdebug.o 52 0 0 0 > net_uCIP_netdhcp.o 2712 0 0 0 > net_uCIP_neteth.o 552 0 38 24 > net_uCIP_netether.o 692 4 32 0 > net_uCIP_netfsm.o 3296 0 4 0 > net_uCIP_neticmp.o 1656 32 184 96 > net_uCIP_netip.o 2012 0 90 12 > net_uCIP_netipcp.o 5244 120 192 200 > net_uCIP_netlcp.o 9836 188 700 456 > net_uCIP_netmagic.o 8 0 0 0 > net_uCIP_netmd5.o 3636 64 0 0 > net_uCIP_netpap.o 1892 60 48 204 > net_uCIP_netppp.o 5800 44 13412 712 > net_uCIP_netrand.o 316 4 16 0 > net_uCIP_netresolv.o 4492 38 628 156 > net_uCIP_netsock.o 904 2 1408 0 > net_uCIP_netsocka.o 196 0 0 0 > net_uCIP_nettcp.o 15200 178 4392 1052 > net_uCIP_nettimer.o 1304 0 16532 20 > net_uCIP_netudp.o 2656 4 452 128 > net_uCIP_netvj.o 0 0 0 0 > net_uCIP_os.o 1284 0 3012 164 > net_uCIP_trace.o 408 0 0 280 > ------------------------------ ---------- ---------- ---------- ---------- > TOTAL 81660 870 114217 4636 > > (I'm sure the mem size could be reduced. This is _all_ code [not > linked], and also the amount of internal data buffers could be reduced.) > > /Best Regards, > Hi Fredrik Would you consider contributing your code changes back to the uC/IP project? I know there has not been much activity in the last years but it is still regularaly downloaded so many are still finding it useful. I was considering using this stack on the Atmel AVR uControllers with an OS called AvrX and the size of the above modules look very good to me. Regards -- Ormund Williams <or...@pa...> ORMLAB |
From: <ro...@mo...> - 2003-10-06 05:45:05
|
Hi Guy, Not actively, however still on the list and still hoping to make use of the stack in some interesting potential projects for a customer later in the year or early next. I've got a copy of uCOS-II which I still haven't found the time to dig into. Also I left a message with some corporate guys from Zilog just last week when attending an seminar on their new range of eZ80 micros. They currently provide a commercial stack which seems to include run-time royalties, so I thought they 'may' be interested in the project themselves. Havn't heard anything from them but must expect the corporate cogs to move rather slowly. I'll let the list now if anything eventuates. Regards, Robert Dickenson. |
From: Guy L. <gu...@gu...> - 2003-10-05 23:30:30
|
Ian McLean wrote: >Just a test to see that the mailing list is still working seeing as mail on >this list is almost dead these days .... > > > This list is working but it never was used much. Most of the discussions have taken place on uco...@ya... but even those have been pretty quiet lately, at least regarding uC/IP. But I'm also curious. Is anyone here actively working with uC/IP or actively supporting a uC/IP derived installation or perhaps planning to work with uC/IP or something similar in the near future? Thanks. Guy -- "Embedded and Open Source Solutions" Guy Lancaster Computer Consultants mailto:gu...@gu... http://guylancaster.com |
From: Ian M. <ia...@op...> - 2003-10-05 11:19:57
|
Just a test to see that the mailing list is still working seeing as mail on this list is almost dead these days .... |
From: Felipe M. P. <ma...@ic...> - 2003-04-07 05:12:38
|
In fact, it's part of my research project. I have to write this data into a table, about uC/IP and other implementations. The compliance could be partial, but fragmentation is considered relevant. thank you, []s -- Felipe > Message: 1 > Date: Sun, 06 Apr 2003 18:52:30 -0700 > From: Guy Lancaster <gu...@gu...> > To: uC/IP Developer List <uci...@li...> > Subject: Re: [Ucip-devel] RCF 1122 compliance > > Felipe Massia Pereira wrote: > > >Hello, > > > >as part of my research, I'd like to know if uC/IP is compliant with RFC > >1122. Thanks in advance, > > > > > Hi Felipe, > > I finally got some time to skim through RFC1122 and the simple answer > would be no, uC/IP is not compliant. However a more useful question > would be how compliant is it and to that I would guess that it's largely > compliant on those features that it supports but it probably supports > only between 50 and 70% of the specified features.. It was developed > largely straight from the RFCs but features covered in 1122 like > fragmentation, routing, and many of the ICMP features were not needed > and therefore were not implemented. > > If you'd like to explain why you're asking we may be able to help more. > > Take care. > > Guy > > -- > "Embedded and Open Source Solutions" > Guy Lancaster Computer Consultants > mailto:gu...@gu... > http://guylancaster.com |
From: Guy L. <gu...@gu...> - 2003-04-07 01:52:21
|
Felipe Massia Pereira wrote: >Hello, > >as part of my research, I'd like to know if uC/IP is compliant with RFC >1122. Thanks in advance, > > Hi Felipe, I finally got some time to skim through RFC1122 and the simple answer would be no, uC/IP is not compliant. However a more useful question would be how compliant is it and to that I would guess that it's largely compliant on those features that it supports but it probably supports only between 50 and 70% of the specified features.. It was developed largely straight from the RFCs but features covered in 1122 like fragmentation, routing, and many of the ICMP features were not needed and therefore were not implemented. If you'd like to explain why you're asking we may be able to help more. Take care. Guy -- "Embedded and Open Source Solutions" Guy Lancaster Computer Consultants mailto:gu...@gu... http://guylancaster.com |
From: Felipe M. P. <ma...@ic...> - 2003-03-29 05:54:13
|
Hello, as part of my research, I'd like to know if uC/IP is compliant with RFC 1122. Thanks in advance, -- Felipe CS MSc student at IC-Unicamp http://www.ic.unicamp.br/~massia/ |
From: Felipe M. <fel...@ya...> - 2003-03-29 05:38:32
|
Hello, I'm new to the list. As part of my research, I'd like to know if uC/IP is compliant with the requirements of RFC 1122. thanks in advance, -- Felipe CS MSc Student at IC-UNICAMP http://www.ic.unicamp.br/~massia/ |
From: Dan H. <da...@we...> - 2003-03-24 11:07:51
|
Hi, We're currently porting the uC/IP stack to eCos for use with GPRS. There seems to be very low activity on this project here, so we're wondering if it's of any use not to bias the port close towards eCos, making it, if not incompatible, atleast non-conformant to the current state of the uCIP sources. That is, should we try improve the uCIP stack or should we try to make a good eCos stack? Dan --=20 Dan Hovang da...@we... +46 733 451 427 WeSpot AB Scheleev=E4gen 19c 223 70 Lund, Sweden |
From: Roberto J. D. <dr...@in...> - 2003-02-03 16:33:49
|
Hi there, I am looking for information on what platforms (software and hardware) does uC/IP runs. Only uC/OS? What about hardware? Is there any online list of supported systems? Thanks in advance, -- Roberto Jung Drebes <dr...@in...> Porto Alegre, RS - Brasil http://www.inf.ufrgs.br/~drebes/ |
From: M. E. Y. <er...@te...> - 2003-01-10 15:19:25
|
Does anybody implemented an embedded GPRS application before or does anybody ported uc/ip to m16c microcontroller? I need this in my student project. Thanks.. M. Erhan Yigitbasi |
From: Toney_Mathew <Toney_Mathew@Satyam.com> - 2002-11-11 05:50:35
|
Hello, I have finished porting PPP and tested it successfully on the OSEC OS. The code used was the ucos one, authored by Guy Lancaster. We have started porting the IP module but are not sure how to test it. Would you get some tips on the same? A sample application, usable on both sides would be handy. We plan to port the TCP module only after testing and completing the IP module. Would it be better if we finished porting TCP too before testing? Regards, Toney ************************************************************************** This email (including any attachments) is intended for the sole use of the intended recipient/s and may contain material that is CONFIDENTIAL AND PRIVATE COMPANY INFORMATION. Any review or reliance by others or copying or distribution or forwarding of any or all of the contents in this message is STRICTLY PROHIBITED. If you are not the intended recipient, please contact the sender by email and delete all copies; your cooperation in this regard is appreciated. ************************************************************************** |
From: Guy L. <gu...@gu...> - 2002-11-10 22:56:43
|
Vitus Jensen wrote: >BTW: what would it take to add routing to the stack? My device has 5 usable >SIOs for PPP... > > Off the top of my head I would say that it wouldn't take much but that depends on your needs. In my mind the user interface would be the most difficult part of the problem. The ability to select an IP interface based on an address is trivial. Managing the lookup table is not but need not be a difficult problem. For example, what do you do if an interface goes down? With a static table you would ignore it but perhaps you want to detect the condition and do something more user friendly about it. Does this start to answer your question? Guy -- "Embedded and Open Source Solutions" Guy Lancaster Computer Consultants mailto:gu...@gu... http://guylancaster.com |
From: Kavaldjian S. <sev...@si...> - 2002-10-31 16:58:38
|
-----Urspr=FCngliche Nachricht----- Von: Kavaldjian Sevan=20 Gesendet: Donnerstag, 31. Oktober 2002 17:55 An: 'lis...@li...' Betreff: Porting uC/IP to CMX(RTOS)!! Hi! Please could you tell me if someone already has tryed to port uC/IP to = CMX (RTOS). If yes please send it to me as soon as possible. Is there someone who could tell me what I have to consider when I am = Porting to CMX and how long it is approximatly going to take me? Regards, Sevan |
From: Vitus J. <je...@ho...> - 2002-10-29 17:01:34
|
Hello all! Fixed it by adding a call to SioIf.start() in StartupNet(). There are now LCP packets appearing on the SIO. Hurray! BTW: what would it take to add routing to the stack? My device has 5 usable SIOs for PPP... Bye, Vitus On Tue, 29 Oct 2002 09:55:40 +0100 (CET), Vitus Jensen wrote: > Hej! > > I'm trying to port uC/IP to our own multithreaded OS (romable, Toshiba CPU). > There were some changes needed (nested comments, and we can's live with > initialized variables) but it compiles OK now. Lots of warnings, though. > > Anyway, I want to test the thing now. TCP/IP over PPP and I have a PPP > analyser connected to the serial line. I would expect that once the stack is > started there will appear bytes on the serial line. But I can't find > anything. :-( > > And before PPP had done it's task any IP code does obviously fail with error > -5, Invalid configuration, because the local address is unknown. > Any hints how I could get things going? > > > > Here is my code (error checking removed): > ============================================= > int StartupNet(unsigned short chn) > { > repeat = 1; > > memset(&SioIf, 0, sizeof(SioIf)); > SioIf.nPortNum = chn; > SioIf.nBaudRate = 19200; > SIO_DriverEntry(&SioIf); > netInit(&SioIf); /* nBufInit, pppInit, > hdPPP = pppOpen(chn); > return 0; > } > int StopNet(int reason) > { > repeat = 0; > pppClose(hdPPP) > SioIf.stop(&SioIf); > return 0; > } > int IpTest(void) > { > StartupNet(3); > msleep(5000); > StopNet(0); > return 0; > } > ============================================= > > By[t]e, > Vitus > > -- > Dipl-Ing Vitus Jensen, R&D > Hoeft & Wessel AG, Hannover > EMail: je...@ho... > Tel: +49-511-6102-336, Fax: -435 > |
From: Vitus J. <je...@ho...> - 2002-10-29 08:56:57
|
Hej! I'm trying to port uC/IP to our own multithreaded OS (romable, Toshiba CPU). There were some changes needed (nested comments, and we can's live with initialized variables) but it compiles OK now. Lots of warnings, though. Anyway, I want to test the thing now. TCP/IP over PPP and I have a PPP analyser connected to the serial line. I would expect that once the stack is started there will appear bytes on the serial line. But I can't find anything. :-( And before PPP had done it's task any IP code does obviously fail with error -5, Invalid configuration, because the local address is unknown. Any hints how I could get things going? Here is my code (error checking removed): ============================================= int StartupNet(unsigned short chn) { repeat = 1; memset(&SioIf, 0, sizeof(SioIf)); SioIf.nPortNum = chn; SioIf.nBaudRate = 19200; SIO_DriverEntry(&SioIf); netInit(&SioIf); /* nBufInit, pppInit, hdPPP = pppOpen(chn); return 0; } int StopNet(int reason) { repeat = 0; pppClose(hdPPP) SioIf.stop(&SioIf); return 0; } int IpTest(void) { StartupNet(3); msleep(5000); StopNet(0); return 0; } ============================================= By[t]e, Vitus -- Dipl-Ing Vitus Jensen, R&D Hoeft & Wessel AG, Hannover EMail: je...@ho... Tel: +49-511-6102-336, Fax: -435 |
From: Akshay A. <Aks...@ex...> - 2002-06-10 07:01:50
|
Hi, uc/IP TCP/IP library has a echotest application used to test the tcp/ip stack. This application requires packet32.h and packet.dll library for build purpose. What is packet.dll library for ? Is the packet.dll library actually used to talk to the ethernet device driver. I am talking in case of Windows. Thanks and Regards Akshay |
From: Mads C. <MC...@vo...> - 2002-04-04 08:03:21
|
Hi everyone! Please read this Robert (hope this is not too annoying for you :-). When doing more than one listen with uC/IP we might loose a listen socket! Robert do you again have the time for making these changes to the CVS. Best wishes to you all, Mads Christiansen Partner Voxtream www.voxtream.com Create these to variables in tcpInput. struct TCPCB_s *prev, *next; Find this section and add /* Duplicate the TCB but must preserve the semaphores. */ connectSem = ntcb->connectSem; readSem = ntcb->readSem; writeSem = ntcb->writeSem; mutex = ntcb->mutex; prev = ntcb->prev; // BUGFIX, must preserve org. prev and next pointers from the free list, next = ntcb->next; // BUGFIX, else we might destroy our hash lookup table when doing more than one tcpListen! memcpy(ntcb, tcb, sizeof(TCPCB)); // Someone might want to look more carefully at this memcpy. Are there other variables that must be preserved ? /mogi ntcb->prev = prev; // BUGFIX, mogi.dk ntcb->next = next; // BUGFIX, 02.04.2002 ntcb->connectSem |
From: Mads C. <MC...@vo...> - 2002-03-04 07:06:28
|
Hi Ye li! I have only a running version of uC/IP with Ethernet support (NE2000), I haven't tried it with PPP. This means that if any of the PPP layers have any multithreaded dependent code this might be a problem. Notice that I use and older version of the uC/IP stack (one of the first with Ethernet support). There are 3 call-back functions that you must create. These are to be used as arguments to the tcpOpen() function. td = tcpOpen(receiveEvent, transmitEvent, statusEvent); The receiveEvent function will be called everytime there is anything new in the receive buffer. The first argument is the TCP Descriptor and the second argument is the number of bytes in the buffer. The transmitEvent is a bit more tricky (Craig Graham might have posted some new changes to the CVS, the disregard this). Again the first argument is the TCP Descriptor, the second argument is the number of bytes you are allowed to transmit. The last argument may not reflect the real number of bytes that you can transmit (due to buffer limitations in the TCP stack, you might only see this with Ethernet). So when you transmit data with the tcpWrite function always check to see how many bytes was really sent!!! The statusEvent function will be called everytime there is a TCP statechange for the TCP descriptor. The first argument is the TCP Descriptor. The second argument is the old TCP state and the third argument is the new TCP state. If you want to do a printf of the tcp state changes this can be done like this printf("\nuCIP: state (td %d) %s (%d) -> %s (%d)", td, tcbStates[oldState], oldState, tcbStates[newState], newState); If you are not familiar with the TCP states I recommend you read a little about TCP. If it is possible for you to run uC/IP in a multithreaded environment, please do so since this eases programming a lot! For the lastest code please see: http://ucip.sourceforge.net Best wishes, Mads >>> "ye_li" <ye...@an...> 03/04 6:38 >>> hello. I have completed multi-thread version about TCP/IP/PPP stack, but now I have some trouble in one-task version. Can you give me a completed example about it? Many thanks. Best regards Ye li 2002-03-04 |
From: Enrico M. <enr...@fa...> - 2002-02-13 12:13:32
|
hi Guys here I'm, back on track. The good news is that sourceforge approved my project: Embedded Shell. A few words about it: I went through the code of TinyTcl (an embedded version of Tcl) developed by the University of California and others, extracted only the commands interpreter and made it OS, malloc, free and file system calls independent. The RAM footprint is really small and I compiled it under VC++6.0. One can add as many commands as she/he wants. Each command, when called, receives: (argc, argv[]) The shell can be used for example in conjuction with ucip for remote control of embedded applications: a remote shell on a TCP port. The Files will be on line next week. The API's documentation will re-start soon. regards, Enrico |
From: Mads C. <MC...@vo...> - 2002-01-22 07:28:37
|
Hi everyone! Please read this Robert. Sorry about this. This is NOT a new bug to me but I never got around to = reporting it. In the udpInput function there are some memory leakage. This is especially = the case when connecting to an Ethernet with a lot of UDP broadcast and = the stack will soon run out of buffers. It seems that when an UDP broadcast packet is sent to an non listening = port the packet is just discarded but never free'd. I wonder why any of = you hasn't noticed that the stack would run out of buffers ?!? Robert do you again have the time for making these changes to the CVS. BTW. I have now been running the stack (one of the first CVS versions with = (almost) all the bugfixes) for several weeks now and it seems VERY STABLE. = I'm running the stack with the SINGLE_TASK option, this means no semaphores= and multitasking, and with the use of callback functions.=20 I think that if the stack keeps up the good work, will will probably ship = it with our product in the near future (6 months). Best wishes to you all, Mads Christiansen Partner Voxtream www.voxtream.com=20 Here is a fraction (the last part of udpInput) of my impl. (sorry about = the tabs). /* Try to find an open udp port to receive the incoming packet */ udpCB =3D udpResolveIncomingUDPCB(ntohl(ipHdr->ip_src.s_addr), = ntohs(udpHdr->dstPort)); if (udpCB =3D=3D NULL) { // Only reflect the packet if it is a = unicast!!! if (ntohl(ipHdr->ip_dst.s_addr) =3D=3D = localHost) { /* if port not open, or port is = not listening for connections from that address reflect the packet */ UDPDEBUG(("udpInput: port %ld not = open, sending icmp_error\n", udpHdr->dstPort)); icmp_error(inBuf, ICMP_UNREACH, = ICMP_UNREACH_PORT, 0); } // Free "memory" BUGFIX 22.01.02/MO= GI nFreeChain(inBuf); return; } /* Add NBuf chain to the incoming data queue for the port */ if (udpCB->tail) { udpCB->tail->next =3D alloc_udp_q(); if (udpCB->tail->next =3D=3D NULL) { goto UDP_ALLOC_FAILED; } udpCB->tail =3D udpCB->tail->next; } else { udpCB->head =3D udpCB->tail =3D alloc_udp_q(); if (udpCB->tail =3D=3D NULL) { goto UDP_ALLOC_FAILED; } } udpCB->tail->next =3D NULL; udpCB->tail->srcAddr =3D ipHdr->ip_src; udpCB->tail->srcPort =3D udpHdr->srcPort; udpCB->tail->nBuf =3D inBuf; // **** Remove IP and UDP header stuff nTrim(NULL, &udpCB->tail->nBuf, sizeof(IPHdr) + sizeof(UDPH= dr)); #if ONETASK_SUPPORT > 0 if (udpCB->receiveEvent)=20 // Data received so notify user,=20 udpCB->receiveEvent((int)(udpCB - &udps[0]), udpCB->tail->nBuf->c= hainLen);=20 #else /* finally, post a semaphore to wake up anyone waiting for data on = this UDP port */ OSSemPost(udpCB->sem); #endif =20 return; UDP_ALLOC_FAILED: UDPDEBUG(("udpInput: port %ld, out of udp queue buffers\n", udpHdr->dst= Port)); // Free "memory" BUGFIX 22.01.02/MOGI nFreeChain(inBuf); return; } |
From: Robert D. <od...@pn...> - 2002-01-12 01:32:19
|
Hi Mads, Thanks for the fix. I have modified the code with your update and will drop it into CVS shortly. I left the various unused #ifdef XXX OS_ENTER_CRITICAL(); #endif conditionals in place as I am unsure whether they are required in multitasking version and so will get back to that another time. Regards, Robert. At 01:21 PM 11/01/2002 +0100, Mads Christiansen wrote: >Hi everyone! > >Please read this Robert. > >And some days of seeking i finally found and annoying bug. >It seems that sometimes the transmit queue in the stacks gets corrupted. > >I located the error in the nTrimQ function in netbuf.c. >Actually I'm not sure if any of you guys ever will see this error since I'm running the stack in a single task. > >I would very much like you Robert to update the CVS, since my pc is not configured for the CVS anymore. > >The error will sometimes occur when nTrim is called from nTrimQ. Read the comments in the source below. > > >Best wishes to you all, > >Mads Christiansen >Partner Voxtream >www.voxtream.com > > >Here is the new nTrimQ function. > > >/* > * nTrimQ - Trim bytes from the front of a buffer queue. > * Note: The queue needs to be protected from collisions for the duration > * of this call. > * Return the number of bytes trimmed. > */ >int nTrimQ(char *dst, NBufQHdr *qh, u_int len) >{ > int st = 0; > > if (qh && qh->qHead && len) { > NBuf *n0; > int trimmed; > > /* Trim entire chains. */ > while (qh->qHead && len >= qh->qHead->chainLen) { > > if ((qh->qHead = (n0 = qh->qHead)->nextChain) == NULL) > qh->qTail = NULL; > qh->qLen--; > > n0->nextChain = NULL; > > if (dst) > { > trimmed = nTrim(dst, &n0, len); > if (dst) > dst += trimmed; > len -= trimmed; > st += trimmed; > } > else > { > len -= n0->chainLen; > st += n0->chainLen; > } > if (n0) nFreeChain(n0); > } > > /* If more to go, trim from next chain. */ > if (len && qh->qHead) { > /* > * XXX LONG CRITICAL SECTION!!! Could we pop this off the queue, > * trim it, and then replace the remainder? Do we need a semaphore? > */ > trimmed = nTrim(dst, &qh->qHead, len); > st += trimmed; > > // Update tail pointer!!! SERIOUS BUGFIX /ma...@mo... 2002.01.11 > if (qh->qLen == 1) > { > // nTrim might return a new nBuf in qh->qHead > // IF qLen == 1 we have to update qTrail!!! > qh->qTail = qh->qHead; > } > } > } > > return st; >} > > >_______________________________________________ >Ucip-devel mailing list >Uci...@li... >https://lists.sourceforge.net/lists/listinfo/ucip-devel > > |
From: Robert D. <od...@pn...> - 2002-01-12 01:26:38
|
Guy and Alberto, I've looked at the code in question and found that I have=20 definately made a very stupid mistake in performing the=20 manual macro expansion. I have corrected this and will=20 update the CVS repository shortly. My apologies to Alberto and his team for creating so much=20 needless work to get the source working and thanks for=20 submitting the bug report. Thanks and regards, Robert Dickenson. At 09:51 AM 10/01/2002 -0800, you wrote: >Alberto Perdomo wrote: > >> Hi Guy. >> >> We=B4re been working with the UCIP stack. I=B4m porting it to a >> DSP platform and made some corrections to code. We had >> several problems. The hardest was, that the TCP layer >> didn=B4t work, every time a packet was received there was an >> exception. We found the error. It=B4s located in the file >> nettcp.c, function tcpReadJiffy. It seems that you mixed up >> two lines: >> >> this is how it was in the original code: >> tcb->rcvBuf =3D tcb->rcvq.qHead->nextChain; >> tcb->rcvq.qHead =3D tcb->rcvBuf; >> >> this is how it really works: >> tcb->rcvBuf =3D tcb->rcvq.qHead; >> tcb->rcvq.qHead =3D tcb->rcvBuf->nextChain; >> >> so, that=B4s it. it really took us a few days to find it, >> because we didn=B4t know the code good, but we managed... >> >> yours sincerely, >> >> alberto perdomo. > > Thanks Alberto. > > Robert, can you look in to this? It looks like you replaced >nDEQUEUE() probably so you could trace it outside of the macro >but it's going to drop the head chain of the queue. Can we >just go back to using nDEQUEUE()? > > Thanks. > > Guy >-- >"Embedded and Open Source Solutions" >Guy Lancaster Computer Consultants >mailto:gu...@gu... >http://guylancaster.com > > > >_______________________________________________ >Ucip-devel mailing list >Uci...@li... >https://lists.sourceforge.net/lists/listinfo/ucip-devel > > |
From: Mads C. <MC...@vo...> - 2002-01-11 12:22:03
|
Hi everyone! Please read this Robert. And some days of seeking i finally found and annoying bug. It seems that sometimes the transmit queue in the stacks gets corrupted. I located the error in the nTrimQ function in netbuf.c. Actually I'm not sure if any of you guys ever will see this error since = I'm running the stack in a single task. I would very much like you Robert to update the CVS, since my pc is not = configured for the CVS anymore. The error will sometimes occur when nTrim is called from nTrimQ. Read the = comments in the source below. Best wishes to you all, Mads Christiansen Partner Voxtream www.voxtream.com=20 Here is the new nTrimQ function. /* * nTrimQ - Trim bytes from the front of a buffer queue. * Note: The queue needs to be protected from collisions for the duration * of this call. * Return the number of bytes trimmed. */ int nTrimQ(char *dst, NBufQHdr *qh, u_int len) { int st =3D 0; =09 if (qh && qh->qHead && len) { NBuf *n0; int trimmed; =09 /* Trim entire chains. */ while (qh->qHead && len >=3D qh->qHead->chainLen) { if ((qh->qHead =3D (n0 =3D qh->qHead)->nextChain) = =3D=3D NULL) qh->qTail =3D NULL; qh->qLen--; =09 n0->nextChain =3D NULL; if (dst) { trimmed =3D nTrim(dst, &n0, len); if (dst) dst +=3D trimmed; len -=3D trimmed; st +=3D trimmed; } else { len -=3D n0->chainLen; st +=3D n0->chainLen; } if (n0) nFreeChain(n0); } =09 /* If more to go, trim from next chain. */ if (len && qh->qHead) { /*=20 * XXX LONG CRITICAL SECTION!!! Could we pop this = off the queue, * trim it, and then replace the remainder? Do we = need a semaphore?=20 */ trimmed =3D nTrim(dst, &qh->qHead, len); st +=3D trimmed; // Update tail pointer!!! SERIOUS BUGFIX /ma...@mo... 2002.01.11 if (qh->qLen =3D=3D 1) { // nTrim might return a new nBuf in qh->qHead // IF qLen =3D=3D 1 we have to update qTrail!!!=20 qh->qTail =3D qh->qHead; } } } =09 return st; } |
From: Guy L. <gu...@gu...> - 2002-01-10 17:38:03
|
Alberto Perdomo wrote: > Hi Guy. > > We=B4re been working with the UCIP stack. I=B4m porting it to a > DSP platform and made some corrections to code. We had > several problems. The hardest was, that the TCP layer > didn=B4t work, every time a packet was received there was an > exception. We found the error. It=B4s located in the file > nettcp.c, function tcpReadJiffy. It seems that you mixed up > two lines: > > this is how it was in the original code: > tcb->rcvBuf =3D tcb->rcvq.qHead->nextChain; > tcb->rcvq.qHead =3D tcb->rcvBuf; > > this is how it really works: > tcb->rcvBuf =3D tcb->rcvq.qHead; > tcb->rcvq.qHead =3D tcb->rcvBuf->nextChain; > > so, that=B4s it. it really took us a few days to find it, > because we didn=B4t know the code good, but we managed... > > yours sincerely, > > alberto perdomo. Thanks Alberto. Robert, can you look in to this? It looks like you replaced nDEQUEUE() probably so you could trace it outside of the macro but it's going to drop the head chain of the queue. Can we just go back to using nDEQUEUE()? Thanks. Guy -- "Embedded and Open Source Solutions" Guy Lancaster Computer Consultants mailto:gu...@gu... http://guylancaster.com |