Here is some more information on this problem along with a temporary
fix. First my configuration.
zeego <--(ethernet)--> rabbit <--(slip connection)--> netcom (running SunOS).
lin-1.99.9 lin-1.99.9
ip_forward
slip
I have my local MTU set to 296 for sl0, but I'm not sure if the
other end is honoring this size, and the automatic detection
doesn't seem to be happening. The problem only happens in combination
with IP forwarding. If I run an application from zeego, the freeze
occurs. If I run the application from rabbit, no freeze occurs.
When I took a look at the tcp dump of the data on sl0, if I was
logging in from rabbit, the maximum packet size was less than the
MTU for sl0. If I logged in from zeego, then the maximum incomding
packet size over sl0 was greater than the MTU. One packet was 1440
bytes long.
I still don't know what is causing the problem, but this patch helps
it for me. It isn't the right way to fix the problem, but it does
work better for incoming packets.
Gordon Chaffee
chaffee@bugs-bunny.cs.berkeley.edu
--- linux/drivers/net/slip.c~ Sat May 25 13:01:47 1996
+++ linux/drivers/net/slip.c Sat Jun 1 18:18:13 1996
@@ -233,9 +233,16 @@
* also fixes a bug in which SunOS sends 512-byte packets even with
* an MSS of 128
*/
+#define BUGTEST
+#ifndef BUGTEST
if (len < 576 * 2) {
len = 576 * 2;
}
+#else
+ if (len < 1000 * 2) {
+ len = 1000 * 2;
+ }
+#endif
xbuff = (unsigned char *) kmalloc (len + 4, GFP_ATOMIC);
rbuff = (unsigned char *) kmalloc (len + 4, GFP_ATOMIC);
@@ -590,9 +597,15 @@
* also fixes a bug in which SunOS sends 512-byte packets even with
* an MSS of 128
*/
+#ifndef BUGTEST
if (len < 576 * 2) {
len = 576 * 2;
}
+#else
+ if (len < 1000 * 2) {
+ len = 1000 * 2;
+ }
+#endif
sl->rbuff = (unsigned char *) kmalloc(len + 4, GFP_KERNEL);
if (sl->rbuff == NULL) {
goto norbuff;