Sorry for the cross-posting, but I believe that from now on the people
from the PPP list can help.
Ok, let's update the situation:
- Linux kernel 2.1.90
- Debian/GNU Linux 1.3.1
- All packages upgraded according to Documentation/Changes in 2.1.90 tree
Now the system is ready to run the kernel 2.1 series (I believe ... :).
Then I'm going for the actual objective of all this trouble: test the
Cyclades driver under heavy load in the latest 2.1 kernel.
I have a script (which works not only for Cyclades ports, but also for any
serial port) that does the following:
1) Closes PPP connections between ports **in the same machine**.
2) Opens FTP sessions thru the PPP links.
3) Transfers 1MB files in both directions in all ports.
4) Closes FTP sessions and go back to step 2.
NOTE: each PPP port pair should be interconnected with a null-modem cable.
This script works perfect in kernel 2.0.33 with PPPd properly upgraded to
v2.3.3 (so that we don't have too many variables in the troubleshooting
process).
For kernel 2.1.90, it seems that all the data, instead of going thru the
PPP links, is going thru the loopback interface !!!
Again, this doesn't seem to be a problem in the driver, because I tested
it with two on-board serial ports (ttyS0 and ttyS1) and the same thing
happens.
Check it out: this is a diff from the ifconfig results for the same file
operation (one file transfer cycle on my script) under each kernel.
--- 2.0.33 Thu Mar 26 13:50:53 1998
+++ 2.1.90 Thu Mar 26 13:25:19 1998
@@ -1,61 +1,61 @@
lo Link encap:Local Loopback
inet addr:127.0.0.1 Bcast:127.255.255.255 Mask:255.0.0.0
- UP BROADCAST LOOPBACK RUNNING MTU:3584 Metric:1
- RX packets:25 errors:0 dropped:0 overruns:0
- TX packets:25 errors:0 dropped:0 overruns:0
+ UP LOOPBACK RUNNING MTU:3584 Metric:1
+ RX packets:16697 errors:0 dropped:0 overruns:0 frame:0
+ TX packets:16697 errors:0 dropped:0 overruns:0 carrier:0 coll:0
At first, is the BROADCAST entry relevant for this problem?
Also, note the number of packets in the kernel 2.1.90. The transfer of 8
1MB files took about 2 sec to finish ... I'm sure this was not done thru
the PPP lines !! :)
Now, the PPP links (remember, - is for 2.0.33, +, for 2.1.90):
-ppp0 Link encap:Point-Point Protocol
- inet addr:10.0.0.1 P-t-P:10.0.0.2 Mask:255.255.255.252
+ppp0 Link encap:Point-to-Point Protocol
+ inet addr:10.0.0.1 P-t-P:10.0.0.2 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
- RX packets:1237 errors:1 dropped:0 overruns:0
- TX packets:1240 errors:0 dropped:0 overruns:0
+ RX packets:9 errors:1 dropped:0 overruns:0 frame:0
+ TX packets:9 errors:0 dropped:0 overruns:0 carrier:0 coll:0
-ppp1 Link encap:Point-Point Protocol
- inet addr:10.0.0.2 P-t-P:10.0.0.1 Mask:255.255.255.252
+ppp1 Link encap:Point-to-Point Protocol
+ inet addr:10.0.0.2 P-t-P:10.0.0.1 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
- RX packets:1237 errors:3 dropped:0 overruns:0
- TX packets:1237 errors:0 dropped:0 overruns:0
+ RX packets:9 errors:1 dropped:0 overruns:0 frame:0
+ TX packets:9 errors:0 dropped:0 overruns:0 carrier:0 coll:0
Here, you can notice two things: the number of packets (which in 2.0.33
shows that the files were actually transmitted thru the serial line) and
... that's weird ... the subnet masks !! I'm forcing 255.255.255.252 on my
pppd call, but it works only for the kernel 2.0.33 ...
The output of 'netstat -rn' (routing table) shows the same results in both
kernels.
Please help !!!
If you need more info, just ask.
Thanks in advance.
Regards,
Ivan Passos
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu