-
Notifications
You must be signed in to change notification settings - Fork 281
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
netd mishandles TCP reset, some types of close and bind then connect #555
Comments
re: close to immediately move kernel socket to CLOSED: net_native.c looks to be the place to make this change. Close the socket, but leave the SD struct around for message buffering. |
Re bind: Lemme check my passive open branch. I sorta remember implementing bind() there. I think its required for passive opens, no? |
The close needs to go via net_native because net_native needs to know when it closed, also when the Wiznet offloaded tcp/ip is done I'm fairly sure we need to block (momentarily only) on doing the close. So really the 'I'm closed' 'ok you're closed' handshake does need to go through netd |
I think I have the reset/close side nailed down now. |
The bind logic is handled in the kernel but we need to tweak uIP to pass the local address from the kernel/netd into uip_connect() instead of UIP making it up. |
I commensed tweaking uip for bind support. I didnt have time to Test/wireshark the changes but soon. |
I think a bind on a udp sock should move the sock into connected state? |
As uIP sees it quite possibly. In the Unix world INADDR_ANY, port bind() means 'receive anything to this port and addr/port means 'receive anything to this port/address pair' Connect() in Unixland means 'send to this address/port only' And I'd need to look up whether it means received frames must have that address. I don't think so but need to check! |
Hmm.. i dont think "sendto" actually sends any signal to netd to change uip's remote address/port. It will send a "write" event, then i guess i can make netd apply the remote addr every write. Ick |
hung up on some bug on tcp end. Getting a signal thats interrupting the psleep while waiting for a connect. My hoaky "gethostbyname" alarm() call seems to be doing it, but alarm(0) doesnt seem to stop the timer. |
Strange - the kernel code appears correct for this and I don't see any connect() problems, but I'm not actually running your gethostbyname() with names because it seems to be endian specific. |
concerning UDP: if netd doesn't move socket to SS_CONNECTED upon bind(), then sock_read() fails with EINVAL! I don't believe a connect() should be necessary on a UDP sock? |
It shouldn't. So presumably you need to do so on the bind() I'll take a look when I get time |
A reset should close the socket for read and write
A close should break the connection between the uip 'socket' and the kernel one and close the kernel one immediately. If data is pending for input then tcp reset the link, if not then let it cycle through close states and reset if any more data arrives
uIP needs tweaking so that it uses the bind() provided local socket if presetn when we connect().
For performance reasons we could do with teaching uIP to be able to answer the question "how many timer cycles until my next wakeup"
And we need to move to the most recent uIP code base (in Contiki)
The text was updated successfully, but these errors were encountered: