Skip to content
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

Open
EtchedPixels opened this issue Nov 13, 2017 · 13 comments
Open
Labels
bug Misbehaviour rather than feature request enhancement Feature request help wanted

Comments

@EtchedPixels
Copy link
Owner

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)

@EtchedPixels EtchedPixels added bug Misbehaviour rather than feature request enhancement Feature request help wanted labels Nov 13, 2017
@beretta42
Copy link
Contributor

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.

@beretta42
Copy link
Contributor

Re bind: Lemme check my passive open branch. I sorta remember implementing bind() there. I think its required for passive opens, no?

@EtchedPixels
Copy link
Owner Author

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

@EtchedPixels
Copy link
Owner Author

I think I have the reset/close side nailed down now.

@EtchedPixels
Copy link
Owner Author

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.

@beretta42
Copy link
Contributor

I commensed tweaking uip for bind support. I didnt have time to Test/wireshark the changes but soon.

@beretta42
Copy link
Contributor

I think a bind on a udp sock should move the sock into connected state?

@EtchedPixels
Copy link
Owner Author

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!

@beretta42
Copy link
Contributor

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

@beretta42
Copy link
Contributor

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.

@EtchedPixels
Copy link
Owner Author

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.

@beretta42
Copy link
Contributor

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?

@EtchedPixels
Copy link
Owner Author

It shouldn't. So presumably you need to do so on the bind() I'll take a look when I get time

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Misbehaviour rather than feature request enhancement Feature request help wanted
Projects
None yet
Development

No branches or pull requests

2 participants