LinuxQuestions.org
Visit Jeremy's Blog.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Networking
User Name
Password
Linux - Networking This forum is for any issue related to networks or networking.
Routing, network cards, OSI, etc. Anything is fair game.

Notices


Reply
  Search this Thread
Old 10-15-2008, 04:21 PM   #31
itz2000
Member
 
Registered: Jul 2005
Distribution: Fedora fc4, fc7, Mandrake 10.1, mandriva06, suse 9.1, Slackware 10.2, 11.0, 12.0,1,2 (Current)]
Posts: 732

Original Poster
Rep: Reputation: 30

Quote:
Originally Posted by itz2000 View Post
in-fact, that's what I want...
I've managed to configure a static link for one ip (to demonstrate I used microsoft.com IP) and configured it to go through ppp0 to eth1 so when I traceroute it's not going through 192.168.1.1 (seems so, but it actually does):
Code:
root at  /home/cookie# route -vn
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.1.1     255.255.255.255 UGH   0      0        0 ppp0
212.199.17.22   0.0.0.0         255.255.255.255 UH    0      0        0 ppp0
207.46.19.254   192.168.1.1     255.255.255.255 UGH   0      0        0 ppp0
127.0.0.0       0.0.0.0         255.0.0.0       U     0      0        0 lo
0.0.0.0         192.168.1.1     0.0.0.0         UG    0      0        0 eth1

for example : regular ip (via eth1 to 192.168.1.1 to net through isp)

root at  /home/cookie# traceroute -n 207.46.19.253 -i eth1
traceroute to 207.46.19.253 (207.46.19.253), 30 hops max, 38 byte packets
 1  192.168.1.1  1.186 ms  1.064 ms  1.062 ms
 2  10.159.160.1  16.835 ms  25.046 ms  16.058 ms
 3  *

and the configured ip through that new rule will go "directly" to net :
root at  /home/cookie# traceroute -n 207.46.19.254
traceroute to 207.46.19.254 (207.46.19.254), 30 hops max, 38 byte packets
 1  212.199.17.22  13.980 ms  24.945 ms  41.051 ms
 2  212.199.28.1  22.716 ms  267.895 ms *
 3  212.199.5.150  213.125 ms  34.304 ms  22.429 ms
 4  80.179.166.21  81.022 ms  93.941 ms  74.345 ms

any ideas?
 
Old 10-15-2008, 06:58 PM   #32
blackhole54
Senior Member
 
Registered: Mar 2006
Posts: 1,896

Rep: Reputation: 61
I don't understand why this would happen, but is it possible you now have everything going out through ppp0 (which is what I thought you wanted) but the microsoft.com packet is being sent back to your network so it can go out through the router (w/o using ppp0 this time) as dictated by your highlighted routing table rule?

I think a way you can test whether everything is leaving your computer via ppp0 is by using a packet sniffer such as tcpdump. If you run the commands (as root and in separate tests)

Code:
tcpdump -nni eth1
tcpdump -nni ppp0
I would anticipate seeing the packets (in both cases) on ppp0 and not on eth1.

Or ... I could be way out of league here.

BTW, it would be useful for people reading this thread if you would list the commands you use to produce the results in the routing table rather than just the final results.

EDIT: Wrt post #30, I though you wanted the packets going through ppp0 rather than straight to the Internet from the router.

Last edited by blackhole54; 10-15-2008 at 07:00 PM.
 
Old 10-16-2008, 07:30 AM   #33
itz2000
Member
 
Registered: Jul 2005
Distribution: Fedora fc4, fc7, Mandrake 10.1, mandriva06, suse 9.1, Slackware 10.2, 11.0, 12.0,1,2 (Current)]
Posts: 732

Original Poster
Rep: Reputation: 30
Quote:
Originally Posted by blackhole54 View Post
I don't understand why this would happen, but is it possible you now have everything going out through ppp0 (which is what I thought you wanted) but the microsoft.com packet is being sent back to your network so it can go out through the router (w/o using ppp0 this time) as dictated by your highlighted routing table rule?

I think a way you can test whether everything is leaving your computer via ppp0 is by using a packet sniffer such as tcpdump. If you run the commands (as root and in separate tests)

