Mailing List Archive

On Sat, Jul 28, 2001 at 06:41:15PM +0200, Martin Josefsson wrote:
> Hi.
>
> Now I've updated the SAME target a bit.
> The only real improvment is the new '--nodst' option which makes SAME only
> use the real sourceaddress of the client when calculating the new
> NAT'd sourceaddress. When this option isn't specified SAME uses both
> source and destination addresses in the calculation. So if you _always_
> want clients to have the same sourceaddress after NAT regardless of which
> destination they make connections to, you'll want this option.

Ok, I can imagine that certain applications / scenarios require this
behaviour.

> Core-team, please apply these patches.

I will have a look at them as soon as possible, and include if I approve them.
The feature itself sounds interesting, as stated above.

> (copied via a flaky floppy to a win98 machine and then ftp'd to a
> server and mailed so I hope they still work :)

mmh... some people do weird things.

>
> /Martin

--
Live long and prosper
- Harald Welte / laforge@gnumonks.org http://www.gnumonks.org
============================================================================
GCS/E/IT d- s-: a-- C+++ UL++++$ P+++ L++++$ E--- W- N++ o? K- w--- O- M-
V-- PS+ PE-- Y+ PGP++ t++ 5-- !X !R tv-- b+++ DI? !D G+ e* h+ r% y+(*)

On Sat, Jul 28, 2001 at 06:41:15PM +0200, Martin Josefsson wrote:
> Core-team, please apply these patches.

now applied.

> /Martin


--
Live long and prosper
- Harald Welte / laforge@gnumonks.org http://www.gnumonks.org
============================================================================
GCS/E/IT d- s-: a-- C+++ UL++++$ P+++ L++++$ E--- W- N++ o? K- w--- O- M-
V-- PS+ PE-- Y+ PGP++ t++ 5-- !X !R tv-- b+++ DI? !D G+ e* h+ r% y+(*)

On Sat, 28 Jul 2001, Harald Welte wrote:

> On Sat, Jul 28, 2001 at 06:41:15PM +0200, Martin Josefsson wrote:
> > Core-team, please apply these patches.
>
> now applied.

Thanks.

I think I'll take a little look at how to support multiple ranges
tomorrow. The main problem I noticed today when rewriting parts of my
target is this:

struct ipt_same_info
{
unsigned char info;

unsigned int rangesize;

/* hangs off end. */
struct ip_nat_range range[1];
};

range has a static size... I don't even want to try to imagine how to
solve it with a dynamic size...

My thought was to define the maximum number of ranges in ipt_SAME.h like
this:

#define IPT_SAME_MAX_RANGES 10

struct ipt_same_info
{
unsigned char info;

unsigned int rangesize;

/* hangs off end. */
struct ip_nat_range range[IPT_SAME_MAX_RANGES];
};

And then use IPT_SAME_MAX_RANGES when cheking rangesize for sanity and so
on. Does this sound like a good idea? Need some input on this before I
start digging that hole...

/Martin

PS. If I succeed I'll implement it in BALANCE too as it's very similar to
SAME (SAME is a modified BALANCE)

Martin, ;-)

If I read the code correctly, and if I fully understand how pointers
work, then a declaration of a zero-element array is like declaring a pointer
and then running memset() on it (IIRC). AFAIK, this cleans out the pointer
and prevents corruption, which is a Big Thing in kernel-space, IMHO.
Dynamic memory? Ouch. I suppose you would need that to grow the
ip_nat_multi_range
to support multiples ranges, right? Well, I know exactly zlich about how
pointers and
stack variables survive over a netlink socket to kernel-space. Try
sending an e-mail
to the core team and ask them about it.

Brad

Martin Josefsson wrote:

> On Sat, 28 Jul 2001, Brad Chapman wrote:
>
>> Mr. Josefsson,
>>
>> IIRC, the `struct ipt_entry' uses a zeroed char *, like this:
>>
>> char elems[0];
>>
>> AFAIK, this is used to stack the match and target structs inside a rule
>> entry. Have you tried this, sir?
>
>
> Brad, please drop the polite Mr. and sir stuff, I'm simply not used to it
> :)
>
> No I havn't looked at this... My programming skills is not enough to
> understand how this works. I would think that char elems[0] is the same as
> char elems[] (or char *elems if you prefer that)
>
> And I fail to understand how this would help me send a struct with a
> pointer to some dynamic memory to kernelspace from inside libipt_SAME.c
>
> Well well, I'll try my approach and see how it goes.
>
> /Martin
>
>
>