Hello, I have a SMTP client that when it is sending large email drops the connection with the server after some timeouts. Small emails are sent correctly. The error from the SMTP client sugests an path MTU discovery problem. If I execute "shorewall clean" and send the large email, it works as expected. I attached the dump file but maybe it is a bit noised. Glandvador. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer''s challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/
Gland Vador wrote:> Hello, > > I have a SMTP client that when it is sending large email drops the connection with the server after some timeouts. Small emails are sent correctly. The error from the SMTP client sugests an path MTU discovery problem. > > If I execute "shorewall clean" and send the large email, it works as expected. > > I attached the dump file but maybe it is a bit noised.I have communicated with Gland Vador via IRC but wanted to follow up here also. First, I don''t believe that this problem has anything to do with MTU discovery. The mail client is running on the firewall and all ICMP traffic is explicitly enabled fw<->net. Second, I recommend that the /etc/shorewall/policy file be modified to log connection attempts dropped by the net->* policies (place ''info'' in the LOG LEVEL column). Third, and germane to the SMTP problem, is that all outbound traffic is being placed in class 1:113 because of the blanket mark rule at the bottom of both tcfor and tcout. These blanket rules should be moved to the top of the tcrules file because tcrules are not terminating -- that is, even if a packet matches one of the rules, it still continues down the chain. So if a later rule also matches, it is that later rule''s mark that the packet ends up with. This is explained at the top of the shorewall-tcrules manpage. -Tom -- Tom Eastep \ The ultimate result of shielding men from the Shoreline, \ effects of folly is to fill the world with fools. Washington, USA \ -Herbert Spencer http://shorewall.net \________________________________________________ ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer''s challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/
Tom Eastep wrote:> > Third, and germane to the SMTP problem, is that all outbound traffic is > being placed in class 1:113 because of the blanket mark rule at the > bottom of both tcfor and tcout. These blanket rules should be moved to > the top of the tcrules file because tcrules are not terminating -- that > is, even if a packet matches one of the rules, it still continues down > the chain. So if a later rule also matches, it is that later rule''s mark > that the packet ends up with. This is explained at the top of the > shorewall-tcrules manpage. >The OP has confirmed that correcting the TC configuration has eliminated the original SMTP program. -Tom -- Tom Eastep \ The ultimate result of shielding men from the Shoreline, \ effects of folly is to fill the world with fools. Washington, USA \ -Herbert Spencer http://shorewall.net \________________________________________________ ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer''s challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/