Hi Harald,
On 03/15/2017 05:39 PM, Harald Welte wrote:
Hi Jonas,
are you working on the review feedback that was provided back in early
February? I think there were some comments like
* remove unrelated cosmetic change in comment
* change from FLAGS to a dedicated MODE netlink attribute
* add
Hi Harald,
On Wed, Mar 15, 2017 at 08:10:38PM +0100, Harald Welte wrote:
> I've modified the patch slightly, see below (compile-tested, but not
> otherwise tested yet). Basically rename the flags attribute to 'role',
> expand the commit log and removed unrelated cosmetic changes.
>
> I've also
On Wed, Mar 15, 2017 at 08:10:38PM +0100, Harald Welte wrote:
> I've modified the patch slightly, see below (compile-tested, but not
> otherwise tested yet). Basically rename the flags attribute to 'role',
> expand the commit log and removed unrelated cosmetic changes.
I also have a version
Hi Pablo,
On Wed, Mar 15, 2017 at 06:23:48PM +0100, Pablo Neira Ayuso wrote:
> On Wed, Mar 15, 2017 at 05:39:16PM +0100, Harald Welte wrote:
> >
> > I would definitely like to see this move forward, particularly in order
> > to test the GGSN-side code.
>
> Agreed.
I've modified the patch
On Wed, Mar 15, 2017 at 05:39:16PM +0100, Harald Welte wrote:
> Hi Jonas,
>
> are you working on the review feedback that was provided back in early
> February? I think there were some comments like
> * remove unrelated cosmetic change in comment
> * change from FLAGS to a dedicated MODE netlink
Hi Jonas,
are you working on the review feedback that was provided back in early
February? I think there were some comments like
* remove unrelated cosmetic change in comment
* change from FLAGS to a dedicated MODE netlink attribute
* add libgtpnl code and some usage information or even sample
Hi Andreas, Pablo, Jonas,
I think that the SGSN/GGSN role flag (or whatever it may end up being
called) logically belongs in the gtp-device at this point, and will in
the future belong to the UDP/GTP-socket (with Andreas' proposed
changes). Having it per-pdp-context indeed seems odd and just
Hi,
- On Feb 13, 2017, at 12:16 PM, pablo pa...@netfilter.org wrote:
> On Mon, Feb 13, 2017 at 10:25:19AM +0100, Andreas Schultz wrote:
>> Hi,
>>
>> I'm a bit late to comment, but maybe you can consider an additional
>> change for v2...
>>
>> - On Feb 3, 2017, at 10:12 AM, Jonas Bonn
On Mon, Feb 13, 2017 at 10:25:19AM +0100, Andreas Schultz wrote:
> Hi,
>
> I'm a bit late to comment, but maybe you can consider an additional
> change for v2...
>
> - On Feb 3, 2017, at 10:12 AM, Jonas Bonn jo...@southpole.se wrote:
>
> > The GTP-tunnel driver is explicitly GGSN-side as it
Hi,
I'm a bit late to comment, but maybe you can consider an additional
change for v2...
- On Feb 3, 2017, at 10:12 AM, Jonas Bonn jo...@southpole.se wrote:
> The GTP-tunnel driver is explicitly GGSN-side as it searches for PDP
> contexts based on the incoming packets _destination_ address.
On Mon, Feb 06, 2017 at 03:16:22PM +0100, Harald Welte wrote:
> Hi Jonas,
>
> On Mon, Feb 06, 2017 at 02:33:07PM +0100, Jonas Bonn wrote:
> > Fair enough. The use-case I am looking at involves PGW load-testing where
> > the simulated load is generated locally on the SGSN so it _is_ seeing IP
> >
Hi Jonas,
On Mon, Feb 06, 2017 at 02:33:07PM +0100, Jonas Bonn wrote:
> Hi Pablo,
>
> On 02/06/2017 12:08 PM, Pablo Neira Ayuso wrote:
> >Hi Jonas,
> >
> >On Fri, Feb 03, 2017 at 10:12:31AM +0100, Jonas Bonn wrote:
> >>The GTP-tunnel driver is explicitly GGSN-side as it searches for PDP
>
Hi Jonas,
Sorry, for later reply, I'm currently on vacation with almost no
internet access.
- On Feb 6, 2017, at 2:33 PM, Jonas Bonn jo...@southpole.se wrote:
> Hi Pablo,
>
> On 02/06/2017 12:08 PM, Pablo Neira Ayuso wrote:
>> Hi Jonas,
>>
>> On Fri, Feb 03, 2017 at 10:12:31AM +0100, Jonas
- On Feb 6, 2017, at 12:08 PM, pablo pa...@netfilter.org wrote:
> Hi Jonas,
>
> On Fri, Feb 03, 2017 at 10:12:31AM +0100, Jonas Bonn wrote:
>> The GTP-tunnel driver is explicitly GGSN-side as it searches for PDP
>> contexts based on the incoming packets _destination_ address. If we
>> want
Hi Jonas,
On Mon, Feb 06, 2017 at 02:33:07PM +0100, Jonas Bonn wrote:
> Fair enough. The use-case I am looking at involves PGW load-testing where
> the simulated load is generated locally on the SGSN so it _is_ seeing IP
> packets and the SNDCP is left out altogether.
Ok, it would have been
Dear Jonas,
On Fri, Feb 03, 2017 at 10:12:31AM +0100, Jonas Bonn wrote:
> The GTP-tunnel driver is explicitly GGSN-side as it searches for PDP
> contexts based on the incoming packets _destination_ address. If we
> want to write an SGSN, then we want to be idenityfing PDP contexts
> based on
Hi Pablo,
On 02/06/2017 12:08 PM, Pablo Neira Ayuso wrote:
Hi Jonas,
On Fri, Feb 03, 2017 at 10:12:31AM +0100, Jonas Bonn wrote:
The GTP-tunnel driver is explicitly GGSN-side as it searches for PDP
contexts based on the incoming packets _destination_ address. If we
want to write an SGSN,
Hi Jonas,
On Fri, Feb 03, 2017 at 10:12:31AM +0100, Jonas Bonn wrote:
> The GTP-tunnel driver is explicitly GGSN-side as it searches for PDP
> contexts based on the incoming packets _destination_ address. If we
> want to write an SGSN, then we want to be idenityfing PDP contexts
> based on
18 matches
Mail list logo
