Re: Lost packets, un-masqueraded retransmits

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Brilliant - thank you for your detailed response Grant, you're completely correct. The ICMP errors are clearly being dropped somewhere outside my control, and the backing off of the retries sending the full-size packet fits perfectly.

Good.

Knowing now what the issue is, I can find the millions of web pages about the same problem - apologies for bothering you with such a FAQ! The MSS clamp works perfectly.

Nonsense!  You were not a bother at all.  This mail list is for exactly these types of questions.  IMHO the Linux / Unix community is nothing if we do not try to help each other but instead compete for each and every boxen to administer like so many of the Windows admins that I know.  :(

Any thoughts regarding the 'leaking packets', reaching the external network without getting masqueraded? I'm monitoring now to see if I still get them, which I possibly won't since they all seemed to be retransmits - I'll post again if they're still around. But here's the detail of one such packet, grabbed from ppp0 on the gateway:

Well possibly.  You are NATing in the nat table POSTROUTING chain as you should be.  However I believe that packets only traverse the nat table if they are considered NEW.  (I'm not sure how this works (for the rest of the packets, conntrack?) but I believe it to be the case.)  Thus if the portion of the NATing / MASQUERADEing code does not alter the source IP for packets that it has already seen one time I could see how your unaltered packets are getting out.  Thus I would wonder if you could not put a rule in your filter table OUTPUT chain to only allow packets out your internet interface if they have a source address of your globally routable IP.

I do think this is an issue that should be further documented and brought to the attention of the Net Filter Developers to see what they think of it.  Unfortunetly I am not one of the devls and thus can not help you much more than that.

0000  00 04 02 00 00 00 00 00 00 00 00 00 00 00 08 00   ................
0010  45 00 00 28 4e 16 40 00 7f 06 21 f8 c0 a8 1f bf   E..(N.@...!.....
0020  c2 42 e9 17 06 01 00 50 6b ba 7a 19 88 1d 82 de   .B.....Pk.z.....
0030  50 11 ff ff 2c f1 00 00                           P...,...

[unpacking details from ethereal...]
Frame 6655 (56 bytes on wire, 56 bytes captured)
    Arrival Time: Sep  2, 2005 12:31:01.442977000
    Time delta from previous packet: 0.300389000 seconds
    Time since reference or first frame: 882.838297000 seconds
    Frame Number: 6655
    Packet Length: 56 bytes
    Capture Length: 56 bytes
    Protocols in frame: sll:ip:tcp
Linux cooked capture
    Packet type: Sent by us (4)
    Link-layer address type: 512
    Link-layer address length: 0
    Source: <MISSING>
    Protocol: IP (0x0800)
Internet Protocol, Src: 192.168.31.191 (192.168.31.191), Dst: 194.66.233.23 (194.66.233.23)
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
        0000 00.. = Differentiated Services Codepoint: Default (0x00)
        .... ..0. = ECN-Capable Transport (ECT): 0
        .... ...0 = ECN-CE: 0
    Total Length: 40
    Identification: 0x4e16 (19990)
    Flags: 0x04 (Don't Fragment)
        0... = Reserved bit: Not set
        .1.. = Don't fragment: Set
        ..0. = More fragments: Not set
    Fragment offset: 0
    Time to live: 127
    Protocol: TCP (0x06)
    Header checksum: 0x21f8 [correct]
    Source: 192.168.31.191 (192.168.31.191)
    Destination: 194.66.233.23 (194.66.233.23)
Transmission Control Protocol, Src Port: 1537 (1537), Dst Port: http (80), Seq: 0, Ack: 0, Len: 0
    Source port: 1537 (1537)
    Destination port: http (80)
    Sequence number: 0    (relative sequence number)
    Acknowledgement number: 0    (relative ack number)
    Header length: 20 bytes
    Flags: 0x0011 (FIN, ACK)
        0... .... = Congestion Window Reduced (CWR): Not set
        .0.. .... = ECN-Echo: Not set
        ..0. .... = Urgent: Not set
        ...1 .... = Acknowledgment: Set
        .... 0... = Push: Not set
        .... .0.. = Reset: Not set
        .... ..0. = Syn: Not set
        .... ...1 = Fin: Set
    Window size: 65535
    Checksum: 0x2cf1 [correct]
    SEQ/ACK analysis
        TCP Analysis Flags
            This frame is a (suspected) retransmission
            The RTO for this segment was: 0.600510000 seconds
            RTO based on delta from frame: 6653

Wow!  I have not seen so much detail on a packet in a LONG time.  At this moment I'm too out of it (I've been fighting a bug) to make much sense out of it.  Looking it over any way the only thing that I do see is the line that states "...This frame is a (suspected) retransmission... ...RTO based on delta from frame: 6653...".



Grant. . . .


[Index of Archives]     [Linux Netfilter Development]     [Linux Kernel Networking Development]     [Netem]     [Berkeley Packet Filter]     [Linux Kernel Development]     [Advanced Routing & Traffice Control]     [Bugtraq]

  Powered by Linux