On Sun, Jan 06, 2002 at 07:21:31PM +0100, Neal H Walfield wrote:
> > However, the main point is: ping works, some basic stuff works, and it
> > should be possible to debug the remaining problems without too much hassles.
> > The main candidates for the problems are um-pppd (in particular the tty
d. In fact, the only change
in that file is to allow it to compile under GNU/Linux. So, if it is
broken under the Hurd, it will likely have also been broken under BSD.
> Neal and me tested ppp over ethernet
> (_not_ what you know as PPPoE), and it worked
On Fri, Jan 04, 2002 at 06:47:02PM -0500, Roland McGrath wrote:
> > I set the speed of the serial line to 19200 by this:
> > stty speed 19200 < /dev/com0
>
> Why do you have to? Doesn't ppp set this speed itself?
I don't think so, but I have not verified it. I
> I set the speed of the serial line to 19200 by this:
> stty speed 19200 < /dev/com0
Why do you have to? Doesn't ppp set this speed itself?
> I set up pfinet (after killing it with kill -9):
> settrans /servers/socket/2 /hurd/pfinet -i tun0
Does settrans -gf not work?
Hi,
I have set up ppp according to Neal's instructions, over a serial direct
link between two computers (speed 19200 to avoid gnumach errors), one
running GNU/Linux and one running GNU/Hurd (you should be able to do this on
a single box with two serial ports and two instances of um-pppd as
On Thu, Jan 03, 2002 at 10:33:33AM +0100, Diego Roversi wrote:
> On Wed, Jan 02, 2002 at 10:58:18PM +0100, Marcus Brinkmann wrote:
>
> > Hi,
> >
> > we are having a problem with the serial device driver. Neal and I think we
> > tracked it down to the interrupt handling.
> >
>
> Some month ago
On Wed, Jan 02, 2002 at 10:58:18PM +0100, Marcus Brinkmann wrote:
> Hi,
>
> we are having a problem with the serial device driver. Neal and I think we
> tracked it down to the interrupt handling.
>
Some month ago, I'd also a problem with the serial line, and I post some
patch for gnumach. Som
On Thu, Jan 03, 2002 at 02:26:27AM +0100, Jeroen Dekkers wrote:
> Hmm strange as remote debugging works fine.
It's not strange ata ll, as with remote debugging the kernel opens the
device and never closes it, while in our case you open the device,
read/write, and then close it.
> Can you tell me
It is easy to reproduce the fact that oskit-mach has no serial device drivers.
The console doesn't count.
___
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
On Thu, Jan 03, 2002 at 02:09:43AM +0100, Neal H Walfield wrote:
> > Did you try this with gnumach, OSKit-Mach or both?
> >
> > In your mail you talk about i386/i386at/com.c, which isn't in my
> > OSKit-Mach tree. I suggest you try out OSKit-Mach because remote
> > debugging works AFAIK (I haven'
> Did you try this with gnumach, OSKit-Mach or both?
>
> In your mail you talk about i386/i386at/com.c, which isn't in my
> OSKit-Mach tree. I suggest you try out OSKit-Mach because remote
> debugging works AFAIK (I haven't tried yet) and that uses the serial
> port.
Been there, done that and it
lem is mostly the baud rate that we
selected: we got much nicer results once we stopped using 300 bps and
tried something a bit more perky, e.g. 2400 bps.
Anyway, we have a new analysis: the code works perfectly when
tunneling ppp over tcp/ip, however, as soon as we try using the serial
port, we st
On Wed, Jan 02, 2002 at 10:58:18PM +0100, Marcus Brinkmann wrote:
> Hi,
>
> we are having a problem with the serial device driver. Neal and I think we
> tracked it down to the interrupt handling.
Did you try this with gnumach, OSKit-Mach or both?
In your mail you talk about i386/i386at/com.c,
> Make sure that RTIi is checking how many bytes to remove from the
> buffer, and isn't just assuming the amount to remove. Also make sure
Ok, this was a bogus suggestion. I should read the actual code before I
start conjectures. :)
All the serial drivers I can find pull out bytes as long as "d
> The CTIi interrupt you are seeing is a timeout interrupt. This is used
> to cover the case where anough bytes aren't recieved to trigger the high
> water interrupt. The serial hardware issues these at a regular interval
> to keep the buffer clear.
Actually, the interrupt is issued if the time
> So, sending "0123456789ABCDEF" will result in
> RECi => 0123456789ABCD
> CTIi => EF
[snip]
> Anybody has an idea how to proceed with this problem? Has anybody gotten
> serial line communication to work reliably? BTW, we have tested PPP and the
> tunn
idea how to proceed with this problem? Has anybody gotten
serial line communication to work reliably? BTW, we have tested PPP and the
tunnel device without using the serial connection (Neal set it up to send
the packets over ethernet), and it works just fine. So, after fixing the
com device, we wil
iated.
> do you think ppp under the hurd is strong enough at this point for me
> to get to work on pppoe right away, or should i put my energies into
> improving that first?
As far as I can tell, there are no big problems with the ppp proper.
Rather, I think that there is a bug in the im
>> 1. Has anybody thought about partial delegation of networking? Does
>>that make sense at all?
>
> I have some vague ideas. I think it does make sense, but making it
> work seems hard. But if someone prods me, then I can describe my
> vague ideas.
Prod, prod.
>> 3. Is there a reasonable
t; permission on some other nodes as well, to make sure that pfinet gets
> access to ethernet hardware and stuff. And then one should probably
> think a little about what a "privileged (< 1024) port means when
> pfinet doesn't run as root. This seems a little harier than
[EMAIL PROTECTED] (Niels Möller) writes:
> 1. Has anybody thought about partial delegation of networking? Does
>that make sense at all?
I have some vague ideas. I think it does make sense, but making it
work seems hard. But if someone prods me, then I can describe my
vague ideas.
> 3. Is
philippe brochard <[EMAIL PROTECTED]> writes:
> but I think it's a good thing if we can run it with an unprivileged user.
I'm not sure if there's any sensible way to delegate control over just
some parts of the networking (e.g different network interfaces), but
until someone comes up with a good
ure what
else select might more usefully do instead. But it only arises at all
because of term's intransigence.
I'm checking in a change to term. In the meantime, it should be reasonably
safe as a workaround to just pass NULL in place of &efds to select in ppp.
_
Hello all, I fixed the very simple problem with the lock file creating thanks to
Marcus ;) and of course Roland. Now I got whole new problem (yay!), here's the log:
May 26 08:34:44 localhost ppp[736]: Phase: Using interface: tun0
May 26 08:34:44 localhost ppp[736]: Phase: deflink: Creat
Figure out what lock file name it is actually trying to use.
It is probably trying to use a file name in a nonexistent directory.
___
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
I disabled the gateway setting code in PPP in hopes of getting it to dial in and
this is what I got (from /var/log/syslog):
y 6 00:39:51 localhost ppp[7087]: Phase: Using interface: tun0
May 6 00:39:51 localhost ppp[7087]: Phase: deflink: Created in closed state
May 6 00:39:51 localhost ppp
On Mon, Apr 23, 2001 at 02:22:55PM -0500, Daniel E Baumann wrote:
> Hello all. I have been playing with PPP some more, but I am not very successfuly as
> it seems pfinet just does not like me :P. It is basically doing the same thing as
> bafore failing to set the gateway address initi
Hello all. I have been playing with PPP some more, but I am not very successfuly as
it seems pfinet just does not like me :P. It is basically doing the same thing as
bafore failing to set the gateway address initially then after several invocations
it will hang and not spit errors at me. So I
On Tue, Mar 06, 2001 at 01:27:13PM -0600, Daniel E Baumann wrote:
> Can I
> justs rebuild the deb with debuggin symbols for now? How do I do that? (Yes I
> should learn how to make a deb ;) ).
Get the Debian source files (should be in ftp://ftp.debian.org/pool/h/hurd
or so). Just get the tar.gz f
On Mon, Mar 05, 2001 at 04:40:48AM +0100, Marcus Brinkmann wrote:
> On Sun, Mar 04, 2001 at 08:00:37PM -0600, Daniel E Baumann wrote:
> > Well if I try to set it with fsysopts the first time it will tell me:
> >
> > ./fsysopts: /servers/socket/2: Network is unreachable (something like that)
> >
On Sun, Mar 04, 2001 at 09:42:50PM -0500, Roland McGrath wrote:
> It sounds like it is pfinet you need to debug, not anything on the client end.
> There might be a hurd package with debugging symbols, Marcus can tell you
> (hurd-dbg I'd guess?), or you could just compile hurd yourself.
We really
On Sun, Mar 04, 2001 at 08:00:37PM -0600, Daniel E Baumann wrote:
> Well if I try to set it with fsysopts the first time it will tell me:
>
> ./fsysopts: /servers/socket/2: Network is unreachable (something like that)
>
> if I do it again it just hangs there and any subsequent invocations it wil
So, if you can reduce the whole thing to a series of fsysopts commands
(equivalent to what ppp does, but without running ppp) that produces
problematic results from pfinet, then it will be much easier for someone
else to try to debug it.
___
Bug-hurd
ts -R /servers/socket/2 --gateway=10.0.0.2'.
>
> Also if I invoke ppp a number of times it will finally seem to work, but it
> will just be hung there, no dialing in :(. Seems that I get some very erratic
> behavior. Are there debug versions of the libs that I can grab (preferably
On Sun, Mar 04, 2001 at 07:20:42PM -0600, Daniel E Baumann wrote:
> On Sun, Mar 04, 2001 at 04:55:02PM -0500, Roland McGrath wrote:
> > > Woops. Here is the message from the error () call:
> > >
> > > ./ppp: /servers/socket/2: --gateway=10.0.0.2: (ipc/mig) server
On Sun, Mar 04, 2001 at 04:55:02PM -0500, Roland McGrath wrote:
> > Woops. Here is the message from the error () call:
> >
> > ./ppp: /servers/socket/2: --gateway=10.0.0.2: (ipc/mig) server died
>
> Ah. That would seem to indicate that pfinet died. Please try doin
> Woops. Here is the message from the error () call:
>
> ./ppp: /servers/socket/2: --gateway=10.0.0.2: (ipc/mig) server died
Ah. That would seem to indicate that pfinet died. Please try doing the
same sequence of fsys_set_options calls by hand using fsysopts on
/servers/socket/2 a
On Sat, Mar 03, 2001 at 06:39:51PM -0500, Roland McGrath wrote:
> You have to show us the full error message from stderr, the
> one that includes the errno code.
Woops. Here is the message from the error () call:
./ppp: /servers/socket/2: --gateway=10.0.0.2: (ipc/mig) server die
You have to show us the full error message from stderr, the
one that includes the errno code.
___
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
O.K., I have been debuggin this thing here. For sdome reason though when I
try to set the gateway programatically it doesn't like it and my error
message is displayed, as shown here in this snippet:
int result = 1;
error_t err;
/* The file we use as a handle to
On Fri, Jan 12, 2001 at 11:31:28AM -0600, Daniel E Baumann wrote:
> Upon popular request, to make the code avaiable, I have imported the user
> space PPP port ino the HURD SourceForge CVS tree.
Great Daniel, thanks a lot!
> This
> code will not be tested or debugged until there is
Upon popular request, to make the code avaiable, I have imported the user
space PPP port ino the HURD SourceForge CVS tree. You can check it out by
doing the following:
Anonymous CVS Access
cvs -d:pserver:[EMAIL PROTECTED]:/cvsroot/hurd login
cvs -z3 -d:pserver:[EMAIL PROTECTED]:/cvsroot
On Wednesday 06 December 2000 15:53, Roland McGrath wrote:
> > Anyone know what the HURD equivalent would be to FreeBSD's
> > setproctitle()? I assume it would be a call in libps. Is there a glibc
> > equivalent function or way to do this? Please enlighten me. Maybe I'll
> > look in the glibc manu
> Anyone know what the HURD equivalent would be to FreeBSD's setproctitle()? I
> assume it would be a call in libps. Is there a glibc equivalent function or
> way to do this? Please enlighten me. Maybe I'll look in the glibc manual
> and see if I can figure somehtin' out.
All setproctitle does
On Wed, Dec 06, 2000 at 10:10:42AM -0600, Daniel E Baumann wrote:
> Anyone know what the HURD equivalent would be to FreeBSD's setproctitle()? I
> assume it would be a call in libps. Is there a glibc equivalent function or
> way to do this? Please enlighten me. Maybe I'll look in the glibc manua
Anyone know what the HURD equivalent would be to FreeBSD's setproctitle()? I
assume it would be a call in libps. Is there a glibc equivalent function or
way to do this? Please enlighten me. Maybe I'll look in the glibc manual
and see if I can figure somehtin' out.
Dan
-
nd some primitive routing
interface. But of course if you think it is feasible to have the patches
incorporated at this stage of Hurd development even, that would be cool.
> Also, I hasve been using Debian for quite a while and would
> like to learn how to make a deb package. Do you th
On Saturday 02 December 2000 13:52, Marcus Brinkmann wrote:
> On Sat, Dec 02, 2000 at 12:31:27PM -0600, Daniel E Baumann wrote:
> > I have writen the function to create an iface startuct in PPP using
> > several SIOC* ioctl glibc calls. This is the first time I've used this so
On Sat, Dec 02, 2000 at 12:31:27PM -0600, Daniel E Baumann wrote:
> I have writen the function to create an iface startuct in PPP using several
> SIOC* ioctl glibc calls. This is the first time I've used this so I am
> posting it for inspection, comments and all that.
>
On Sat, Dec 02, 2000 at 12:31:27PM -0600, Daniel E Baumann wrote:
> I have writen the function to create an iface startuct in PPP using several
> SIOC* ioctl glibc calls. This is the first time I've used this so I am
> posting it for inspection, comments and all that. Also, is
I have writen the function to create an iface startuct in PPP using several
SIOC* ioctl glibc calls. This is the first time I've used this so I am
posting it for inspection, comments and all that. Also, is it ok to reuse the
same ifreq struct in the ioctl calls or should I declare one for
On Sat, Nov 25, 2000 at 04:31:31PM -0500, Igor Khavkine wrote:
> >
> > sprintf(node_name, "%s/%d", _SERVERS_SOCKET, PF_INET);
>
> Well, that's another segfault right there, you're trying to write
> to a wild pointer. Try:
> asprintf(&node_name, _SERVERS_SOCKET "%d", PF_INET);
> Actually you d
On Sat, Nov 25, 2000 at 01:50:37AM -0600, Daniel E Baumann wrote:
> Here is the code I wrote for setting the gateway in bundle.c, I welcome any
> comments. Some of this I borrowed from fsysopts.c.
>
I hope this is prototype code because there is a couple of obvious
blunders.
> int
> bundle_Set
Here is the code I wrote for setting the gateway in bundle.c, I welcome any
comments. Some of this I borrowed from fsysopts.c.
int
bundle_SetRoute(struct bundle *bundle, int cmd, struct in_addr dst,
struct in_addr gateway, struct in_addr mask, int bang,
int ssh)
On Fri, Nov 24, 2000 at 11:30:40AM -0600, Daniel E Baumann wrote:
> When I supply the node
> name is it safe to hard code "/servers/socket/2" as the node name?
As far as this hack goes, sure.
> I think I may add a check to
> ensure that it is a tunnel interface also.
Don't bother.
Marcus
-
Hi, I am currently hacking around the routing stuff in PPP by just allowing
you to do "add default HISADDR", which makes the peer at the other end the
gateway and no other routing entries can be made or removed (at least not
until there is sufficient support in libc0.2). I am attempt
On Wed, Nov 22, 2000 at 10:54:54AM +, Daniel E Baumann wrote:
> I am porting BSD PPP as most know (I hope that most of you guys know that).
> There is some code in there which uses the BSD routing implementation (which
> is dfiferent from Linux) to set routes. I know that pfinet
I am porting BSD PPP as most know (I hope that most of you guys know that).
There is some code in there which uses the BSD routing implementation (which
is dfiferent from Linux) to set routes. I know that pfinet does not support
this and all I do is set up the gateway of the tunnel interface. I
On Thu, Oct 05, 2000 at 04:44:00PM +0200, Marcus Brinkmann wrote:
> b. Porting ppp.
I have now prepared a ppp source tar file which is hacked to compile the lot
of the source files cleanly. This involved providing a few preprocessor
symbols (MAXHOSTNAMELEN, MAXPATHLEN, _BSD_VA_LIST_) and mess
On Thu, Oct 05, 2000 at 07:53:29PM -0400, Roland McGrath wrote:
> > Here is what you need:
> > Current CVS Hurd, at least the pfinet directory.
> > The patch from
> > http://www.marcus-brinkmann.de/files/pfinet-tun-20001005.diff.gz
>
> You should go ahead and check your code in, Marcus.
Done.
s with this. When I suggested mpd, I didn't realize that netgraph
was its only option.
> b. Porting ppp.
This is the one to use for now. I don't think there is too much to it.
___
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
Hi,
I have finished my work on the tunnel interface so far[1] that I think someone
can have a go at porting user space ppp. Don't count on me[2], I took a look at
it, and it's quite ugly, because ppp does a lot of things we don't support,
so you have to butcher to code a bit. See
So, who was going to work on PPP?
Thanks,
Marcus
--
`Rhubarb is no Egyptian god.' Debian http://www.debian.org Check Key server
Marcus Brinkmann GNUhttp://www.gnu.orgfor public PGP Key
[EMAIL PROTECTED], [EMAIL PROTECTED]PGP Key ID 36E7CD09
http://h
Roland McGrath <[EMAIL PROTECTED]> writes:
> (As your example is written, it suggests that /dev/eth0 and
> /dev/ppp0 are devices that deliver IP packets, while I would
> expect them to deliver Ethernet and PPP frames respectively.
Well actually I thought they would deliver datagr
> Could one set up a tree like this:
>
> pfinet
> +-- load balancing channel
> |+-- network device channel
> | +-- Mach eth0
> |+-- network device channel
> | +-- Mach eth1
> +-- PPP channel
> +-- serial port channel
>
ne set up a tree like this:
pfinet
+-- load balancing channel
|+-- network device channel
| +-- Mach eth0
|+-- network device channel
| +-- Mach eth1
+-- PPP channel
+-- serial port channel
+-- Mach com0
with commands like:
settrans -c /dev/eth0 /h
66 matches
Mail list logo