Code:
tcpdump -nni eth1
tcpdump -nni ppp0
I would anticipate seeing the packets (in both cases) on ppp0 and not on eth1.

Or ... I could be way out of league here.

BTW, it would be useful for people reading this thread if you would list the commands you use to produce the results in the routing table rather than just the final results.

EDIT: Wrt post #30, I though you wanted the packets going through ppp0 rather than straight to the Internet from the router.

Okay, So 2 tests made :
traceroute to some internet IP while sniffing eth1 (and ppp0 which will not recieve any of the packets) and sniffing an IP which supposedly went through ppp0 (to eth1 -> to 192.168.1.1) to the internet.


Code:
test 1 :
 14:18:52# traceroute -n 207.46.19.253
traceroute to 207.46.19.253 (207.46.19.253), 30 hops max, 38 byte packets
 1  192.168.1.1  1.382 ms  1.053 ms  1.154 ms
 2  10.159.160.1  19.862 ms  7.715 ms  19.596 ms
..

root at  /home/cookie# tcpdump -nni eth1 | grep -v STP
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes
14:20:00.858758 IP 212.199.170.170 > 192.168.1.4: GREv1, call 0, seq 8407, ack 8294, length 32: LCP, Echo-Request (0x09), id 227, length 14
14:20:00.858872 IP 192.168.1.4 > 212.199.170.170: GREv1, call 25737, seq 8295, ack 8407, length 32: LCP, Echo-Reply (0x0a), id 227, length 14
14:20:01.719001 IP 192.168.1.4 > 212.199.170.170: GREv1, call 25737, seq 8296, length 24: LCP, Echo-Request (0x09), id 177, length 10
14:20:01.732646 IP 212.199.170.170 > 192.168.1.4: GREv1, call 0, seq 8408, ack 8296, length 28: LCP, Echo-Reply (0x0a), id 177, length 10
14:20:01.993472 IP 192.168.1.4.37933 > 207.46.19.253.33435: UDP, length 10
14:20:01.994772 IP 192.168.1.1 > 192.168.1.4: ICMP time exceeded in-transit, length 46
14:20:01.994862 IP 192.168.1.4.37933 > 207.46.19.253.33436: UDP, length 10
14:20:01.995890 IP 192.168.1.1 > 192.168.1.4: ICMP time exceeded in-transit, length 46
14:20:01.995925 IP 192.168.1.4.37933 > 207.46.19.253.33437: UDP, length 10
14:20:01.997055 IP 192.168.1.1 > 192.168.1.4: ICMP time exceeded in-transit, length 46
14:20:01.997096 IP 192.168.1.4.37933 > 207.46.19.253.33438: UDP, length 10
14:20:02.016753 IP 10.159.160.1 > 192.168.1.4: ICMP time exceeded in-transit, length 36
14:20:02.017023 IP 192.168.1.4.37933 > 207.46.19.253.33439: UDP, length 10
14:20:02.024683 IP 10.159.160.1 > 192.168.1.4: ICMP time exceeded in-transit, length 36
14:20:02.024743 IP 192.168.1.4.37933 > 207.46.19.253.33440: UDP, length 10
14:20:02.044235 IP 10.159.160.1 > 192.168.1.4: ICMP time exceeded in-transit, length 36
14:20:02.044395 IP 192.168.1.4.37933 > 207.46.19.253.33441: UDP, length 10
14:20:02.231017 IP 192.168.1.4 > 212.199.170.170: GREv1, call 25737, ack 8408, no-payload, length 12
35 packets captured
35 packets received by filter
0 packets dropped by kernel

Code:
test 2 : packet to internet via ppp0 while sniffing on both ppp0 and eth1

14:12:00# traceroute -n 207.46.19.254
traceroute to 207.46.19.254 (207.46.19.254), 30 hops max, 38 byte packets
 1  212.199.17.22  21.857 ms  38.988 ms  23.336 ms
 2  * 212.199.28.1  14.060 ms  21.990 ms
 3  212.199.5.150  22.973 ms  13.609 ms  14.171 ms
 4  80.179.166.21  69.805 ms  81.766 ms  69.835 ms
 5  77.67.61.145  72.882 ms  70.510 ms  71.154 ms
 6  213.200.80.110  165.926 ms  186.106 ms  173.195 ms
 7  213.200.66.134  173.275 ms  162.053 ms  223.078 ms
 8  207.46.47.92  166.774 ms  163.365 ms  165.865 ms
 9  207.46.41.34  169.965 ms  171.980 ms  165.935 ms
10  207.46.33.213  238.668 ms  248.132 ms  239.261 ms
11  207.46.34.250  243.357 ms  238.784 ms  255.585 ms
...
root at  /home/cookie# tcpdump -nni ppp0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ppp0, link-type LINUX_SLL (Linux cooked), capture size 96 bytes
14:20:18.152378 IP 192.116.98.211.37936 > 207.46.19.254.33435: UDP, length 10
14:20:18.178290 IP 212.199.17.22 > 192.116.98.211: ICMP time exceeded in-transit, length 36
14:20:18.178536 IP 192.116.98.211.37936 > 207.46.19.254.33436: UDP, length 10
14:20:18.200829 IP 212.199.17.22 > 192.116.98.211: ICMP time exceeded in-transit, length 36
14:20:18.200982 IP 192.116.98.211.37936 > 207.46.19.254.33437: UDP, length 10
14:20:18.211950 IP 212.199.17.22 > 192.116.98.211: ICMP time exceeded in-transit, length 36
14:20:18.212184 IP 192.116.98.211.37936 > 207.46.19.254.33438: UDP, length 10
14:20:23.213456 IP 192.116.98.211.37936 > 207.46.19.254.33439: UDP, length 10
14:20:23.227002 IP 212.199.28.1 > 192.116.98.211: ICMP time exceeded in-transit, length 36
14:20:23.227188 IP 192.116.98.211.37936 > 207.46.19.254.33440: UDP, length 10
14:20:23.239865 IP 212.199.28.1 > 192.116.98.211: ICMP time exceeded in-transit, length 36
14:20:23.240026 IP 192.116.98.211.37936 > 207.46.19.254.33441: UDP, length 10
14:20:23.259120 IP 212.199.5.150 > 192.116.98.211: ICMP time exceeded in-transit, length 148
14:20:23.259386 IP 192.116.98.211.37936 > 207.46.19.254.33442: UDP, length 10
14:20:23.271489 IP 212.199.5.150 > 192.116.98.211: ICMP time exceeded in-transit, length 148
14:20:23.271608 IP 192.116.98.211.37936 > 207.46.19.254.33443: UDP, length 10
14:20:23.288497 IP 212.199.5.150 > 192.116.98.211: ICMP time exceeded in-transit, length 148
14:20:23.288660 IP 192.116.98.211.37936 > 207.46.19.254.33444: UDP, length 10
14:20:23.357855 IP 80.179.166.21 > 192.116.98.211: ICMP time exceeded in-transit, length 36
14:20:23.358075 IP 192.116.98.211.37936 > 207.46.19.254.33445: UDP, length 10
14:20:23.427557 IP 80.179.166.21 > 192.116.98.211: ICMP time exceeded in-transit, length 36
14:20:23.427710 IP 192.116.98.211.37936 > 207.46.19.254.33446: UDP, length 10
14:20:23.506079 IP 80.179.166.21 > 192.116.98.211: ICMP time exceeded in-transit, length 36
14:20:23.506244 IP 192.116.98.211.37936 > 207.46.19.254.33447: UDP, length 10

24 packets captured
24 packets received by filter
0 packets dropped by kernel

and eth1 :
root at  /home/cookie# tcpdump -nni eth1 | grep -v STP
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes
14:20:16.098175 arp who-has 192.168.1.4 tell 192.168.1.1
14:20:16.098293 arp reply 192.168.1.4 is-at 00:50:bf:da:ba:71
14:20:18.152579 IP 192.168.1.4 > 212.199.170.170: GREv1, call 25737, seq 8298, length 54: IP 192.116.98.211.37936 > 207.46.19.254.33435: UDP, length 10
14:20:18.178205 IP 212.199.170.170 > 192.168.1.4: GREv1, call 0, seq 8410, ack 8298, length 76: IP 212.199.17.22 > 192.116.98.211: [|icmp]
14:20:18.178573 IP 192.168.1.4 > 212.199.170.170: GREv1, call 25737, seq 8299, ack 8410, length 58: IP 192.116.98.211.37936 > 207.46.19.254.33436: UDP, length 10
14:20:18.200744 IP 212.199.170.170 > 192.168.1.4: GREv1, call 0, seq 8411, ack 8299, length 76: IP 212.199.17.22 > 192.116.98.211: [|icmp]
14:20:18.201018 IP 192.168.1.4 > 212.199.170.170: GREv1, call 25737, seq 8300, ack 8411, length 58: IP 192.116.98.211.37936 > 207.46.19.254.33437: UDP, length 10
14:20:18.211909 IP 212.199.170.170 > 192.168.1.4: GREv1, call 0, seq 8412, ack 8300, length 76: IP 212.199.17.22 > 192.116.98.211: [|icmp]
14:20:18.212209 IP 192.168.1.4 > 212.199.170.170: GREv1, call 25737, seq 8301, ack 8412, length 58: IP 192.116.98.211.37936 > 207.46.19.254.33438: UDP, length 10
14:20:20.029103 IP 192.168.1.4.41086 > 212.199.170.170.1723: P 4146705210:4146705226(16) ack 1256127644 win 54: pptp CTRL_MSGTYPE=ECHORQ ID(912)
14:20:20.087119 IP 212.199.170.170.1723 > 192.168.1.4.41086: . ack 16 win 1952
14:20:20.146268 IP 212.199.170.170.1723 > 192.168.1.4.41086: P 1:21(20) ack 16 win 1952: pptp CTRL_MSGTYPE=ECHORP ID(912) RESULT_CODE(1) ERR_CODE(0)
14:20:20.146277 IP 192.168.1.4.41086 > 212.199.170.170.1723: . ack 21 win 54
14:20:21.338426 IP 212.199.170.170 > 192.168.1.4: GREv1, call 0, seq 8413, ack 8301, length 32: LCP, Echo-Request (0x09), id 229, length 14
14:20:21.338543 IP 192.168.1.4 > 212.199.170.170: GREv1, call 25737, seq 8302, ack 8413, length 32: LCP, Echo-Reply (0x0a), id 229, length 14
14:20:21.721276 IP 192.168.1.4 > 212.199.170.170: GREv1, call 25737, seq 8303, length 24: LCP, Echo-Request (0x09), id 178, length 10
14:20:21.734866 IP 212.199.170.170 > 192.168.1.4: GREv1, call 0, seq 8414, ack 8303, length 28: LCP, Echo-Reply (0x0a), id 178, length 10
14:20:22.233336 IP 192.168.1.4 > 212.199.170.170: GREv1, call 25737, ack 8414, no-payload, length 12
14:20:23.213551 IP 192.168.1.4 > 212.199.170.170: GREv1, call 25737, seq 8304, length 54: IP 192.116.98.211.37936 > 207.46.19.254.33439: UDP, length 10
14:20:23.226921 IP 212.199.170.170 > 192.168.1.4: GREv1, call 0, seq 8415, ack 8304, length 76: IP 212.199.28.1 > 192.116.98.211: [|icmp]
14:20:23.227223 IP 192.168.1.4 > 212.199.170.170: GREv1, call 25737, seq 8305, ack 8415, length 58: IP 192.116.98.211.37936 > 207.46.19.254.33440: UDP, length 10
14:20:23.239785 IP 212.199.170.170 > 192.168.1.4: GREv1, call 0, seq 8416, ack 8305, length 76: IP 212.199.28.1 > 192.116.98.211: [|icmp]
14:20:23.240061 IP 192.168.1.4 > 212.199.170.170: GREv1, call 25737, seq 8306, ack 8416, length 58: IP 192.116.98.211.37936 > 207.46.19.254.33441: UDP, length 10
14:20:23.259024 IP 212.199.170.170 > 192.168.1.4: GREv1, call 0, seq 8417, ack 8306, length 188: IP 212.199.5.150 > 192.116.98.211: [|icmp]
14:20:23.259423 IP 192.168.1.4 > 212.199.170.170: GREv1, call 25737, seq 8307, ack 8417, length 58: IP 192.116.98.211.37936 > 207.46.19.254.33442: UDP, length 10
14:20:23.271424 IP 212.199.170.170 > 192.168.1.4: GREv1, call 0, seq 8418, ack 8307, length 188: IP 212.199.5.150 > 192.116.98.211: [|icmp]
14:20:23.271639 IP 192.168.1.4 > 212.199.170.170: GREv1, call 25737, seq 8308, ack 8418, length 58: IP 192.116.98.211.37936 > 207.46.19.254.33443: UDP, length 10
14:20:23.288407 IP 212.199.170.170 > 192.168.1.4: GREv1, call 0, seq 8419, ack 8308, length 188: IP 212.199.5.150 > 192.116.98.211: [|icmp]
14:20:23.288697 IP 192.168.1.4 > 212.199.170.170: GREv1, call 25737, seq 8309, ack 8419, length 58: IP 192.116.98.211.37936 > 207.46.19.254.33444: UDP, length 10
14:20:23.357768 IP 212.199.170.170 > 192.168.1.4: GREv1, call 0, seq 8420, ack 8309, length 76: IP 80.179.166.21 > 192.116.98.211: [|icmp]
14:20:23.358114 IP 192.168.1.4 > 212.199.170.170: GREv1, call 25737, seq 8310, ack 8420, length 58: IP 192.116.98.211.37936 > 207.46.19.254.33445: UDP, length 10
14:20:23.427472 IP 212.199.170.170 > 192.168.1.4: GREv1, call 0, seq 8421, ack 8310, length 76: IP 80.179.166.21 > 192.116.98.211: [|icmp]
14:20:23.427744 IP 192.168.1.4 > 212.199.170.170: GREv1, call 25737, seq 8311, ack 8421, length 58: IP 192.116.98.211.37936 > 207.46.19.254.33446: UDP, length 10
14:20:23.505990 IP 212.199.170.170 > 192.168.1.4: GREv1, call 0, seq 8422, ack 8311, length 76: IP 80.179.166.21 > 192.116.98.211: [|icmp]
14:20:23.506282 IP 192.168.1.4 > 212.199.170.170: GREv1, call 25737, seq 8312, ack 8422, length 58: IP 192.116.98.211.37936 > 207.46.19.254.33447: UDP, length 10
49 packets captured
49 packets received by filter
0 packets dropped by kernel
like you can see PPP0 is using GREv1 which is Generic Routing Encapsulation http://www.faqs.org/rfcs/rfc2784.html.


