On Sun, Jun 06, 2010 at 11:34:44AM +0300, Jordan Gordeev wrote:
>> I would disagree that that makes it a necessary part. You could use
>> something other than TCP - if gdb supports serial lines, for example,
>> you could use a pty; even if gdb doesn't support anything but TCP out
>> of the box, yo
Most of what I'm writing here has already been brought up elsewhere in
the thread; I'm collecting it here as a response to the specific
questions jgordeev asked. Those who've read the rest of the thread
will probably find nothing new here.
>> My opinion, which is probably worth approximately what
>> While of course nothing is perfect, I think the number of cases
>> where you want the routability of IP but have nothing on the local
>> broadcast domain that can proxy is small enough that the cost of
>> writing them off outweighs the cost of dealing with the issues that
>> using IP raises.
> P
On Jun 6, 2010, at 11:51 33AM, der Mouse wrote:
> IPKDB used [...]. [...] easy to support a single IPsec ESP [...]
[...]
>>> [...]
>> I must say, though, that the more I think about it, the more I'm
>> concerned about replay attacks. You suggested that ESP replay
>> prevention be disab
IPKDB used [...]. [...] easy to support a single IPsec ESP [...]
>>> [...]
>> [...]
> I must say, though, that the more I think about it, the more I'm
> concerned about replay attacks. You suggested that ESP replay
> prevention be disabled, and that is in fact consistent with the ESP
> specs
On Jun 6, 2010, at 9:54 01AM, Thor Lancelot Simon wrote:
> On Sun, Jun 06, 2010 at 12:02:18PM +0300, Jordan Gordeev wrote:
>> Thor Lancelot Simon wrote:
>>> IPKDB used a custom MD5-based packet hash for "security". I actually
>>> think it would probably be very easy to support a single IPsec ESP
Hello. I'd say use tcp. Gdb already supports it, so half the work is
done. More than that, if, in fact, you can use a small tcp implementation
inside the debugged kernel.
On Jun 5, 6:28pm, Jordan Gordeev wrote:
} Subject: remote kernel debugging over a network
} Hello, kernel ha
On Sun, Jun 06, 2010 at 12:02:18PM +0300, Jordan Gordeev wrote:
> Thor Lancelot Simon wrote:
>> IPKDB used a custom MD5-based packet hash for "security". I actually
>> think it would probably be very easy to support a single IPsec ESP
>> security association instead. The hair with IPsec is all wi
On Jun 6, 2010, at 5:02 18AM, Jordan Gordeev wrote:
> Thor Lancelot Simon wrote:
>> IPKDB used a custom MD5-based packet hash for "security". I actually
>> think it would probably be very easy to support a single IPsec ESP
>> security association instead. The hair with IPsec is all with key
>>
Thor Lancelot Simon wrote:
IPKDB used a custom MD5-based packet hash for "security". I actually
think it would probably be very easy to support a single IPsec ESP
security association instead. The hair with IPsec is all with key
negotiation. Don't bother, and don't do some things like replay
p
der Mouse wrote:
My question is: Should I go with a custom protocol (+ a daemon that
proxies to TCP), or should I go with TCP directly?
My opinion, which is probably worth approximately what you paid for it:
custom protocol built directly atop Ethernet (ie, not IP-based).
You are conce
On Sun, Jun 06, 2010 at 12:47:36AM +0200, Joerg Sonnenberger wrote:
> On Sat, Jun 05, 2010 at 05:57:55PM -0400, Thor Lancelot Simon wrote:
> > IPKDB used a custom MD5-based packet hash for "security". I actually
> > think it would probably be very easy to support a single IPsec ESP
> > security as
On Sat, Jun 05, 2010 at 05:57:55PM -0400, Thor Lancelot Simon wrote:
> IPKDB used a custom MD5-based packet hash for "security". I actually
> think it would probably be very easy to support a single IPsec ESP
> security association instead. The hair with IPsec is all with key
> negotiation. Don'
On Sat, Jun 05, 2010 at 01:33:04PM -0700, Bakul Shah wrote:
> > custom protocol built directly atop Ethernet (ie, not IP-based).
>
> At a previous company (about 13 years back) this is what we
> did. The details are hazy now but we didn't change the gdb
> remote protocol; we just emulated a seria
On Sat, 05 Jun 2010 16:01:01 EDT der Mouse wrote:
> > I have to make a decision about the protocol that will be used for
> > remote kernel debugging.
>
> > My question is: Should I go with a custom protocol (+ a daemon that
> > proxies to TCP), or should I go with TCP directly?
>
> My opinion,
>> My opinion, which is probably worth approximately what you paid for
>> it: custom protocol built directly atop Ethernet (ie, not IP-based).
>> It seems to me that, for this application, the downsides of TCP
>> outweigh the upsides.
> It seems to me that something over IP nonetheless would be h
On Sat, Jun 05, 2010 at 04:01:01PM -0400, der Mouse wrote:
> > I have to make a decision about the protocol that will be used for
> > remote kernel debugging.
>
> > My question is: Should I go with a custom protocol (+ a daemon that
> > proxies to TCP), or should I go with TCP directly?
>
> My op
> I have to make a decision about the protocol that will be used for
> remote kernel debugging.
> My question is: Should I go with a custom protocol (+ a daemon that
> proxies to TCP), or should I go with TCP directly?
My opinion, which is probably worth approximately what you paid for it:
custom
Hello, kernel hackers!
I am the student doing the "Remote kernel debugging over Ethernet"
Google Summer of Code project.
I have to make a decision about the protocol that will be used for
remote kernel debugging.
The environment for running any protocol, when the kernel is stopped for
inspect
19 matches
Mail list logo
