Fuzzy Fox wrote: > > orpheus <[EMAIL PROTECTED]> wrote: > > > > The connection is made OK, and the protocol headers are exchanged but > > nothing else - for example in the POP3 case USER and PASS are sent, > > but after RETR is issued I get the size of the message and no data. > > This problem is reported regularly on this list, and it can have a > couple of different causes. The basic problem is that small packets are > getting through just fine, but large packets are not. > > One reason for this might be that the packets are getting fragmented > during their travel across the net, and the masquerade system cannot > figure out how to route the fragments to the final destination, because > the port and control information is only found in the first packet; the > other packets don't have enough information to identify that they are to > be masqueraded. This can be rectified, though, by configuring your masq > box to re-assemble fragments before forwarding them on. The kernel > option for this is CONFIG_IP_ALWAYS_DEFRAG. > > Another reason is a bit more mysterious, and involves routers that have > different MTU sizes, and dropping of packets that don't happen to match > the size they expect. I've never heard an explanation that satisifies > me about this problem, but I do know that the solution involves setting > your own MTU size to match what is typical for an ethernet config- > uration. That is, on your PPP (and of course, your ethernet) interface, > make sure the MTU is set to 1500. It might be worth observing that over in comp.dcom.sys.cisco (and other places as well) small battles occasionally rage about the effects of filtering ICMP. Paranoid router admins have started to experiment with dropping all ICMP, thus breaking path MTU discovery (and other atomic features of TCP/IP). I have no idea if compiling MTU discover OUT of the linux kernel would fix the situation. It is pretty clear, though, that some TCP/IP features need to be redesigned/reengineered to increase security and that IETF policy of liberal acceptance- strict emmitance is reaching even further down the stack than, perhaps, initially intended. Boy, IPv6 should prove to be even more interesting (in the true vain of the Chinese curse) once available for general consumption. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] For daily digest info, email [EMAIL PROTECTED]
