We help IT Professionals succeed at work.

Check out this week's podcast, "Dairy Farms to Databases: Community's Hand in Technology"Listen Now

x

Active Diald does not work occasionally

simonff
simonff asked
on
333 Views
Last Modified: 2010-03-17
I have a typical setup with a local network and a Linux server on a single phone line. I have diald and IP masq installed. It works great, but once in a few days diald makes the connection completely, but no IP traffic is possible. Here is some output:

#ping 194.220.146.5 (the other end of connection)
ping: sendto: Operation not permitted
PING 194.220.146.5 (194.220.146.5): 56 data bytes
ping: wrote 194.220.146.5 64 chars, ret=-1

#ifconfig ppp0
ppp0      Link encap:Point-Point Protocol  
          inet addr:194.135.178.215  P-t-P:194.220.146.5
Mask:255.255.255.0
          UP POINTOPOINT RUNNING  MTU:1500  Metric:1
          RX packets:193 errors:0 dropped:0 overruns:0
          TX packets:237 errors:0 dropped:0 overruns:0

I am not even sure if the problem is with diald or IP masq.
Any suggestions?

Thanks,
Simon
Comment
Watch Question

Commented:
Try the above again, from both your masqueraded machine, and from your directly connected machine. This will tell you whether the problem is with the masquerading setup, or the PPP link.

The output from route -n on both machihnes when the problem manifests would also be useful in tracking this one down.

Author

Commented:
Alas, I cannot ping from other machines - UDP is not allowed through the masq setup, and I cannot use ifconfig because they are Win 95 machines. The above output applied to the directly connected machine.
I will monitor the 'route -n' output when this strange thing happens again, but I do not quite like what I have even under the normal conditions (note the multiple entries). Here 200.200.200.0 is our local network.

Fresh after reboot:
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
194.135.176.5   0.0.0.0         255.255.255.255 UH    1      0        0 sl0
200.200.200.0   0.0.0.0         255.255.255.0   U     0      0        1 eth0
127.0.0.0       0.0.0.0         255.0.0.0       U     0      0        0 lo
0.0.0.0         0.0.0.0         0.0.0.0         U     1      0        0 sl0

While online:
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
194.135.176.5   0.0.0.0         255.255.255.255 UH    0      0        0 ppp0
194.135.176.5   0.0.0.0         255.255.255.255 UH    1      0        0 sl0
194.220.146.5   0.0.0.0         255.255.255.255 UH    0      0        1 ppp0
200.200.200.0   0.0.0.0         255.255.255.0   U     0      0      316 eth0
127.0.0.0       0.0.0.0         255.0.0.0       U     0      0      129 lo
0.0.0.0         0.0.0.0         0.0.0.0         U     0      0        3 ppp0
0.0.0.0         0.0.0.0         0.0.0.0         U     1      0      110 sl0
Commented:
This one is on us!
(Get your first solution completely free - no credit card required)
UNLOCK SOLUTION

Author

Commented:
Silly me... :) I had this bogus IP address as remote_IP in diald.conf... Thanks. Say, do you know where I can get wildmat sources or the whole implementation of XPAT command?

Author

Commented:
Oops, it was premature. I have just had the same problem again. See the routing table, it is quite good now. What else can be wrong?

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
194.220.146.5   0.0.0.0         255.255.255.255 UH    0      0        1 ppp0
194.220.146.5   0.0.0.0         255.255.255.255 UH    1      0        0 sl0
200.200.200.0   0.0.0.0         255.255.255.0   U     0      0      263 eth0
127.0.0.0       0.0.0.0         255.0.0.0       U     0      0       77 lo
0.0.0.0         0.0.0.0         0.0.0.0         U     0      0        2 ppp0
0.0.0.0         0.0.0.0         0.0.0.0         U     1      0        4 sl0

Commented:
Routing table looks fine to me now - I have a very similar setup, and my routing table looks just like that, so I'd say your routing is set up right.

You're getting 'Operation not permitted' as well, so that seems to suggest that something else is up. What you might want to do, is , next time the problem occurs, try running tcpdump on the ppp0 interface, then trying to ping. See if any packets go out at all - if they don't, something is wrong with the logic somewhere, as opposed to the physical connection being at fault. You could put diald into debug mode - add 'debug 31' to the end of your diald.conf - this logs *loads* of stuff to syslog, and might give you some pointers.

Author

Commented:
OK, here is something that I have caught during the last trouble period.

Diald debug messages (debug flags at 255, rule 30 is the very last one - accept any):
Jul  5 19:01:18 rrg diald[216]: filter accepted rule 30 proto 89 len 64 packet 194.220.146.5,0 => 224.0.0.5,0
Jul  5 19:01:18 rrg diald[216]: Adding connection 134680648 @ 868114878 - timeout 30

Tcpdump results:
22:21:06.090000 194.220.146.5 > 224.0.0.5: OSPFv2-hello 44: backbone [tos 0xc0] [ttl 1]
22:21:16.090000 194.220.146.5 > 224.0.0.5: OSPFv2-hello 44: backbone [tos 0xc0] [ttl 1]
And so on...

Does that help to diagnose the problem, or should I run tcpdump in a more verbose mode?
Unlock the solution to this question.
Join our community and discover your potential

Experts Exchange is the only place where you can interact directly with leading experts in the technology field. Become a member today and access the collective knowledge of thousands of technology experts.

*This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

OR

Please enter a first name

Please enter a last name

8+ characters (letters, numbers, and a symbol)

By clicking, you agree to the Terms of Use and Privacy Policy.