So what I actually need to do is encapsulate anything I want to go through ppp0 (which is anything), to the internet via 192.168.1.1 (which lies on eth1).

any tips on how to do that for every ip and not only specific ip?

Last edited by itz2000; 10-16-2008 at 07:33 AM.
 
Old 10-17-2008, 05:33 AM   #34
itz2000
Member
 
Registered: Jul 2005
Distribution: Fedora fc4, fc7, Mandrake 10.1, mandriva06, suse 9.1, Slackware 10.2, 11.0, 12.0,1,2 (Current)]
Posts: 732

Original Poster
Rep: Reputation: 30
I just thought about it...
isn't there a way to wrap (or re-route) outgoing packets with iptables?
 
Old 10-17-2008, 07:21 PM   #35
blackhole54
Senior Member
 
Registered: Mar 2006
Posts: 1,896

Rep: Reputation: 61
Quote:
Originally Posted by itz2000 View Post
isn't there a way to wrap (or re-route) outgoing packets with iptables?
iptables can change the source address (SNAT or MASQUERADE) and the destination address (DNAT). The first might be useful if this computer was acting as a gateway for another computer. I don't think you would have any use for DNAT here. I believe there is a way to tag packets with iptables and have that affect how they get routed by using the ip command. But that is way beyond anything I have ever done.

----------

After reviewing post #33 I realized I had misread the output you posted in post #31. In fact, I got it exactly backwards! So I now agree that for the specific address, the packets are going through the tunnel and everything else is going straight out through eth1 -> router -> Internet. Although that routing table entry still does not make sense to me.

You still have not told me what commands you used to get the routing table in post #31. So I haven't a clue how to go from there to the routing table you want. But if you back up to what you had in post #1, I think the following three commands might do it:

