[Gllug] Sendmail, Firewalls, SSL...

[Formi]

 Thanks for the comprehensive explanation, so resuming, the firewall
 is not telling me much appart from the ports involved and the rule
 that dropped the packet.

 It basically works as far as I know it, so I shouldn't be very worried
 about it.

 I shall recommend giptables, really nice and easy firewall.

 www.giptables.org 



On Tue, 25 Jun 2002 tet at accucard.com wrote:

> 
> >Sorry for the missunderstanding, what I want to know is where to find info 
> >about those TOS=0x00, etc. I know those come from the tcp/ip and udp 
> >headers. I would normally use ethereal but I'm on a dial-up link to the 
> >server and I would just prefer a more direct visual approach.
> 
> TOS is type of service, part of the IP packet header, which specifies
> how routers are to treat the packet. For example, Consider the
> situation where there are two routes between A & B, one via a cheap
> but unreliable dial up link, and one via faster and more reliable,
> but more expensive leased line. It would be reasonable to send
> "unimportant" traffic (e.g., TFTP) via the cheap link, and more
> critical stuff (such as DNS zone transfers) via the reliable link.
> So certain applications will mark their packets with type of service
> flags, so that routers can Do The Right Thing (tm).
> 
> The TOS field can have the following values (details in RFC1349 and
> RFC1455):
> 
> 	0  -- normal
> 	1  -- minimize delay
> 	2  -- maximize throughput
> 	4  -- maximize reliability
> 	8  -- minimize cost
> 	15 -- maximize security
> 
> The PREC field specifies precedence (i.e., "importance") of the packet,
> and can be one of:
> 
> 	0  -- normal
> 	1  -- priority
> 	2  -- immediate
> 	3  -- flash
> 	4  -- flash override
> 	5  -- critical
> 	6  -- internetwork control
> 	7  -- network control
> 
> But all you really need to know is that the higher the value, the better
> treatment it'll be given by routers.
> 
> TTL is time to live. After a packet has made this many hops (i.e., has
> been through this many routers on it's journey from A to B), it is
> considered unviable, and is destroyed. This is to prevent routing loops
> bringing the network grinding to a halt.
> 
> ID=3618 is almost certainly the fragment identifier, a 16-bit number
> that enables fragmented packets to be reassembled at destination.
> 
> The LEN field is probably the total packet length. Not sure why you
> have two of them, though. Both 37 and 57 are a tad on the short side
> for a DNS packet, so maybe that's why it's being dropped.
> 
> Note that both PREC and TOS have been superseded by the differentiated
> services codepoint in RFC2474...
> 
> Note also that there's information in the IP header that isn't being
> logged here, which may be the reason the packet's being dropped. For
> example, the fragmentation flags aren't logged, and there's no mention
> of whether there are any IP options.
> 
> Tet
> 
> 
> 

-- 
				
    V   
   . .                              Formi		
    v 
   / \ GZ           MDK 8.2 ThinkPad 560E
  // \\/   
 /( _ )     Linux Registered User #235743
  ^   ^  	     	



-- 
Gllug mailing list  -  Gllug at linux.co.uk
http://list.ftech.net/mailman/listinfo/gllug