The short answer is that the checksum is assumed to have been verified before the packet is handed to the Mirage stack.
The problem with doing an additional redundant verification in Mirage is that when two local VMs are talking then the Xen driver, which has offered checksum offload, does not do any actual checksum computation. So all packets arrive with invalid checksums. The particular call to the null function is there just as a marker that this is where it should be checked. A proper solution would be to correctly process the offload offers, which mirage doesn't, AFAIK. Clearly if the driver offers offload then checksum computation should not be done on the way out or verification on the way in, else it should. There is a complication that checksum offload can be turned on or off midstream so it may have to change per packet. A good project for someone interested. On Fri, Nov 20, 2015 at 7:31 PM, Richard Mortier < [email protected]> wrote: > One of my undergraduate students who's doing a project with MirageOS > and the TCP/IP stack in particular asked a question that I couldn't > immediately answer -- wondered if someone else could :) > > Specifically, > https://github.com/mirage/mirage-tcpip/blob/master/tcp/pcb.ml#L99 > appears to define `verify_checksum` to always return `true`; but it is > then called at > https://github.com/mirage/mirage-tcpip/blob/master/tcp/pcb.ml#L510 > in the `input` function in a way that probably expects checksums to > have actually been verified. > > Which seems rather odd -- am I missing something? > > -- > Richard Mortier > [email protected] > > _______________________________________________ > MirageOS-devel mailing list > [email protected] > http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel >
_______________________________________________ MirageOS-devel mailing list [email protected] http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel
