(No subject header)

(No subject header)

[John Black]

I have a NAT question for everyone.  
 
At work i have a single static IP address that all of the
computers in the LAN uses for the outside world.  My
firewall is also acting as a dns server.  
 
Question 1: When i try to ssh in to a computer from the
outside world it follows the first rule.  But when i change
ssh to listen to a certain address and port it still
defaults to the first rule?
 
Question 2: if the DNS server was running on a server behind
the firewall would this help sloves this problem?
 
 
thanks
john

Re: (No subject header)

[Antony Stone]

On Wednesday 28 July 2004 5:01 pm, John Black wrote:

> At work i have a single static IP address that all of the
> computers in the LAN uses for the outside world.  My
> firewall is also acting as a dns server.

Okay, so you have one public IP address, and all your internal machines are 
masqueraded behind that one address for outbound connections; also your 
firewall runs DNS (although it's not clear whether you mean it runs caching 
DNS for internal clients, or also authoritative DNS for external queries 
about your domain).

> Question 1: When i try to ssh in to a computer from the
> outside world it follows the first rule.

What is "the first rule"?

> But when i change ssh to listen to a certain address and port it still
> defaults to the first rule?

What is the question here?

> Question 2: if the DNS server was running on a server behind
> the firewall would this help sloves this problem?

Don't know.   Tell us what the problem is (and what sort of DNS server you're 
running), and we might be able to think of the answer.

Posting your netfilter rules might help us understand what you're asking 
about, as well.

Regards,

Antony.

-- 
Success is a lousy teacher.  It seduces smart people into thinking they can't 
lose.

 - William H Gates III

                                                     Please reply to the list;
                                                           please don't CC me.

Re: (No subject header)

[John Black]

> Okay, so you have one public IP address, and all your internal machines
are
> masqueraded behind that one address for outbound connections; also your
> firewall runs DNS (although it's not clear whether you mean it runs
caching
> DNS for internal clients, or also authoritative DNS for external queries
> about your domain).

i have a caching dns sserver for the inside of the lan, but external queries
are
handled by the companies dns server

> What is "the first rule"?
iptables -t nat -A PREROUTING -d X.X.X.X -p tcp --dport 22 -j DNAT \
-- to 192.168.1.89:2222 (ares)

iptables -t nat -A PREROUTING -d X.X.X.X -p tcp --dport 22 -j DNAT \
-- to 192.168.1.90:22222 (zeus)

i asigned that workstation to listen to that port.

when i ssh into zeus from the outside world it says connecting to zeus, but
at the bash prompt it is ares

im running BIND 9 on red hat 9

thanks
john

RE: (No subject header)

[Jason Opperisano]

> iptables -t nat -A PREROUTING -d X.X.X.X -p tcp --dport 22 -j DNAT \
> -- to 192.168.1.89:2222 (ares)
>
> iptables -t nat -A PREROUTING -d X.X.X.X -p tcp --dport 22 -j DNAT \
> -- to 192.168.1.90:22222 (zeus)

If X.X.X.X in that first rule == X.X.X.X in that second rule--the second rule will never be matched.

You're giving netfilter 3 pieces of information to use to decide whether you have a match:

Protocol = TCP
Dest IP = X.X.X.X
Dest Port = 22

Given those conditions, how will it skip the first rule and make it to the second?

I would reverse your theory.  Let the hosts on the inside listen on the standard SSH port (TCP 22), and use different ports on the external side:

iptables -t nat -A PREROUTING -d X.X.X.X -p tcp --dport 2222 -j DNAT \
 --to 192.168.1.89:22 (ares)

iptables -t nat -A PREROUTING -d X.X.X.X -p tcp --dport 2223 -j DNAT \
 --to 192.168.1.90:22 (zeus)

And then use:	ssh -p 2222 X.X.X.X to connect to ares
And:			ssh -p 2223 X.X.X.X to connect to zeus

-j

Re: (No subject header)

[John Black]

yes X.X.X.X = my static ip address

>If X.X.X.X in that first rule == X.X.X.X in that second rule--the second
rule will never be matched.

ill give it a try


thanks
john

(No subject header)

[John Black]

 
I'm trying to setup a connection to port 3389 on a windows
2003 server.

my server 80.1.1.1

public ip address for windows server110.20.30.15

private ip address for windows server 192.168.0.15


is this right:
iptbles -t nat -A PREROUTING -d 80.1.1.1 -p tcp \
--dport 3389   -j DNAT --to 110.20.30.15:2289
iptbles -t nat -A PREROUTING -d 110.20.30.15 -p tcp\
--dport 3389   -j DNAT --to 192.168.0.15:2289

 

Re: (No subject header)

[John Black]

> You also need forward statment
> 
> iptables -A FORWARD -d 110.20.30.15 -p tcp --dport 2289 -j
> ACCEPT
would my server need to be in that forwarding statement?
iptables -A FORWARD -d 80.1.1.1 -p tcp --dport 3389 -j
ACCEPT

because i want to allow only this address 80.1.1.1 access to
this port.

> also in case it matters to you, you misspelled iptables
> below.
it was just a typeo

Re: (No subject header)

[Brent Clark]

John Black wrote:
>  
> I'm trying to setup a connection to port 3389 on a windows
> 2003 server.
> 
> my server 80.1.1.1
> 
> public ip address for windows server110.20.30.15
> 
> private ip address for windows server 192.168.0.15
> 
> 
> is this right:
> iptbles -t nat -A PREROUTING -d 80.1.1.1 -p tcp \
> --dport 3389   -j DNAT --to 110.20.30.15:2289
> iptbles -t nat -A PREROUTING -d 110.20.30.15 -p tcp\
> --dport 3389   -j DNAT --to 192.168.0.15:2289

Hi

This is my ruleset

Hope it helps

$IPT -t filter -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPT -t nat -A PREROUTING -i eth0 -p tcp -s 1.2.3.4 --dport 3389 -j DNAT 
--to 192.168.111.124:3389
$IPT -t filter -A FORWARD -i eth0 -p tcp -s 1.2.3.4 --dport 3389 -d 
192.168.111.124 -j ACCEPT

Kind Regards
Brent Clark

(No subject header)

[Milton Miller]

[Hmm, why did this not appear in patchwork.kernel.org?  Now
I have to guess a CC list.]

On Wed, 26 May 2010 around 22:43:50 -0400 (EDT), Len Brown wrote:
> From: Len Brown <len.brown@intel.com>
> 
> TS_POLLING set tells the scheduler a task will poll
> need_resched() to look for work.
> 

True

> TS_POLLING clear tells resched_task() and wake_up_idle_cpu()
> that the remote CPU is sleeping in idle, and thus requires
> a reschedule interrupt to wake them to notice work.

No, that only applies to the idle task.


> 
> Update the description of TS_POLLING to reflect how it works.
> "cleared when sleeping in idle, requiring reschedule interrupt"

That would imply its set for every normal task that is not in some
kind of sleep state.


> 
> Signed-off-by: Len Brown <len.brown@intel.com>
> Acked-by: Peter Zijlstra <peterz@infradead.org>

> -#define TS_POLLING		0x0004	/* true if in idle loop
> -					   and not sleeping */
> +#define TS_POLLING		0x0004	/* clear when sleeping in idle
> +					   requiring reschedule interrupt */

How about "idle task polling need_resched, skip sending interrupt"?

milton

(No subject header)

[Milton Miller]

[Hmm, why did this not appear in patchwork.kernel.org?  Now
I have to guess a CC list.]

On Wed, 26 May 2010 around 22:43:50 -0400 (EDT), Len Brown wrote:
> From: Len Brown <len.brown@intel.com>
> 
> TS_POLLING set tells the scheduler a task will poll
> need_resched() to look for work.
> 

True

> TS_POLLING clear tells resched_task() and wake_up_idle_cpu()
> that the remote CPU is sleeping in idle, and thus requires
> a reschedule interrupt to wake them to notice work.

No, that only applies to the idle task.


> 
> Update the description of TS_POLLING to reflect how it works.
> "cleared when sleeping in idle, requiring reschedule interrupt"

That would imply its set for every normal task that is not in some
kind of sleep state.


> 
> Signed-off-by: Len Brown <len.brown@intel.com>
> Acked-by: Peter Zijlstra <peterz@infradead.org>

> -#define TS_POLLING		0x0004	/* true if in idle loop
> -					   and not sleeping */
> +#define TS_POLLING		0x0004	/* clear when sleeping in idle
> +					   requiring reschedule interrupt */

How about "idle task polling need_resched, skip sending interrupt"?

milton

Re: (No subject header)

[Len Brown]

On Thu, 27 May 2010, Milton Miller wrote:

> 
> [Hmm, why did this not appear in patchwork.kernel.org?  Now
> I have to guess a CC list.]
> 
> On Wed, 26 May 2010 around 22:43:50 -0400 (EDT), Len Brown wrote:
> > From: Len Brown <len.brown@intel.com>
> > 
> > TS_POLLING set tells the scheduler a task will poll
> > need_resched() to look for work.
> > 
> 
> True
> 
> > TS_POLLING clear tells resched_task() and wake_up_idle_cpu()
> > that the remote CPU is sleeping in idle, and thus requires
> > a reschedule interrupt to wake them to notice work.
> 
> No, that only applies to the idle task.
> 
> 
> > 
> > Update the description of TS_POLLING to reflect how it works.
> > "cleared when sleeping in idle, requiring reschedule interrupt"
> 
> That would imply its set for every normal task that is not in some
> kind of sleep state.

you're right, just the idle task sets this flag.

> > Signed-off-by: Len Brown <len.brown@intel.com>
> > Acked-by: Peter Zijlstra <peterz@infradead.org>
> 
> > -#define TS_POLLING		0x0004	/* true if in idle loop
> > -					   and not sleeping */
> > +#define TS_POLLING		0x0004	/* clear when sleeping in idle
> > +					   requiring reschedule interrupt */
> 
> How about "idle task polling need_resched, skip sending interrupt"?

I think that is an improvement over my wording.

Though technically we're not polling need_resched in the case
I have in mind.  The hardware is snooping any write to the thread flags
via MONITOR/MWAIT trigger address.

cheers,
-Len Brown, Intel Open Source Technology Center

Doubt about CRTSCTS preprocessor macro definition in termbits.h file

[Ramya Desai]

Dear All,

I did not understand the CRTSCTS preprocessor macro which is defined
in termbits.h file.

http://lxr.linux.no/linux+v2.6.36/include/asm-generic/termbits.h

As per the typedefs defined in the beginning of the file, the c_cflag
is unsigned int member in the struct termios structure. The CRTSCTS is
defined in the file as a 48 bit value.

#define CRTSCTS   020000000000  /* flow control */

I saw the following snippet in one of the serial applications.

struct termios newtio;
newtio.c_cflag = B9600 | CRTSCTS | CS8 | CLOCAL | CREAD;

My question is, the c_cflag is a 32 bit value member and the CRTSCTS
is a 48 bit value. How CRTSCTS is accommodates into c_cflag variable?
Please let me know, if my interpretation is wrong.

Thanks in advance.

Regards,
Ramya.

(No subject header)

[Milton Miller]

On Tue Nov 09 2010 around 02:27:38 EST, Ramya Desai wrote:
> I did not understand the CRTSCTS preprocessor macro which is defined
> in termbits.h file.
..
> As per the typedefs defined in the beginning of the file, the c_cflag
> is unsigned int member in the struct termios structure. The CRTSCTS is
> defined in the file as a 48 bit value.
> 
> #define CRTSCTS 020000000000 /* flow control */

That is not a 48 bit value.

> 
> I saw the following snippet in one of the serial applications.
> 
> struct termios newtio;
> newtio.c_cflag = B9600 | CRTSCTS | CS8 | CLOCAL | CREAD;
> 
> My question is, the c_cflag is a 32 bit value member and the CRTSCTS
> is a 48 bit value. How CRTSCTS is accommodates into c_cflag variable?
> Please let me know, if my interpretation is wrong.
> 
> Thanks in advance.

Hint: constants in C may be expressed in base 16, 10, or 8.

milton

(No subject header)

[Milton Miller]

On Tue, 30 Nov 2010 about 20:01:29 -0000, Oleg Nesterov wrote:
> Teach get_arg_ptr() to handle compat = T case correctly.

>  #include <asm/uaccess.h>
>  #include <asm/mmu_context.h>
> @@ -395,6 +396,18 @@ get_arg_ptr(const char __user * const __
>  {
>  	const char __user *ptr;
>  
> +#ifdef CONFIG_COMPAT
> +	if (unlikely(compat)) {

This should not be marked unlikely.  Unlikely tells gcc the path
with over 99% confidence and disables branch predictors on some
architectures.  If called from a compat processes this will result
in a mispredicted branch every iteration.  Just use if (compat)
and let the hardware branch predictors do their job.

> +		compat_uptr_t __user *a = (void __user*)argv;
> +		compat_uptr_t p;
> +
> +		if (get_user(p, a + argc))
> +			return ERR_PTR(-EFAULT);
> +
> +		return compat_ptr(p);
> +	}
> +#endif
> +
>  	if (get_user(ptr, argv + argc))
>  		return ERR_PTR(-EFAULT);
>  
> @@ -1501,6 +1514,18 @@ int do_execve(const char *filename,
>  	return do_execve_common(filename, argv, envp, regs, false);
>  }
>  
> +#ifdef CONFIG_COMPAT
> +int compat_do_execve(char * filename,
> +	compat_uptr_t __user *argv,
> +	compat_uptr_t __user *envp,
> +	struct pt_regs * regs)
> +{
> +	return do_execve_common(filename,
> +				(void __user*)argv, (void __user*)envp,

Shouldn't these be compat_ptr(argv)?  (makes a difference on s390)

> +				regs, true);
> +}
> +#endif
> +
>  void set_binfmt(struct linux_binfmt *new)
>  {
>  	struct mm_struct *mm = current->mm;

Thanks,
milton

(No subject header)

[Milton Miller]

On Tue, 30 Nov 2010 about 20:01:29 -0000, Oleg Nesterov wrote:
> Teach get_arg_ptr() to handle compat = T case correctly.

>  #include <asm/uaccess.h>
>  #include <asm/mmu_context.h>
> @@ -395,6 +396,18 @@ get_arg_ptr(const char __user * const __
>  {
>  	const char __user *ptr;
>  
> +#ifdef CONFIG_COMPAT
> +	if (unlikely(compat)) {

This should not be marked unlikely.  Unlikely tells gcc the path
with over 99% confidence and disables branch predictors on some
architectures.  If called from a compat processes this will result
in a mispredicted branch every iteration.  Just use if (compat)
and let the hardware branch predictors do their job.

> +		compat_uptr_t __user *a = (void __user*)argv;
> +		compat_uptr_t p;
> +
> +		if (get_user(p, a + argc))
> +			return ERR_PTR(-EFAULT);
> +
> +		return compat_ptr(p);
> +	}
> +#endif
> +
>  	if (get_user(ptr, argv + argc))
>  		return ERR_PTR(-EFAULT);
>  
> @@ -1501,6 +1514,18 @@ int do_execve(const char *filename,
>  	return do_execve_common(filename, argv, envp, regs, false);
>  }
>  
> +#ifdef CONFIG_COMPAT
> +int compat_do_execve(char * filename,
> +	compat_uptr_t __user *argv,
> +	compat_uptr_t __user *envp,
> +	struct pt_regs * regs)
> +{
> +	return do_execve_common(filename,
> +				(void __user*)argv, (void __user*)envp,

Shouldn't these be compat_ptr(argv)?  (makes a difference on s390)

> +				regs, true);
> +}
> +#endif
> +
>  void set_binfmt(struct linux_binfmt *new)
>  {
>  	struct mm_struct *mm = current->mm;

Thanks,
milton

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom policy in Canada: sign http://dissolvethecrtc.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: (No subject header)

[Oleg Nesterov]

On 12/01, Milton Miller wrote:
>
> On Tue, 30 Nov 2010 about 20:01:29 -0000, Oleg Nesterov wrote:
> > Teach get_arg_ptr() to handle compat = T case correctly.
>
> >  #include <asm/uaccess.h>
> >  #include <asm/mmu_context.h>
> > @@ -395,6 +396,18 @@ get_arg_ptr(const char __user * const __
> >  {
> >  	const char __user *ptr;
> >
> > +#ifdef CONFIG_COMPAT
> > +	if (unlikely(compat)) {
>
> This should not be marked unlikely.  Unlikely tells gcc the path
> with over 99% confidence and disables branch predictors on some
> architectures.  If called from a compat processes this will result
> in a mispredicted branch every iteration.  Just use if (compat)
> and let the hardware branch predictors do their job.

This applies to almost every likely/unlikely, and I think that compat
processes should fall into "unlikely category". But I don't really mind,
I can remove this hint, I added it mostly as documentation.

> > +#ifdef CONFIG_COMPAT
> > +int compat_do_execve(char * filename,
> > +	compat_uptr_t __user *argv,
> > +	compat_uptr_t __user *envp,
> > +	struct pt_regs * regs)
> > +{
> > +	return do_execve_common(filename,
> > +				(void __user*)argv, (void __user*)envp,
>
> Shouldn't these be compat_ptr(argv)?  (makes a difference on s390)

I'll recheck, but I don't think so. Please note that compat_ptr()
accepts "compat_uptr_t", not "compat_uptr_t *".

argv should be correct as a pointer to user-space, otherwise the
current code is buggy. For example, compat_do_execve() passes
argv to compat_count() which does get_user(argv) without any
conversion.

IOW, even if this should be fixed, I think this have nothing to
do with this patch. But I'll recheck, thanks.

Oleg.

Re: (No subject header)

[Oleg Nesterov]

On 12/01, Milton Miller wrote:
>
> On Tue, 30 Nov 2010 about 20:01:29 -0000, Oleg Nesterov wrote:
> > Teach get_arg_ptr() to handle compat = T case correctly.
>
> >  #include <asm/uaccess.h>
> >  #include <asm/mmu_context.h>
> > @@ -395,6 +396,18 @@ get_arg_ptr(const char __user * const __
> >  {
> >  	const char __user *ptr;
> >
> > +#ifdef CONFIG_COMPAT
> > +	if (unlikely(compat)) {
>
> This should not be marked unlikely.  Unlikely tells gcc the path
> with over 99% confidence and disables branch predictors on some
> architectures.  If called from a compat processes this will result
> in a mispredicted branch every iteration.  Just use if (compat)
> and let the hardware branch predictors do their job.

This applies to almost every likely/unlikely, and I think that compat
processes should fall into "unlikely category". But I don't really mind,
I can remove this hint, I added it mostly as documentation.

> > +#ifdef CONFIG_COMPAT
> > +int compat_do_execve(char * filename,
> > +	compat_uptr_t __user *argv,
> > +	compat_uptr_t __user *envp,
> > +	struct pt_regs * regs)
> > +{
> > +	return do_execve_common(filename,
> > +				(void __user*)argv, (void __user*)envp,
>
> Shouldn't these be compat_ptr(argv)?  (makes a difference on s390)

I'll recheck, but I don't think so. Please note that compat_ptr()
accepts "compat_uptr_t", not "compat_uptr_t *".

argv should be correct as a pointer to user-space, otherwise the
current code is buggy. For example, compat_do_execve() passes
argv to compat_count() which does get_user(argv) without any
conversion.

IOW, even if this should be fixed, I think this have nothing to
do with this patch. But I'll recheck, thanks.

Oleg.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom policy in Canada: sign http://dissolvethecrtc.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

(No subject header)

[gina]

You have just won £1,000,000GBP.Please Contact your Claims
Personnel with your email only to. nellydave1@gmail.com .for
info
......................................................................
NOTE : If You Recieve This Message In Your
Junk Or Spam Its Due To Your Internet
Provider.