Code:
route add -host 192.168.1.1 dev ppp0
route add default gw 192.168.1.1 dev ppp0
route del -host 192.168.1.1 dev ppp0
I would have thought the last command would have caused the entry from the second command to vanish. But as close as I can come to trying it with my setup, it doesn't seem to. So you might want to try that and see if it does what you want. You now know how to monitor to see what is happening with the packets.

It sill seems to me that the straightforward way to do this is what I posted on post #27. Whether or not you decide to do it that way, I would like to know for my own information if that works. Since I am not set up to try it, would you try it at least once and let me know what happens? Thanks.
 
Old 10-17-2008, 09:35 PM   #36
itz2000
Member
 
Registered: Jul 2005
Distribution: Fedora fc4, fc7, Mandrake 10.1, mandriva06, suse 9.1, Slackware 10.2, 11.0, 12.0,1,2 (Current)]
Posts: 732

Original Poster
Rep: Reputation: 30
Code:
# cable-start
Using interface ppp0
Connect: ppp0 <--> /dev/pts/3
PAP authentication succeeded
local  IP address 192.116.110.110
remote IP address 212.199.17.21
NEW LINE By ZUK
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
212.199.17.21   0.0.0.0         255.255.255.255 UH    0      0        0 ppp0
212.199.170.170 192.168.1.1     255.255.255.255 UGH   0      0        0 eth1
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 eth1
127.0.0.0       0.0.0.0         255.0.0.0       U     0      0        0 lo
0.0.0.0         192.168.1.1     0.0.0.0         UG    0      0        0 ppp0
0.0.0.0         0.0.0.0         0.0.0.0         U     0      0        0 ppp0
 # route add -host 192.168.1.1 dev ppp0
 # route add default gw 192.168.1.1 dev ppp0
SIOCADDRT: File exists
 # route del -host 192.168.1.1 dev ppp0
 # route -vn
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
212.199.17.21   0.0.0.0         255.255.255.255 UH    0      0        0 ppp0
212.199.170.170 192.168.1.1     255.255.255.255 UGH   0      0        0 eth1
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 eth1
127.0.0.0       0.0.0.0         255.0.0.0       U     0      0        0 lo
0.0.0.0         192.168.1.1     0.0.0.0         UG    0      0        0 ppp0
0.0.0.0         0.0.0.0         0.0.0.0         U     0      0        0 ppp0
 # 
# Modem hangup
Connect time 1.5 minutes.
Sent 21370 bytes, received 391 bytes.
Connection terminated.
Using interface ppp0
Connect: ppp0 <--> /dev/pts/3
PAP authentication succeeded
local  IP address 84.94.76.2
remote IP address 212.199.17.21

 # cable-stop
Terminating cable-ppp link on pid (8996),please wait..
Terminating on signal 15
Connect time 0.1 minutes.
Sent 138 bytes, received 0 bytes.
Modem hangup
Connection terminated.

After I "fix" this, when I try to surf somewhere, the "modem" just hang-up and re-connect me. probably there's a conflict or something.

arghhh I'm getting insane.
 
Old 10-18-2008, 01:56 AM   #37
blackhole54
Senior Member
 
Registered: Mar 2006
Posts: 1,896

Rep: Reputation: 61
Quote:
Originally Posted by itz2000 View Post
Code:
# cable-start
Using interface ppp0
Connect: ppp0 <--> /dev/pts/3
PAP authentication succeeded
local  IP address 192.116.110.110
remote IP address 212.199.17.21
NEW LINE By ZUK
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
212.199.17.21   0.0.0.0         255.255.255.255 UH    0      0        0 ppp0
212.199.170.170 192.168.1.1     255.255.255.255 UGH   0      0        0 eth1
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 eth1
127.0.0.0       0.0.0.0         255.0.0.0       U     0      0        0 lo
0.0.0.0         192.168.1.1     0.0.0.0         UG    0      0        0 ppp0
0.0.0.0         0.0.0.0         0.0.0.0         U     0      0        0 ppp0
Wait a minute! That is a different result than in post #1 after running cable-start. It already has the table entry you were looking for w/o using the commands in my last post. Although I am mystified by the last line shown.

Are those last two lines a result of your modifying cable-start? If so, I was suggesting you use the three lines in my last post instead of whatever you have done to create the last two lines above. Not in addition to.

Quote:
After I "fix" this, when I try to surf somewhere, the "modem" just hang-up and re-connect me. probably there's a conflict or something.
I believe the Modem hangup reported is the modem at the other end hanging up. Perhaps it is being caused by that the remote end getting data it doesn't understand as a result of the last line in the routing table? Or perhaps this whole approach is wrong and you should try what I suggested in post #27?

Last edited by blackhole54; 10-18-2008 at 01:58 AM. Reason: two -> to
 
Old 10-19-2008, 02:13 PM   #38
itz2000
Member
 
Registered: Jul 2005
Distribution: Fedora fc4, fc7, Mandrake 10.1, mandriva06, suse 9.1, Slackware 10.2, 11.0, 12.0,1,2 (Current)]
Posts: 732

Original Poster
Rep: Reputation: 30
Quote:
Originally Posted by blackhole54 View Post
Wait a minute! That is a different result than in post #1 after running cable-start. It already has the table entry you were looking for w/o using the commands in my last post. Although I am mystified by the last line shown.

Are those last two lines a result of your modifying cable-start? If so, I was suggesting you use the three lines in my last post instead of whatever you have done to create the last two lines above. Not in addition to.

I believe the Modem hangup reported is the modem at the other end hanging up. Perhaps it is being caused by that the remote end getting data it doesn't understand as a result of the last line in the routing table? Or perhaps this whole approach is wrong and you should try what I suggested in post #27?
according to #27 (if i understood right) I've tried to add those 5 lines

Code:
echo "NEW LINE By ZUK sleep 5"
sleep 5
route add -host 192.168.1.1 dev ppp0
route add default gw 192.168.1.1 dev ppp0
route del -host 192.168.1.1 dev ppp0
NEWGW=$(ifconfig ppp0 | grep inet | cut -d":" -f3 | tail -1 | cut -d" " -f1)
/sbin/route add default gw $NEWGW
echo "DONE"
instead of what was in the script the result is this :

Code:
root at  /home# route -vn
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.1.1     0.0.0.0         255.255.255.255 UH    2      0        0 eth1
212.199.170.170 192.168.1.1     255.255.255.255 UGH   0      0        0 eth1
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 eth1
127.0.0.0       0.0.0.0         255.0.0.0       U     0      0        0 lo
root at  /home# cable-start
Using interface ppp0
Connect: ppp0 <--> /dev/pts/4
PAP authentication succeeded
local  IP address 192.116.98.231
remote IP address 212.199.17.22
NEW LINE By ZUK sleep 5
DONE
root at  /home# route -vn 
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.1.1     0.0.0.0         255.255.255.255 UH    2      0        0 eth1
212.199.17.22   0.0.0.0         255.255.255.255 UH    0      0        0 ppp0
212.199.170.170 192.168.1.1     255.255.255.255 UGH   0      0        0 eth1
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 eth1
127.0.0.0       0.0.0.0         255.0.0.0       U     0      0        0 lo
0.0.0.0         212.199.17.22   0.0.0.0         UG    0      0        0 ppp0
0.0.0.0         192.168.1.1     0.0.0.0         UG    0      0        0 ppp0
0.0.0.0         0.0.0.0         0.0.0.0         U     0      0        0 ppp0



AND WHEN I TRY TO SURF I GET HANGUPS which follows

root at  /home# Modem hangup
Connect time 0.3 minutes.
Sent 1545 bytes, received 0 bytes.
Connection terminated.
Using interface ppp0
Connect: ppp0 <--> /dev/pts/4
PAP authentication succeeded
local  IP address 192.116.98.232
remote IP address 212.199.17.22
Modem hangup
Connect time 0.1 minutes.
Sent 557 bytes, received 0 bytes.
Connection terminated.
Using interface ppp0
Connect: ppp0 <--> /dev/pts/4
 
Old 10-20-2008, 05:11 AM   #39
blackhole54
Senior Member
 
Registered: Mar 2006
Posts: 1,896

