PERFORCE change 108918 for review

[Paolo Pisati]

http://perforce.freebsd.org/chv.cgi?CH=108918

Change 108918 by piso at piso_newluxor on 2006/11/01 15:18:55

	Fix a comment.

Affected files ...

.. //depot/projects/soc2005/libalias/sys/netinet/ip_fw2.c#27 edit

Differences ...

==== //depot/projects/soc2005/libalias/sys/netinet/ip_fw2.c#27 (text+ko) ====

@@ -3471,55 +3471,49 @@
 				/* 
 				 * XXX - Libalias checksum offload 'duct tape':
 				 * 
-				 * locally generated packets have only 
-				 * pseudo-header
-				 * checksum calculated and libalias will 
-				 screw it[1],
-				 * so mark them for later fix.
-				 * Moreover there are cases when libalias 
-				 modify tcp
-				 * packet data[2], mark it for later fix too.
+				 * locally generated packets have only
+				 * pseudo-header checksum calculated
+				 * and libalias will screw it[1], so
+				 * mark them for later fix.  Moreover
+				 * there are cases when libalias
+				 * modify tcp packet data[2], mark it
+				 * for later fix too.
 				 *
-				 * [1] libalias was never meant to run in 
-				 kernel, so
-				 * it doesn't have any knowledge about 
-				 checksum 
-				 * offloading, and it expects a packet with 
-				 a full
-				 * internet checksum. Unfortunately, packets 
-				 * generated locally will have just the pseudo
-				 * header calculated, and when libalias tries 
-				 to 
-				 * adjust the checksum it will actually screw 
-				 it.
+				 * [1] libalias was never meant to run
+				 * in kernel, so it doesn't have any
+				 * knowledge about checksum
+				 * offloading, and it expects a packet
+				 * with a full internet
+				 * checksum. Unfortunately, packets
+				 * generated locally will have just the
+				 * pseudo header calculated, and when
+				 * libalias tries to adjust the
+				 * checksum it will actually screw it.
 				 *
-				 * [2] when libalias modify tcp's data content,
-				 * full TCP checksum has to be recomputed: 
-				 * the problem is that libalias doesn't have 
-				 any 
-				 * idea about checksum offloading
-				 * To workaround this, we do not do 
-				 checksumming 
-				 * in LibAlias, but only mark the packets in 
-				 th_x2 
-				 * field. If we receive a marked packet, we 
-				 * calculate correct checksum for it aware of 
-				 * offloading.
-				 * Why such a terrible hack instead of
-				 * recalculating checksum for each packet?
-				 * Because the previous checksum was not 
-				 checked!
-				 * Recalculating checksums for EVERY packet 
-				 will
-				 * hide ALL transmission errors. Yes, marked 
-				 packets
-				 * still suffer from this problem. But, sigh, 
-				 natd(8)
-				 * has this problem, too.
+				 * [2] when libalias modify tcp's data
+				 * content, full TCP checksum has to
+				 * be recomputed: the problem is that
+				 * libalias doesn't have any idea
+				 * about checksum offloading To
+				 * workaround this, we do not do
+				 * checksumming in LibAlias, but only
+				 * mark the packets in th_x2 field. If
+				 * we receive a marked packet, we
+				 * calculate correct checksum for it
+				 * aware of offloading.  Why such a
+				 * terrible hack instead of
+				 * recalculating checksum for each
+				 * packet?  Because the previous
+				 * checksum was not checked!
+				 * Recalculating checksums for EVERY
+				 * packet will hide ALL transmission
+				 * errors. Yes, marked packets still
+				 * suffer from this problem. But,
+				 * sigh, natd(8) has this problem,
+				 * too.
 				 *
-				 * TODO:
-				 * -make libalias mbuf aware (so it can handle
-				 *  delayed checksum)
+				 * TODO: -make libalias mbuf aware (so
+				 * it can handle delayed checksum)
 				 */
 
 				if (mcl->m_pkthdr.rcvif == NULL &&