connection Problems after upgrade to 8.1 form 8.0
Hello Experts,
my problem is about a ppp-chat connection which I manually to connect to a
remote machine. The is a mgetty/callback running. I get the callback and
establish a connection. That worked fine with version 8.0 but after the
upgrade to 8.1 - it seems as if I get the connection but then I am blocked.
I have added some statements which may help to show what happens. I am lost
since I am a novice dealing with firewalls. And I only guess that it call be
the firewall. Since the machines are uncritical, I can run tests without a
firewall.
How can I make sure that everything works, without a firewall? = How do I
switch all this stuff down. I tried it but something seems to bolck me
recieving data, though emailing works fine.
Thanks a lot Michael
tamboti:~ # ping 196.168.55.1
PING 196.168.55.1 (196.168.55.1) from 196.168.55.200 : 56(84) bytes of data.
<CTRL-C>
--- 196.168.55.1 ping statistics ---
15 packets transmitted, 0 received, 100% loss, time 14016ms
tamboti:~ # ssh 196.168.55.1
<CTRL-C>
tamboti:~ # SuSEfirewall2 stop
Removing filter rules and disabling IP forwarding ...
SuSEfirewall2: clearing rules now ... done
tamboti:~ # ssh 196.168.55.1
<CTRL-C>
tamboti:~ # /home/michael/tmp/peer-down
PPP link to ppp0 terminated.
tamboti:~ # SuSEfirewall2 status
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source
destination
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source
destination
Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source
destination
Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source
destination
Chain POSTROUTING (policy ACCEPT 7 packets, 461 bytes)
pkts bytes target prot opt in out source
destination
Chain OUTPUT (policy ACCEPT 7 packets, 461 bytes)
pkts bytes target prot opt in out source
destination
Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source
destination
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source
destination
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source
destination
Chain OUTPUT (policy ACCEPT 69 packets, 4951 bytes)
pkts bytes target prot opt in out source
destination
Chain POSTROUTING (policy ACCEPT 69 packets, 4951 bytes)
pkts bytes target prot opt in out source
destination
tamboti:~ #
This is the log, from the connection:
Connect: ppp0 <--> /dev/ttyS1
rcvd [LCP ConfReq id=0x1
On Wed, 9 Oct 2002 08:00:45 +0200 MichaelHoeller@t-online.de (Michael Höller) wrote:
my problem is about a ppp-chat connection which I manually to connect to a remote machine. The is a mgetty/callback running. I get the callback and
I have added some statements which may help to show what happens. I am lost since I am a novice dealing with firewalls. And I only guess that it call be the firewall. Since the machines are uncritical, I can run tests without a firewall.
How can I make sure that everything works, without a firewall? = How do I switch all this stuff down. I tried it but something seems to bolck me recieving data, though emailing works fine.
This is my understanding of the firewall on-off procedure. 1. If SuSEfirewall2 is installed, it takes precedence over the personal-firewall. 2. If you have firewall2 starting at boot, you should do a "SuSEfirewall2 stop" to disable it. Verify by doing "SuSEfirewall2 status" before and after "stop". 3. Rename /etc/ip-up to ip-up.bak. When pppd is started, ip-up will try to start the firewall, even if you ran "stop" earlier. 4. Now dialup. The firewall is not protecting ppp0. 5. If your problem is fixed, it's either the firewall configuration, or something else to do with the firewall. If your problem remains the same, it's not the firewall. -- use Perl; #powerful programmable prestidigitation
Thanks, but the problem exists even without the firewall... I have a connection: ppp0 Link encap:Point-to-Point Protocol inet addr:196.168.55.200 P-t-P:192.168.55.1 Mask:255.255.255.255 UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1 RX packets:4 errors:0 dropped:0 overruns:0 frame:0 TX packets:21 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:3 RX bytes:62 (62.0 b) TX bytes:1490 (1.4 Kb) and a ping gets send but never comes back. The same scritp worked fine under 8.0. Do you have an idea where I can start checking? Michael :-)
How can I make sure that everything works, without a firewall? = How do I switch all this stuff down. I tried it but something seems to bolck me recieving data, though emailing works fine.
This is my understanding of the firewall on-off procedure. 1. If SuSEfirewall2 is installed, it takes precedence over the personal-firewall. 2. If you have firewall2 starting at boot, you should do a "SuSEfirewall2 stop" to disable it. Verify by doing "SuSEfirewall2 status" before and after "stop". 3. Rename /etc/ip-up to ip-up.bak. When pppd is started, ip-up will try to start the firewall, even if you ran "stop" earlier. 4. Now dialup. The firewall is not protecting ppp0. 5. If your problem is fixed, it's either the firewall configuration, or something else to do with the firewall. If your problem remains the same, it's not the firewall.
I have the same problem. I have traced it to a routing problem, try the following route del default route add default netmask 0 ppp0 with any luck your network connection should now be working. Iain McMillan
Thanks,
but the problem exists even without the firewall...
I have a connection: ppp0 Link encap:Point-to-Point Protocol inet addr:196.168.55.200 P-t-P:192.168.55.1 Mask:255.255.255.255 UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1 RX packets:4 errors:0 dropped:0 overruns:0 frame:0 TX packets:21 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:3 RX bytes:62 (62.0 b) TX bytes:1490 (1.4 Kb)
and a ping gets send but never comes back.
The same scritp worked fine under 8.0. Do you have an idea where I can start checking?
Michael :-)
How can I make sure that everything works, without a firewall? = How do I switch all this stuff down. I tried it but something seems to bolck me recieving data, though emailing works fine.
This is my understanding of the firewall on-off procedure. 1. If SuSEfirewall2 is installed, it takes precedence over the personal-firewall. 2. If you have firewall2 starting at boot, you should do a "SuSEfirewall2 stop" to disable it. Verify by doing "SuSEfirewall2 status" before and after "stop". 3. Rename /etc/ip-up to ip-up.bak. When pppd is started, ip-up will try to start the firewall, even if you ran "stop" earlier. 4. Now dialup. The firewall is not protecting ppp0. 5. If your problem is fixed, it's either the firewall configuration, or something else to do with the firewall. If your problem remains the same, it's not the firewall.
I forgot I also had to use the following as well echo "0" > /proc/sys/net/ipv4/tcp_ecn Iain McMillan
I have the same problem.
I have traced it to a routing problem, try the following
route del default route add default netmask 0 ppp0
with any luck your network connection should now be working.
Iain McMillan
Thanks,
but the problem exists even without the firewall...
I have a connection: ppp0 Link encap:Point-to-Point Protocol inet addr:196.168.55.200 P-t-P:192.168.55.1 Mask:255.255.255.255 UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1 RX packets:4 errors:0 dropped:0 overruns:0 frame:0 TX packets:21 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:3 RX bytes:62 (62.0 b) TX bytes:1490 (1.4 Kb)
and a ping gets send but never comes back.
The same scritp worked fine under 8.0. Do you have an idea where I can start checking?
Michael :-)
How can I make sure that everything works, without a firewall? = How do I switch all this stuff down. I tried it but something seems to bolck me recieving data, though emailing works fine.
This is my understanding of the firewall on-off procedure. 1. If SuSEfirewall2 is installed, it takes precedence over the personal-firewall. 2. If you have firewall2 starting at boot, you should do a "SuSEfirewall2 stop" to disable it. Verify by doing "SuSEfirewall2 status" before and after "stop". 3. Rename /etc/ip-up to ip-up.bak. When pppd is started, ip-up will try to start the firewall, even if you ran "stop" earlier. 4. Now dialup. The firewall is not protecting ppp0. 5. If your problem is fixed, it's either the firewall configuration, or something else to do with the firewall. If your problem remains the same, it's not the firewall.
participants (3)
-
Iain McMillan
-
MichaelHoeller@t-online.de
-
zentara