[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[lwip-users] [lwip] udp server problem (possible problem with pcb->remo
From: |
David Figueroa |
Subject: |
[lwip-users] [lwip] udp server problem (possible problem with pcb->remote_ip) |
Date: |
Wed, 08 Jan 2003 23:24:45 -0000 |
I have noticed there might be a problem with udp, else maybe I'm overlooking
something trivial.
Once the server has bound to a port and is "receiving"
The first and subsequent requests from the same ip source works just fine.
The second and subsequent requests from a different ip source does not get
accepted.
This is because the "listening" pcb is now set to the first guy's ip
address. This is set by the udp_connect function:
err_t
udp_connect(struct udp_pcb *pcb, struct ip_addr *ipaddr, u16_t port)
{
struct udp_pcb *ipcb;
ip_addr_set(&pcb->remote_ip, ipaddr);
pcb->remote_port = port;
...
Therefore whenever a new udp packet arrives (and port matches) from a
different ip address it will be rejected because the remote ip address in
pcb (pcb->remote_ip) is no longer NULL i.e. "ip_addr_isany" (in udp_input -
there are 6 different checks to accept/reject udp request).
I have temporarily fixed this by clearing out the pcb->remote_ip after the
"ip_output_if" call in udp_send.
err = ip_output_if(p, src_ip, &pcb->remote_ip, UDP_TTL, IP_PROTO_UDP,
netif);
}
/**** df temporary fix ****/
ip_addr_set(&pcb->remote_ip, NULL);
pcb->remote_port = 0;
/**** end df temporary fix ****/
#ifdef UDP_STATS
++stats.udp.xmit;
#endif /* UDP_STATS */
return err;
}
but this cannot be correct. Should there be a new pcb created to accept the
new udp request? If so how is this done? And also why can't the existing
pcb be re-used (as I am doing now). Surely new udp clients should not cause
the pcb list to grow indefinitely...
I apologize if this problem has been reported/fixed; if so please point me
in the right direction.
Thanks for your input,
dave
[This message was sent through the lwip discussion list.]
- [lwip-users] [lwip] udp server problem (possible problem with pcb->remote_ip),
David Figueroa <=