Re: PPTP

On Sep 27, 6:54 am, Rob Kendrick <n...@xxxxxxxx> wrote:
On Wed, 26 Sep 2007 07:01:35 -0700, Alan Williams wrote:
On Sep 26, 3:02 am, Rob Kendrick <n...@xxxxxxxx> wrote:
On Tue, 25 Sep 2007 04:32:28 -0700, Mike Carter wrote:
Does RISC OS support the Point-to-Point Tunneling Protocol yet?

Not to my knowledge. It's a pretty nasty Cisco/Microsoft hybrid VPN
protocol, for which there are numerous better alternatives that might be
worth you investigating.

But I doubt any of them will be available to RISC OS users, either.

B.

This does in fact raise some interesting questions about where in the
RISC OS network driver stack a VPN driver would actually fit.

Presumably it would have to provide a DCI4 device say pptp0, while
actually sitting on top of IP sockets at the same time. Effectively
connecting together the top and bottom of the IP stack.

Yes, I've been considering this problem. I have half of a "TUN/TAP" DCI4
driver to allow user land processes to inject and receive packets from the
IP stack written, which I started as both an effort to port OpenVPN as
well as a learning curve to eventually add networking support to ArcEm.
At some point, I'll find the time to finish it.

B.- Hide quoted text -

- Show quoted text -


Interesting.

I actually found another solutions by accident. If you run Virtual
RPC its TCPIP view is really the same as the windows host, so if you
have the VPN up in windows the RISC OS VM will see the machines at the
other end too.

I have some source to a DCI4 .1q vlan encapsulation layer some where,
this is not quite the same thing, though some bit may be
canibalisable. This is a RM with both DCI4 driver and protocol stack
semantics, as it sits on a driver and presents multiple virtual
devices to the protocol stacks above, tagging and untagging packet as
they pass up and down. I think it worked, can't say how stable it was
though. I haven't the need or the time to waste ;-) any more.

Alan

.

Relevant Pages

  • Re: [PATCH 0/3] New firewire stack
    ... My main point about ohci1394 (the old stacks PCI driver) is, ... The big problems in the ohci1394 drivers is the irq_handler, bus reset ... reset, so there is no need to complicate the core stack with this extra state, ... interfaces have slightly disjoint feature sets and can't really be phased out. ...
    (Linux-Kernel)
  • Re: [PATCH 0/3] New firewire stack
    ... My main point about ohci1394 (the old stacks PCI driver) is, ... The big problems in the ohci1394 drivers is the irq_handler, bus reset ... reset, so there is no need to complicate the core stack with this extra state, ... interfaces have slightly disjoint feature sets and can't really be phased out. ...
    (Linux-Kernel)
  • [crash] BUG: unable to handle kernel NULL pointer dereference at (null), last sysfs file: /sys/devic
    ... Stack: ... Call Trace: ... # SCSI device support ... # You can enable one or both FireWire driver stacks. ...
    (Linux-Kernel)
  • Re: Driver getting Page Fault 0Eh Fault=0000, only when 2 PCI cards present in system
    ... There certainly are stack limits that a poorly designed function can exceed, ... > Is there a size issue on the size of a subroutine in a driver? ... With only one of our PCI cards ... >> area in Memory Space and also uses 1 PCI interrupt. ...
    (microsoft.public.development.device.drivers)
  • Re: how to test RAM?
    ... Driver Verifier. ... REPEAT THE LAST TABLE O N L Y) or match the fault address to the driver. ... Memory corruption, other hardware ... A kernel stack overflow. ...
    (microsoft.public.windowsxp.general)