Service_PreReset handler in Internet module

The Internet module performs a full shutdown (equivalent to *RMKill) in response to Service_PreReset. However, because the module is still running, it means that anything which then attempts to use Internet services has a good chance of crashing.

Specifically, I’m currently looking into a problem where attempting to reset a machine which has the VNC server with an active connection will result in a crash. The Internet module shuts itself down, then manually triggers callbacks, at which point a VNC server callback runs and attempts to use a socket SWI. The SWI then crashes due to the socket being left in some half-terminated state (specifically it crashes when trying to interact with an mbuf, because mere microseconds earlier the Internet module closed its MbufManager session, invalidating all of its mbuf pointers)

Since Service_PreReset is only really meant to be used by hardware drivers, and the Internet module isn’t a hardware driver, I’m left wondering why the module does what it does. CVS doesn’t give any obvious clues (the PreReset handler has been there forever). Meanwhile, all the ethernet hardware drivers I’ve looked at contain their own (generally sensible) PreReset handlers, so it seems unlikely that it’s resetting everything for the benefit of the backend drivers.

If I remove the PreReset handler from Internet (or replace it with the usermode_donothing call) then the crash goes away, so I’m tempted to go down the route of removing the handler completely. Or failing that, a flag could be added to ensure all the socket SWIs are deactivated once PreReset is seen, similar to the flag I added to DMAManager a while ago (although I can’t remember what issue prompted that change).

Anyone more familiar with the network stack than myself have any insights?

If I remove the PreReset handler from Internet (or replace it with the usermode_donothing call) then the crash goes away, so I’m tempted to go down the route of removing the handler completely.

Given the rewrite of the stack somewhere in the production pipeline that seems entirely reasonable.

If you can see anything in Resolver and Internet that makes the reverse lookup work correctly¹ that can be done easily then that would be nice too.

¹ Years since I looked at that mess (as in trying to get a DNS blacklist test utility to behave and discovering the official resolver often doesn’t – resolve that is), but as I recall nailing in “in.addr.arpa” strikes me as a bit of code for a test version that just got left in the production item.

Since Service_PreReset is only really meant to be used by hardware drivers, and the Internet module isn’t a hardware driver, I’m left wondering why the module does what it does. CVS doesn’t give any obvious clues

Nothing interesting in the BlackLog either. Inspection of Internet 4.10 binary shows it also did it, so I suspect the evidence was somewhere in the long lost ANC division’s logs.

Maybe someone was trying to clean up before a soft reset? The module would have been restarted some point in !Boot when the stack is brought up. Soft resets went away with the Risc PC though.

I agree there’s no good reason for a protocol module to do anything with Service_PreReset: chop it!