Rep: Reputation: 61
Quote:
Originally Posted by itz2000 View Post
according to #27 (if i understood right) I've tried to add those 5 lines

Code:
echo "NEW LINE By ZUK sleep 5"
sleep 5
route add -host 192.168.1.1 dev ppp0
route add default gw 192.168.1.1 dev ppp0
route del -host 192.168.1.1 dev ppp0
NEWGW=$(ifconfig ppp0 | grep inet | cut -d":" -f3 | tail -1 | cut -d" " -f1)
/sbin/route add default gw $NEWGW
echo "DONE"
Try it with just the two lines I've highlighted. (Eliminating the first 3 route commands. You can keep the echo and sleep commands if you wish.)

That said, there a a couple things I don't understand ...

Quote:
Code:
root at  /home# route -vn 
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.1.1     0.0.0.0         255.255.255.255 UH    2      0        0 eth1
212.199.17.22   0.0.0.0         255.255.255.255 UH    0      0        0 ppp0
212.199.170.170 192.168.1.1     255.255.255.255 UGH   0      0        0 eth1
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 eth1
127.0.0.0       0.0.0.0         255.0.0.0       U     0      0        0 lo
0.0.0.0         212.199.17.22   0.0.0.0         UG    0      0        0 ppp0
0.0.0.0         192.168.1.1     0.0.0.0         UG    0      0        0 ppp0
0.0.0.0         0.0.0.0         0.0.0.0         U     0      0        0 ppp0
I don't understand why the first line d(orange highlight) didn't get removed with

Code:
 route del -host 192.168.1.1 dev ppp0
And I have no idea where the last line (red highlight) came from.

EDIT: BTW, have you seen this work on a Microsoft Windows system? I thought something like that may have been hinted at earlier in this thread, but I wasn't sure.

Last edited by blackhole54; 10-20-2008 at 05:14 AM.
 
Old 10-20-2008, 07:19 AM   #40
itz2000
Member
 
Registered: Jul 2005
Distribution: Fedora fc4, fc7, Mandrake 10.1, mandriva06, suse 9.1, Slackware 10.2, 11.0, 12.0,1,2 (Current)]
Posts: 732

Original Poster
Rep: Reputation: 30
Quote:
Originally Posted by blackhole54 View Post
Try it with just the two lines I've highlighted. (Eliminating the first 3 route commands. You can keep the echo and sleep commands if you wish.)

That said, there a a couple things I don't understand ...

I don't understand why the first line d(orange highlight) didn't get removed with

Code:
 route del -host 192.168.1.1 dev ppp0
And I have no idea where the last line (red highlight) came from.

EDIT: BTW, have you seen this work on a Microsoft Windows system? I thought something like that may have been hinted at earlier in this thread, but I wasn't sure.
I think the line didn't deleted since we deleted the PPP0 line and that is a eth1 line.

I will try to get a windows routing A.S.A.P,
while trying the thing you said without the 3 routing lines, it didn't work good.


will post a answer soon.
 
Old 10-20-2008, 12:03 PM   #41
blackhole54
Senior Member
 
Registered: Mar 2006
Posts: 1,896

Rep: Reputation: 61
Quote:
Originally Posted by itz2000 View Post
I think the line didn't deleted since we deleted the PPP0 line and that is a eth1 line.
Oops! My mistake.

Quote:
I will try to get a windows routing A.S.A.P,
If it doesn't work on Microsoft, I think it is time to call your ISP. (If your ISP is Linux friendly, you might call them w/o bothering with the Microsoft setup. I thought maybe you had already tried it.) If it does work on Microsoft, take a look at its routing table. IIRC the command is

Code:
route print
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
Configuring routing table with 2 network cards chanakya Linux - Newbie 3 06-03-2008 07:04 AM
routing table selie Linux - Networking 2 05-04-2007 09:12 AM
routing table arvind kumar Linux - Networking 2 06-08-2005 11:59 PM
Help with a Routing Table maginotjr Linux - Networking 4 06-06-2005 09:49 AM
routing table upr8830 Linux - Networking 6 06-18-2003 03:04 AM

LinuxQuestions.org > Forums > Linux Forums > Linux - Networking

All times are GMT -5. The time now is 12:17 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration