headers
the_gadfly | 1 Jul 2009 04:24
Favicon

that's ok ,could someone show me a good rap-api udp receiving software ?


That's ok , the code sent udp messages successfully when I  turning on the
ARP_QUEUEING .According  the Ethereal ,the message is correct including src
,dest.and checksum.
However ,my udp receiving software did not work well.so could some one help
me ?

Best Regards
the_gadfly

Simon Goldschmidt wrote:
> 
> 
>> hi:
>> this is my code,modified form stand-alone lwip example web server. I am
>> trying to send messages through UDP. But all it is sending are ARP's.
> 
> That's perfectly OK: before the stack can actually send the UDP packet, it
> has to know the target MAC address. Since it doesn't know it, yet, ARP
> request packets are sent.
> 
> The stack should receive ARP response packets and (if ARP queueing is
> turned on), the original UDP packets should be sent (if ARP queueing is
> turned off, the old packets are not sent - udp_send() returns an error -
> but the next packets can be sent).
> 
> So the question is: are there any ARP responses and if so, why doesn't the
> stack handle them. You should see the ARP response packets if they come
> from the same PC you are running wireshark on.
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bernhard 'Gustl' Bauer | 1 Jul 2009 11:40
Picon

tcp_close: pcb->state - WAS: portscan

Hi,

I finally made some progress in my portscan problem.

When I send out data, I get http_sent() calls. If all data is sent out I 
call a tcp_close(). Unfortunately pcb->state is either ESTABLISHED or 
CLOSE_WAIT and neither does free tcp_pcb.

One solution could be to use tcp_abort(). Another to set state to CLOSED 
or SYN_SENT. How to do it right?

TIA

Gustl
Permalink | Reply | 3 comments |
headers
Kieran Mansley | 1 Jul 2009 12:53

Re: tcp_close: pcb->state - WAS: portscan

On Wed, 2009-07-01 at 11:40 +0200, Bernhard 'Gustl' Bauer wrote:
> Hi,
> 
> I finally made some progress in my portscan problem.
> 
> When I send out data, I get http_sent() calls. If all data is sent out I 
> call a tcp_close(). Unfortunately pcb->state is either ESTABLISHED or 
> CLOSE_WAIT and neither does free tcp_pcb.

That's odd.  Is this the state before or after you've called tcp_close
()?  If you've called tcp_close() it should be in FIN_WAIT1, FIN_WAIT2,
CLOSING, or TIME_WAIT on its way to CLOSED.  CLOSE_WAIT is entered if
the other end closes the connection first, and then when you call
tcp_close() it should move to LAST_ACK and then CLOSED. 

> One solution could be to use tcp_abort(). Another to set state to CLOSED 
> or SYN_SENT. How to do it right?

tcp_close() is the right way to do it, but why the state is as you
describe I'm not sure.

Kieran
Permalink | Reply | 2 comments |
headers
Lou Cypher | 1 Jul 2009 14:12
Favicon

tcp_poll(), event handlers and possible misinformation

I was investigating on how it comes that tcp_poll() handler is called even on
receive packets -- I thought it was *only* for transmit ones, while with httpd
and large POST messages, I see it called on packets delayed/missed in handling

Left aside the first problem (...) I noted how event handlers are called in
tcp_fasttmr() and tcp_slowtmr(), and I started figuring something wrong that can
happen.
Surely I'm not well into lwIP internals, but I'd like someone to clarify my
hypothesis:
- Suppose you are handling a packet of data, in the handler set with tcp_recv().
- While doing your chores, a new packet is/becomes ready/late, and the timer you
connected to tcp_fasttmr() and/or tcp_slowtmr() fires an interrupt.
- The interrupt stops your handler in the middle, and the timer function finds
some PCBs that need processing, calling again the tcp_recv() handler: isn't this
kind of reentrancy fatal?

It's true that even in that case the library could depute any semaphore handling
to the handlers, but I don't remember I found such a note anywhere, nor the
httpd server in contrib does expose it.
Even if the conjecture holds true, I wouldn't file it as a bug, but just as
"missing information" about usage.

About the original problem: if I get called for tcp_poll, and there's nothing to
send, should I call my recv handler? (...)

Lou

____________________________________________________________
GET FREE 5GB EMAIL - Check out spam free email with many cool features!
Visit http://www.inbox.com/email to find out more!
(Continue reading)

Permalink | Reply | 11 comments |
headers
Bernhard 'Gustl' Bauer | 1 Jul 2009 13:22
Picon

Re: tcp_close: pcb->state - WAS: portscan

Kieran Mansley schrieb:
> On Wed, 2009-07-01 at 11:40 +0200, Bernhard 'Gustl' Bauer wrote:
>> When I send out data, I get http_sent() calls. If all data is sent out I 
>> call a tcp_close(). Unfortunately pcb->state is either ESTABLISHED or 
>> CLOSE_WAIT and neither does free tcp_pcb.
> 
> That's odd.  Is this the state before or after you've called tcp_close
> ()?  If you've called tcp_close() it should be in FIN_WAIT1, FIN_WAIT2,
> CLOSING, or TIME_WAIT on its way to CLOSED.  CLOSE_WAIT is entered if
> the other end closes the connection first, and then when you call
> tcp_close() it should move to LAST_ACK and then CLOSED. 

It is before I call tcp_close(). Afterwards it is FIN_WAIT_1. Some time 
later it is TIME_WAIT. And in the end tcp_pcb is removed by tcp_slowtmr. 
Is this the correct way to do it? Is there a way to remove it 
immediately when it enters TIME_WAIT?

Gustl
Permalink | Reply | 1 comment |
headers
Kieran Mansley | 1 Jul 2009 14:28

Re: tcp_poll(), event handlers and possible misinformation

On Wed, 2009-07-01 at 14:12 +0200, Lou Cypher wrote:
> I was investigating on how it comes that tcp_poll() handler is called even on
> receive packets -- I thought it was *only* for transmit ones, while with httpd
> and large POST messages, I see it called on packets delayed/missed in handling
> 
> Left aside the first problem (...) I noted how event handlers are called in
> tcp_fasttmr() and tcp_slowtmr(), and I started figuring something wrong that can
> happen.
> Surely I'm not well into lwIP internals, but I'd like someone to clarify my
> hypothesis:
> - Suppose you are handling a packet of data, in the handler set with tcp_recv().
> - While doing your chores, a new packet is/becomes ready/late, and the timer you
> connected to tcp_fasttmr() and/or tcp_slowtmr() fires an interrupt.

I'm not sure why the timer handling functions would be raising
interrupts.

> - The interrupt stops your handler in the middle, and the timer function finds
> some PCBs that need processing, calling again the tcp_recv() handler: isn't this
> kind of reentrancy fatal?

This shouldn't happen.  The "normal" way to avoid such things is to not
process packets in the interrupt handler, but instead to queue them for
processing by the stack.  This way there is only a single thread active
in the stack at any one time. 

> About the original problem: if I get called for tcp_poll, and there's nothing to
> send, should I call my recv handler? (...)

>From the raw API documentation:
(Continue reading)

Permalink | Reply | 10 comments |
headers
Kieran Mansley | 1 Jul 2009 14:32

Re: tcp_close: pcb->state - WAS: portscan

On Wed, 2009-07-01 at 13:22 +0200, Bernhard 'Gustl' Bauer wrote:

> It is before I call tcp_close().

OK, that makes sense then.

>  Afterwards it is FIN_WAIT_1. Some time 
> later it is TIME_WAIT. And in the end tcp_pcb is removed by tcp_slowtmr. 
> Is this the correct way to do it?

Yes.

> Is there a way to remove it 
> immediately when it enters TIME_WAIT?

No.

Kieran
Permalink | Reply | 0 comments |
headers
Lou Cypher | 1 Jul 2009 15:17
Favicon

Re: tcp_poll(), event handlers and possible misinformation

> I'm not sure why the timer handling functions would be raising
> interrupts.

Well, interrupt won't come from tcp_fasttmr(), but from the caller.
It's quite usual having hardware timers, with an automatic reload, that
interrupt processing at a predefined rate: from there I can call tcp_fasttmr(),
tcp_slowtmr() and all the the other timing functions.

Yes, there are issues to keep in mind, like the requirement for secondary
functions (called from handler), like tcp_fasttmr(); they shall execute "fast
enough" to avoid missing next timer tick.
If lwIP processing were slower than 250 ms (TCP_FAST_INTERVAL), well... I should
better change my processor...
Once avoided all the downsides you can have the benefit of a well defined
tick/interrupt rate (beside interrupt response).

>> - The interrupt stops your handler in the middle, and the timer function finds
>> some PCBs that need processing, calling again the tcp_recv() handler: isn't this
>> kind of reentrancy fatal?
> 
> This shouldn't happen.  The "normal" way to avoid such things is to not
> process packets in the interrupt handler, but instead to queue them for
> processing by the stack.  This way there is only a single thread active
> in the stack at any one time. 

And so I will do, to avoid contention.
My drawback is that having a co-operative scheduler I can't guarantee a constant
timer call: from some call to the next I could have some jitter.
I presume that having 250 ms on a cycle, and 255 on the next, won't kill lwIP, true?
(Continue reading)

Permalink | Reply | 7 comments |
headers
Jeff Barber | 1 Jul 2009 16:16
Picon

Re: tcp_poll(), event handlers and possible misinformation

On Wed, Jul 1, 2009 at 9:17 AM, Lou Cypher<loucypher@...> wrote:
>> I'm not sure why the timer handling functions would be raising
>> interrupts.
>
> Well, interrupt won't come from tcp_fasttmr(), but from the caller.
> It's quite usual having hardware timers, with an automatic reload, that
> interrupt processing at a predefined rate: from there I can call tcp_fasttmr(),
> tcp_slowtmr() and all the the other timing functions.
>
> Yes, there are issues to keep in mind, like the requirement for secondary
> functions (called from handler), like tcp_fasttmr(); they shall execute "fast
> enough" to avoid missing next timer tick.
> If lwIP processing were slower than 250 ms (TCP_FAST_INTERVAL), well... I should
> better change my processor...
> Once avoided all the downsides you can have the benefit of a well defined
> tick/interrupt rate (beside interrupt response).
>
>>> - The interrupt stops your handler in the middle, and the timer function finds
>>> some PCBs that need processing, calling again the tcp_recv() handler: isn't this
>>> kind of reentrancy fatal?
>>
>> This shouldn't happen.  The "normal" way to avoid such things is to not
>> process packets in the interrupt handler, but instead to queue them for
>> processing by the stack.  This way there is only a single thread active
>> in the stack at any one time.
>
> And so I will do, to avoid contention.
> My drawback is that having a co-operative scheduler I can't guarantee a constant
> timer call: from some call to the next I could have some jitter.
> I presume that having 250 ms on a cycle, and 255 on the next, won't kill lwIP, true?
(Continue reading)

Permalink | Reply | 6 comments |
headers
Bill Auerbach | 1 Jul 2009 16:25

RE: tcp_poll(), event handlers and possible misinformation

>When a connection is idle (i.e., no data is either transmitted or
>received), lwIP will repeatedly poll the application by calling a
>specified callback function. This can be used either as a watchdog
>timer for killing connections that have stayed idle for too long, or
>as a method of waiting for memory to become available. For instance,
>if a call to tcp_write() has failed because memory wasn't available,
>the application may use the polling functionality to call tcp_write()
>again when the connection has been idle for a while.

Maybe this is legacy now.  If tcp_write cannot send data, it will be called
by the stack when data can be sent.

Or empirically, I don't use tcp_poll (it gave me problems) and I don't have
memory to send 500k at once. tcp_sent is simply called until I am able to
send all of my data.

Bill
Permalink | Reply | 1 comment |

Gmane