Dear readers,
if I possibly refer to a known bug of diald-0.16, please excuse the repetition,
but I couldn't find a hint in the manual pages nor elsewhere.
I watched a rather mysterious happening when I expected diald to bring or hold
the link down:
the link was hold/brought up caused by packets which came from an IP address
outside of my system, moreover, the IP number is one of my provider's pool!
The destination also is anywhere in the world.
One line of my /var/log/messages about an accepted rule:
Aug 7 15:59:20 terra diald[10978]: filter accepted rule 4 proto 6 len 40 seq
e9443c81 ack 45e0f8c8 flags FIN ACK packet 129.187.24.161,9967 =>
209.68.62.170,80
[rule 4 is "accept tcp 5 ip.tot_len=40,tcp.syn"]
As you can see at the output of 'ifconfig', none of the addresses is one of mine
(dynamically assigned) or the ISP's pointopoint address.
terra:/home/thomas # ifconfig
[...]
sl0 Link encap:Serial Line IP
inet addr:192.168.1.1 P-t-P:192.168.1.2 Mask:255.255.255.0
UP POINTOPOINT RUNNING MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0
TX packets:8 errors:0 dropped:0 overruns:0
ppp0 Link encap:Point-Point Protocol
inet addr:129.187.24.205 P-t-P:129.187.24.125 Mask:255.255.0.0
UP POINTOPOINT RUNNING MTU:1500 Metric:1
RX packets:175 errors:0 dropped:0 overruns:0
TX packets:310 errors:0 dropped:0 overruns:0
Now my question (two parts):
a. If my link is up: How can the transfer of packets from an IP address of my
provider's LAN to another one anywhere in the world prevent my diald from
bringing the link down?
[IOW: Why seem these packets travelling over my link which has absolute another
address?]
b. If my link is down: How can packets from an IP address of my provider's LAN
cause my diald to bring the link up?
Moreover: When I stopped diald and terminated pppd to kill the link, and then
started diald again, this aparition began immediately again!
BTW: I use the standard filter rules which I leaved unchanged except a few
timeouts due to the phone company's shortest impulse duration of 90 seconds (I
won't leave a connection identity longer than 80 seconds in the connection set).
And: I'm sure that I have killed all TCP/IP clients which I started before!
Especially due to my question b. I assume there is a buffer inside my system
where some packets are held back and then, continously sent out - even when
diald has been shut down and restarted again -, cause diald to hold/bring up the
link.
But here I'm at the end with my latin (is this a possible phrase in English?),
so can anyone give me a hint (perhaps an additional tricky filter rule to ignore
packets of the subnet 129.187.24.0, just as a workaround)?
Thanks a lot for helping!
CU, Thomas
P.S.: I appended an example of output to /var/log/messages where the link has
been brought up again caused by such a mysterious packet as I mentioned above:
-------------------------------------------------------------------------------
Aug 7 17:34:44 terra diald[11120]: filter accepted rule 8 proto 6 len 40 seq
4af8d240 ack c482bcf flags ACK packet 204.244.59.246,7746 =>
129.187.24.46,10284
Aug 7 17:36:00 terra diald[11120]: filter accepted rule 6 proto 6 len 40 seq
96a8349d ack f5553d6e flags FIN ACK packet 129.187.24.143,10277 =>
209.63.161.138,80
Aug 7 17:38:00 terra diald[11120]: filter accepted rule 6 proto 6 len 40 seq
96a8349d ack f5553d6e flags FIN ACK packet 129.187.24.143,10277 =>
209.63.161.138,80
Aug 7 17:39:47 terra diald[11120]: Closing down idle link.
Aug 7 17:39:48 terra diald[11120]: Closed fwdfd
Aug 7 17:39:48 terra diald[11120]: Changed snoop device to sl0
Aug 7 17:39:48 terra diald[11120]: new state STOP_LINK action 134541104 timeout
60
Aug 7 17:39:48 terra pppd[11296]: Terminating on signal 2.
Aug 7 17:39:48 terra pppd[11296]: Connection terminated.
Aug 7 17:39:48 terra pppd[11296]: Exit.
Aug 7 17:39:50 terra diald[11120]: new state DISCONNECT action 134541952
timeout 300
Aug 7 17:39:50 terra diald[11120]: new state CLOSE action 134542096 timeout -1
Aug 7 17:39:51 terra diald[11120]: Delaying 5 seconds before clear to dial.
Aug 7 17:39:56 terra diald[11120]: new state RETRY action 134542400 timeout -1
Aug 7 17:39:57 terra diald[11120]: new state DOWN action 134539824 timeout -1
>>> Aug 7 17:40:00 terra diald[11120]: filter accepted rule 6 proto 6 len 40 seq
>>> 96a8349d ack f5553d6e flags FIN ACK packet 129.187.24.143,10277 =>
>>> 209.63.161.138,80
Aug 7 17:40:00 terra diald[11120]: new state CONNECT action 134540080 timeout
60
Aug 7 17:40:01 terra diald[11120]: Running connect (pid = 11340).
Aug 7 17:40:05 terra diald[11120]: new state START_LINK action 134540832
timeout 60
Aug 7 17:40:05 terra diald[11120]: Running pppd (pid = 11341).
Aug 7 17:40:05 terra pppd[11341]: pppd 2.2.0 started by root, uid 0
Aug 7 17:40:05 terra pppd[11341]: Using interface ppp0
Aug 7 17:40:05 terra pppd[11341]: Connect: ppp0 <--> /dev/modem
Aug 7 17:40:05 terra pppd[11341]: Remote message:
Aug 7 17:40:05 terra pppd[11341]: local IP address 129.187.24.68
Aug 7 17:40:05 terra pppd[11341]: remote IP address 129.187.24.126
Aug 7 17:40:05 terra pppd[11341]: ppp not replacing existing default route to
sl0[0.0.0.0]
Aug 7 17:40:05 terra diald[11120]: New addresses: local 129.187.24.68, remote
129.187.24.126.
Aug 7 17:40:06 terra diald[11120]: new state UP action 134541264 timeout 120
Aug 7 17:40:06 terra diald[11120]: Changed snoop device to ppp0
Aug 7 17:42:00 terra diald[11120]: filter accepted rule 6 proto 6 len 40 seq
96a8349d ack f5553d6e flags FIN ACK packet 129.187.24.143,10277 =>
209.63.161.138,80
-
To unsubscribe from this list: send the line "unsubscribe linux-diald" in
the body of a message to [EMAIL PROTECTED]
