/* HINT: Search archives @ http://www.indyramp.com/masq/ before posting! */
PPPoE requires an MTU of no greater than 1492 (8 bytes are absorbed by the PPPoE
protocol) and if the link is allowed to auto-discover its MTU, it gets 1492.
At one point I tried setting the MTU on all interfaces to 1492 or less, to no avail.
(eth0<--->ppp0, both to 1492, eth1 to the internal network to 1492 and the MacOS
clients to 576 - which is what they get when MTU discovery is off).
The firewall can access everything, no problem. Its definitely a MASQ related problem.
Aside from the problems with certain web sites, the setup cooks - the MacOS machines
get 150KB/sec through the firewall, a switch, and an airport (wavelan) hub - while
compiling a kernel.
Ugh.
Anyone have luck with the 2.3.x kernels and the new netfilter code?
At 4:15 PM -0600 1/20/00, Fuzzy Fox wrote:
>Carl MacDonald <[EMAIL PROTECTED]> wrote:
>>
>> A much simpler solution is to increase the MTU of the PPP connection
>> to 1500 (or whatever your internal network MTU is).
>
>If I understand PPP-over-Ethernet (and I do not), there is some sort of
>technical difficulty that prevents the MTU from being raised higher than
>1492. I don't know what that reason might be, but I see it posted often
>enough to believe it.
>
>Then again, maybe you have something there. It could be that the MTU of
>the PPPoE interface will always be "MTU of ethernet minus 8". In which
>case, perhaps the MTU of the outgoing ethernet interface could be raised
>to 1508. But that violates RFC specifications, so probably has a good
>chance of messing things up...
>
>> Being a network server engineer I have seen this kind of bug in many
>> products that are doing any kind of protocol conversion with packet
>> sizes differing between inbound and outbound data.
>
>Yes, and in fact, it is difficult to place the nature of this bug. I
>have seen discussions among the Linux gurus, in which they were unable
>to pin the nature of the problem down to anything internal to Linux,
>because the problem could easily be in the remote network equipment.
>
>> In the case of NAT conversions, I can imagine this to be a sticky
>> problem keeping things like sequence numbers correct...
>
>In IP Masq, this is handled more-or-less well by reconstructing
>fragmented packets before forwarding them. Thus, they are essentially
>rebuilt and refragmented, but it does prevent fragments from being lost,
>since fragments do not carry port information...
>
Mark Scandariato
Cary, NC
[EMAIL PROTECTED]
_______________________________________________
Masq maillist - [EMAIL PROTECTED]
Admin requests can be handled at http://www.indyramp.com/masq-list/ -- THIS INCLUDES
UNSUBSCRIBING!
or email to [EMAIL PROTECTED]
PLEASE read the HOWTO and search the archives before posting.
You can start your search at http://www.indyramp.com/masq/
Please keep general linux/unix/pc/internet questions off the list.
