serveez-discuss — users and developers can exchange their opinions and problems here

Re: [Serveez-discuss] texinfo

[stefan <st...@lk...>]

On Sat, 2 Dec 2000, Martin Grabmueller wrote:

> Ich hatte eigentlich vor, das hier zu machen:
> 
> --- autogen.sh.orig     Sun Jun 11 16:50:23 2000
> +++ autogen.sh  Sat Dec  2 15:51:03 2000
> @@ -44,7 +44,7 @@
>  if [ -r config.status ]; then
>    CMD=`awk '/^#.*\/?configure .*/ { $1 = ""; print; exit }' < config.status`
>  else
> -  CMD=`dirname $0`/configure
> +  CMD=`dirname $0`/configure --enable-maintainer-mode
>  fi
>  echo "Running $CMD $@ ..."
>  $CMD "$@"
> 
> Dann wird beim ersten mal `--enable-maintainer-mode' angehaengt, und
> bei allen weiteren Aufrufen auch ausgefuehrt, weil's aus config.status
> rausgefischt wird.
> 
> Soll ich diesen Mega-Patch committen?

Ja. Bitte.

st...@lk...

Re: [Serveez-discuss] texinfo

[Martin G. <mgr...@cs...>]

> Date: Thu, 30 Nov 2000 23:24:59 +0100 (CET)
> From: stefan <st...@lk...>
>
> Zu dem Tex: Ist schon komisch... Raimi macht gerade ne review der Doku und
> du koenntest ja mal wegen des build schauen ?? Wie gesagt: habe kein text
> hier.

Ich hab mal in serveez.texi reingeschaut:

*** Bad node line: @node Introduction, Using @value{PACKAGE}, Top, Top
*** Bad node line: @node Using @value{PACKAGE}, Concept, Introduction, Top
*** Bad node line: @node Concept, Server, Using @value{PACKAGE}, Top
*** Undefined node (Using Serveez): @xref{Using Serveez}.

Sieht aus, als ob texi2html keine Variablen in Node-Titeln vertraegt.
Allerdings scheints in @xref{} ohne Fehler zu klappen.  Dafuer faellt
mir allerdings kein vernuenfitger fix ein; leider wird dadurch kein
korrekter Link unter `Control Protocol Server' erzeugt, sondern im
HTML erscheint literal `@xref{Using Serveez}'.

Dieses @xref{...} mit einer Variable drin scheint auch das Problem
fuer TeX zu sein.  Wenn ich das aendere (@xref{Using @value{PACKAGE}}
-> @xref{Using Serveez}), dann kommt TeX damit klar.

Tja, um alle Probleme zu fixen, muesste man wohl an allen betroffenen
Stellen `Serveez' expandieren.  Aber das ist sicher nicht das, was du
mit den Variablen erreichen wolltest :(

Also, die Entscheidung liegt bei dir.

'mgrabmue

-- 
Martin Grabmueller              mgr...@cs...
http://www.pintus.de/mgrabmue/  mgrabmue@#lkcc on EFnet

Re: [Serveez-discuss] texinfo

[Martin G. <mgr...@cs...>]

> Date: Thu, 30 Nov 2000 23:24:59 +0100 (CET)
> From: stefan <st...@lk...>
> 
> Ja. Das ist aegerlich, steht auch so im ChangeLog. Aber die automake
> Skripte sehen das genauso vor. Wenn du willst, kannst du das GERNE machen
> mit dem "autogen.sh". Da muesste dann sowas stehen wie (if ! $cmdline ~=
> /enable-maintainer-mode/ $cmdline+=--enable-maintainer-mode) ja ? 

Ich hatte eigentlich vor, das hier zu machen:

--- autogen.sh.orig     Sun Jun 11 16:50:23 2000
+++ autogen.sh  Sat Dec  2 15:51:03 2000
@@ -44,7 +44,7 @@
 if [ -r config.status ]; then
   CMD=`awk '/^#.*\/?configure .*/ { $1 = ""; print; exit }' < config.status`
 else
-  CMD=`dirname $0`/configure
+  CMD=`dirname $0`/configure --enable-maintainer-mode
 fi
 echo "Running $CMD $@ ..."
 $CMD "$@"

Dann wird beim ersten mal `--enable-maintainer-mode' angehaengt, und
bei allen weiteren Aufrufen auch ausgefuehrt, weil's aus config.status
rausgefischt wird.

Soll ich diesen Mega-Patch committen?

'mgrabmue

-- 
Martin Grabmueller              mgr...@cs...
http://www.pintus.de/mgrabmue/  mgrabmue@#lkcc on EFnet

Re: [Serveez-discuss] strange pipe behaviour on linux box

[Martin G. <mgr...@cs...>]

> Date: Sat, 2 Dec 2000 02:19:17 +0100 (CET)
> From: stefan <st...@lk...>
> 
>   die named pipes unter linux funktionieren jetzt auch so, dass man mit
> hilfe des tunnel servers auch pipe connections forwarden kann (also pipe
> over icmp, hehe). 

Das klingt gut!

> allerdings hat sich eine komische sache angedeutet. ich
> verwende den einmal geoeffneten fd fuer die lese-pipe fuer jede neue
> verbindung. das funktioniert im grunde ganz gut. allerdings wirft der fd
> jede menge poll() errors, wenn ein neuer prozess diese pipe zum schreiben
> blockend oeffnet. irgendwann erholt sich das ganze und der connect ist
> fertig. hat das schon mal jemand gesehen ? meine frage ist nun, ob man den
> lese-fd irgendwie resetten kann ? oder ist es wirklich noetig, nach
> beenden eines connects die pipe neu zu oeffnen ?

Hm, ich schaetze du bewegst dich da auf einem Gebiet mit nicht ganz
definierter Semantik.  Eigentlich ist es fuer den Leser einer Pipe ja
so, dass ein Schreiberprozess, der sein Ende der Pipe schliesst, dem
Leser ein end-of-file praesentiert.  Kann also sein, dass der Leser
bei einem neuen Schreibprozess trotzdem erstmal am Dateiende liest,
und das gefaellt vielleicht dem Kern nicht.  Mehr kann ich dazu nicht
sagen, die man page fuer `fifo' ist da sehr unspezifisch und deutet
schon mal an, dass das Verhalten mit nicht-blockierenden Prozessen
seltsam ist und schon gar nicht portabel:

       Under  Linux,  opening a FIFO for read and write will suc-
       ceed both in blocking and non-blocking mode. POSIX  leaves
       this  behaviour undefined. This can be used to open a FIFO
       for writing while there are no readers available.  A  pro-

'mgrabmue

-- 
Martin Grabmueller              mgr...@cs...
http://www.pintus.de/mgrabmue/  mgrabmue@#lkcc on EFnet

[Serveez-discuss] strange pipe behaviour on linux box

[stefan <st...@lk...>]

hello,

  die named pipes unter linux funktionieren jetzt auch so, dass man mit
hilfe des tunnel servers auch pipe connections forwarden kann (also pipe
over icmp, hehe). allerdings hat sich eine komische sache angedeutet. ich
verwende den einmal geoeffneten fd fuer die lese-pipe fuer jede neue
verbindung. das funktioniert im grunde ganz gut. allerdings wirft der fd
jede menge poll() errors, wenn ein neuer prozess diese pipe zum schreiben
blockend oeffnet. irgendwann erholt sich das ganze und der connect ist
fertig. hat das schon mal jemand gesehen ? meine frage ist nun, ob man den
lese-fd irgendwie resetten kann ? oder ist es wirklich noetig, nach
beenden eines connects die pipe neu zu oeffnen ?

st...@lk...

[Serveez-discuss] texinfo

[stefan <st...@lk...>]

On Wed, 29 Nov 2000, Martin Grabmueller wrote:

> Du hast natuerlich recht.  ./autogen.sh hat's (fast) gefixt.  Ein
> Problem bleibt allerdings noch: Man muss nach dem autogen.sh noch ein
> ./configure --enable-maintainer-mode machen, sonst wird das
> doc/version.texi nicht erzeugt.  Vielleicht sollten wir das ins
> ./autogen.sh Skript einbauen? Wenn du willst, mach ich das.  Ausserdem
> wollte ich mir das Texinfo-file noch mal anschauen, da es im Moment
> nicht ohne Fehler von TeX gefressen wird.

Ja. Das ist aegerlich, steht auch so im ChangeLog. Aber die automake
Skripte sehen das genauso vor. Wenn du willst, kannst du das GERNE machen
mit dem "autogen.sh". Da muesste dann sowas stehen wie (if ! $cmdline ~=
/enable-maintainer-mode/ $cmdline+=--enable-maintainer-mode) ja ? 

Zu dem Tex: Ist schon komisch... Raimi macht gerade ne review der Doku und
du koenntest ja mal wegen des build schauen ?? Wie gesagt: habe kein text
hier.

st...@lk...

Re: [Serveez-discuss] Build failure as of CVS 2000-11-28

[Martin G. <mgr...@cs...>]

> Im CVS muesste sich eigentlich die raw-socket.* Dateien schon befinden.
> Das Problem koennte sein, dass sich auch das Makefile.am in src/ geaendert
> hat und du kein ./autogen.sh hast laufen lassen. Wenn es das nicht ist,
> dann meld' dich nochmal, bitte.

*AscheAufsHauptStreu*

Du hast natuerlich recht.  ./autogen.sh hat's (fast) gefixt.  Ein
Problem bleibt allerdings noch: Man muss nach dem autogen.sh noch ein
./configure --enable-maintainer-mode machen, sonst wird das
doc/version.texi nicht erzeugt.  Vielleicht sollten wir das ins
./autogen.sh Skript einbauen? Wenn du willst, mach ich das.  Ausserdem
wollte ich mir das Texinfo-file noch mal anschauen, da es im Moment
nicht ohne Fehler von TeX gefressen wird.

'mgrabmue

-- 
Martin Grabmueller              mgr...@cs...
http://www.pintus.de/mgrabmue/  mgrabmue@#lkcc on EFnet

Re: [Serveez-discuss] Build failure as of CVS 2000-11-28

[stefan <st...@lk...>]

On Tue, 28 Nov 2000, Martin Grabmueller wrote:

> icmp-socket.o: In function `icmp_check_packet':
> /home/mgrabmue/cvs/serveez/src/icmp-socket.c:204: undefined reference to `raw_check_ip_header'
> /home/mgrabmue/cvs/serveez/src/icmp-socket.c:216: undefined reference to `raw_ip_checksum'
> icmp-socket.o: In function `icmp_write':
> /home/mgrabmue/cvs/serveez/src/icmp-socket.c:466: undefined reference to `raw_ip_checksum'
> /home/mgrabmue/cvs/serveez/src/icmp-socket.c:499: undefined reference to `raw_ip_checksum'
> collect2: ld returned 1 exit status

Im CVS muesste sich eigentlich die raw-socket.* Dateien schon befinden.
Das Problem koennte sein, dass sich auch das Makefile.am in src/ geaendert
hat und du kein ./autogen.sh hast laufen lassen. Wenn es das nicht ist,
dann meld' dich nochmal, bitte.

st...@lk...

--
-- It's extremely painful to know that to eat I must play Mother
-- Culture's game. I WANT OUT.
--

[Serveez-discuss] Build failure as of CVS 2000-11-28

[Martin G. <mgr...@cs...>]

icmp-socket.o: In function `icmp_check_packet':
/home/mgrabmue/cvs/serveez/src/icmp-socket.c:204: undefined reference to `raw_check_ip_header'
/home/mgrabmue/cvs/serveez/src/icmp-socket.c:216: undefined reference to `raw_ip_checksum'
icmp-socket.o: In function `icmp_write':
/home/mgrabmue/cvs/serveez/src/icmp-socket.c:466: undefined reference to `raw_ip_checksum'
/home/mgrabmue/cvs/serveez/src/icmp-socket.c:499: undefined reference to `raw_ip_checksum'
collect2: ld returned 1 exit status
m

-- 
Martin Grabmueller              mgr...@cs...
http://www.pintus.de/mgrabmue/  mgrabmue@#lkcc on EFnet

[Serveez-discuss] Re: Evaluation of Serveez

[stefan <st...@lk...>]

On Mon, 27 Nov 2000, Holman Romero wrote:

> Hi again Stefan..!!
Hello Holman,

> I'm sorry, I was busy in others things, any personal problems. 
No problem.

> About evaluation... Hummm, look at this question:
> 
> -> Does the program recommend or encourage the use of any non-free
> software?
> 
> Serveez include a Gnutella Server and Gnutella it's not Free Software and 
> it's not a GNU Package, look at 
> http://www.gnu.org/philosophy/gnutella.html

In my eyes (and in the context i used it in source code and documentation)
Gnutella is a general term for the network protocol the original
"Gnutella" client (which is of course not free) uses to transfer data. The
gnutella spider within serveez is a *full* replacement of this client.
Thus i think there should be no problem here except that it might be used
to share non-free (illegal) data.

> ... and, I found this at configure options:
> 
>   --enable-q3key-proto    Include Quake3 license server [default=yes]
> 
> I think that this can cause problems. Technically, Serveez is very good
> and functional. What do you think about this?

In the documentation there is some hint. We discourage the use of this
server for legacy reasons. But it was an excellent example to show how udp
servers might work in serveez.

> On the other hand, I had a trouble when I tried install sizzle (take care,
> sizzle... not serveez). Problem was with reference to rlport.c in
> compile-time, and I solve it clearing rlport.c from POTFILES.in and other
> file that I do not remember now... and re-compile

I knew it ! There is always trouble with it... As noted in the INSTALL
file there are two possibilities to link the sizzle library to serveez,
shared or static. Actually there is no need to make a full installation of
the sizzle package. If you tell serveez's configure script where the
unpacked source tree of sizzle can be found it builds it itself
(--with-sizzle=../sizzle-0.0.xx). You could help us fixing your personal
problem with the sizzle installation giving us more information on that.

> Greetings...
> 
> Holman
> 
> P.D: Excuse my english... My native language is spanish  =)

My is german. So don't bother. We are looking forward to your further
comments and what you think about this answer.

Thanks in advance,
	st...@lk...

Re: [Serveez-discuss] binary release

[Martin G. <mgr...@cs...>]

Hallo auch,

>   ich werde in zukunft zu jeder source distribution auch immer eine binary
> release fuer windoze dazutun. ich uebersetze das projekt einfach mit allen
> debug infos. damit kann man alles unter win32 testen, ohne sich ein MSVC
> zu installieren.
> 
> Martin: wenn du wert darauf legst, koennte ich das dann auch bei dem
> sizzle projekt machen. 

Ich haette Interesse, da ich mich weigere, mir einen Windows-Compiler
zu installieren, aber gern ein Sizzle fuer Windows haette.  Wenn auch
nur zum heimisch fuehlen. :)

'mgrabmue

-- 
Martin Grabmueller              mgr...@cs...
http://www.pintus.de/mgrabmue/  mgrabmue@#lkcc on EFnet

[Serveez-discuss] binary release

[stefan <st...@lk...>]

Hallo,

  ich werde in zukunft zu jeder source distribution auch immer eine binary
release fuer windoze dazutun. ich uebersetze das projekt einfach mit allen
debug infos. damit kann man alles unter win32 testen, ohne sich ein MSVC
zu installieren.

Martin: wenn du wert darauf legst, koennte ich das dann auch bei dem
sizzle projekt machen. 

st...@lk...

--
-- It's extremely painful to know that to eat I must play Mother
-- Culture's game. I WANT OUT.
--

[Serveez-discuss] feedback survey has been activated

[stefan <st...@lk...>]

An alle Beteiligten und nicht Beteiligten: Wenn ihr was zum Serveez zu
sagen habt, dann fuellt eben mal die Umfrage auf Sourceforge.net aus. Wir
sind gespannt, was eure Meinung zu dem Ganzen ist.

st...@lk...

[Serveez-discuss] Evaluation of Serveez (fwd)

[stefan <st...@lk...>]

st...@lk...

--
-- It's extremely painful to know that to eat I must play Mother
-- Culture's game. I WANT OUT.
--

---------- Forwarded message ----------
Date: Sat, 11 Nov 2000 09:03:04 -0500 (COT)
From: Holman Romero <hr...@gn...>
To: st...@lk...
Subject: Evaluation of Serveez


Hi Stefan!!

I'm working on Serveez, and I've very good concepts about on. Next days
I will have completed my task and I will present it you.

Greetings,

Holman Romero
GNU Software Evaluator
hr...@gn...
Support the Free Software 
Support the GNU Project 

[Serveez-discuss] RE: [Ethereal-dev] off-topic (fwd)

[stefan <st...@lk...>]

---------- Forwarded message ----------
Date: Mon, 6 Nov 2000 08:57:41 -0500 
From: "Clayton, Mark" <mcl...@ne...>
To: 'stefan' <st...@lk...>, "Clayton, Mark" <mcl...@ne...>
Subject: RE: [Ethereal-dev] off-topic


Sorry for the delay in replying.  We're in a tough
release cycle.  In 2.3.42, I have not seen the 
behavior you describe.
I think you're right that raw sockets are weak in Linux.

Mark

-----Original Message-----
From: stefan [mailto:st...@lk...]
Sent: Thursday, November 02, 2000 1:38 PM
To: Clayton, Mark
Subject: RE: [Ethereal-dev] off-topic


On Wed, 1 Nov 2000, Clayton, Mark wrote:

> I don't know many of the details, but a couple of real guru's here
> have said that raw sockets on version 2.2.14 are busted.  We've
> been using the development kernel 2.3.42 and the raw socket support
> is much better.  However, the filesystem seems very unstable.  If 
> you get anything helpful on this, would you please forward it to me?
> I'd like to know what the thinking is on what and how raw sockets
> are to be implemented in the kernel.  We've also found that there
> is not a ioctl function for raw sockets, but there is for all of the
> other socket family members.  

Thanks for your quick response ! I tried the latest linux kernel
2.4.0-test10 and it got even worse. I do not know if it is a feature: I am
using recvfrom() and sendto() for read/write on raw sockets and with the
new kernel the remote address in the last argument of recvfrom() is not
even set. It states "0.0.0.0". That is not likely the 2.2.17 kernel did. I
know that the source address of each packet is given in the ip header, but
it has also been set in that argument... Is this bug or feature ?

The ip header checksum is bad on big packets in either kernels. Is all
this a real kernel problem ? I would not have thought, that linux is weak
on raw sockets ! But I think the reason for that is just that generally
this is not used very often in user programs...

Please tell me, if you got any news.

st...@lk...

[Serveez-discuss] RE: [Ethereal-dev] off-topic (fwd)

[stefan <st...@lk...>]

---------- Forwarded message ----------
Date: Wed, 1 Nov 2000 07:39:28 -0500 
From: "Clayton, Mark" <mcl...@ne...>
To: 'stefan' <st...@lk...>
Subject: RE: [Ethereal-dev] off-topic


I don't know many of the details, but a couple of real guru's here
have said that raw sockets on version 2.2.14 are busted.  We've
been using the development kernel 2.3.42 and the raw socket support
is much better.  However, the filesystem seems very unstable.  If 
you get anything helpful on this, would you please forward it to me?
I'd like to know what the thinking is on what and how raw sockets
are to be implemented in the kernel.  We've also found that there
is not a ioctl function for raw sockets, but there is for all of the
other socket family members.  
Thanks,
Mark

-----Original Message-----
From: stefan [mailto:st...@lk...]
Sent: Wednesday, November 01, 2000 4:01 AM
To: eth...@zi...
Subject: [Ethereal-dev] off-topic


Hello Ethereal'ers

i was wondering about some networking "problem" but cannot find any
information about it. thus i try it here, because i guess you got the
know-how i wanted:

when creating a raw socket without any more setsockopt's it receives ip
messages inclusive ip header. if i want to recalculate the header checksum
it works fine for small packets. but if the packet has been fragmented and
assembled again by the kernel (this could have been seen in ethereal ->
great software!) the header checksum is some kind wrong !? it seems like i
got the checksum of one of fragments and not of the whole packet. if you
know anything about this, please, please tell me.

i am using:
Linux bono 2.2.17 #2 Wed Sep 27 00:13:05 CEST 2000 i586 unknown

thanks in advance,
	st...@lk...

_______________________________________________
Ethereal-dev mailing list
Eth...@et...
http://www.ethereal.com/mailman/listinfo/ethereal-dev

[Serveez-discuss] Linking Windows import libraries (fwd)

[stefan <st...@lk...>]

Hallo, das sind doch gute Nachrichten vom MinGW port vom gcc: Man kann
jetzt auch gegen MSVC++ import libraries linken. Und das beste scheint zu
sein, dasz man sogar nur gegen DLLs linken kann, ohne die entsprechende
.lib Datei zu haben.

---------- Forwarded message ----------
Date: Wed, 1 Nov 2000 13:05:14 +1300 (NZDT)
From: "[iso-8859-1] Danny Smith" <dan...@ya...>
To: Paul Sokolovsky <pa...@is...>, camilo ramos <cr...@co...>
Cc: min...@li...
Subject: Re: [Mingw-users] Linking Windows import libraries


--- Paul Sokolovsky <pa...@is...> wrote: > Hello camilo,
> 
> camilo ramos <cr...@co...> wrote:
> 
> cr> Hello all,
> 
> cr> I was  wondering  about  the  following: Can  one  statically
> link in *.lib
> cr> import library files produced by Visual C++? Note that the 
> object files
> cr> that would be used to produce the *.lib are  not  part of a DLL,
> neither
> cr> there would be a DLL  equivalent  to  such *.lib file. Just the
> archived
> cr> objects the way one can do it in Unix with an *.a archive file
> for
> cr> static linking.
> 
> cr>  Is this possible?
> 
PS>      That's exactly what recently released alapha binutils might be
PS> good for. Danny, can you confirm this?
New ld can link against MS style import libs - including most recent
PSDK - directly.  

Like so:
gcc -o foo.exe foo.o d:/psdk/lib/odbc32.lib 

or you could rename to libodbc32.a and use the usual 
gcc -o foo.exe foo.o -Ld:/psdk/lib -lodbc32


Also against MS static.libs (but could be problems with dependency on
MS static crt libc.lib).     Also  problems if you try to link against
MS debug build (which depend on msvcrtd.dll).

C++ libs won't work of course.

You can also link against a C dll without any import lib (ld builds one
on-the-fly), but, in my experience, *only* if __cdecl.

 
> cr>  Any  suggestions  thanked.
> 
> 
> cr> Best regards,
> cr>  camilo                          mailto:cr...@co...

[Serveez-discuss] Re: Schulterklopf

[stefan <st...@lk...>]

On Tue, 31 Oct 2000, Martin Grabmueller wrote:

> Hallo Ela,
Hallo selbst, und danke: *schulter schmerz*

> ich spiele gerade mit Serveez rum und bin richtig begeistert von dem
> Tunnel-Server (Firewall-Admins, nehmt euch in acht!).  Das
> TCP-over-UDP-over-TCP fuer HTTP-Requests funktioniert total prima,
> sogar mit keepalive!  Einfach zwei Server in der Config-Datei
> definieren, fertig.  Das soll euch erst mal einer nachmachen.
> 
> Wie sieht das mit icmp-Paketen aus?  Kann man darueber nur Tunneln,
> wenn man root-Rechte hat (mit icmp bin ich echt kein Auskenner).
ICMP Socken kann man nur als root aufmachen. Das war schon immer so.

el...@lk...

[Serveez-discuss] Win32 logo

[stefan <st...@lk...>]

Hallo,

schon seit einiger Zeit kann man sowohl unter Unix als auch unter Win32
den Serveez als `daemon' starten. Bei Windows erscheint das Programm dann
einmal in der Taskleiste und andererseits auch als Icon im Taskbar. Leider
habe ich ueberhaupt keine *.ico Datei dafuer. Die muss 16x16 Pixel gross
sein und 16 oder 256? Farben haben. Also falls jemand eine Idee oder
ein Icon hat, dann kann er mir das ja zusenden. Bis dato benutze ich eines
der systeminternen Standard-Icons.

st...@lk...

[Serveez-discuss] Tunnel server + Dokumentation

[stefan <st...@lk...>]

Hallo,

in der Datei `serveez.cfg' befinden sich jetzt 2 Konfigurationen, die
einmal einen TCP Tunnel ueber UDP auf den HTTP Port 80 und dann einen TCP
Tunnel ueber ICMP auf den Telnet Port 23 instanziieren. Ich denke ich musz
nicht sagen, dasz ich das gern getestet haben moechte... lokal
funktioniert beides jedenfalls.

Ich moechte dann noch darum bitten, dasz du (Raimi) uns mal das
serveez.dvi ausdruckst, damit wir die Doku querlesen koennen, um
irgendwelche Typos und sonstiges ausmerzen koennen. Ich weiss naemlich
nicht, wie man unter Linux sowas druckt. Auszerdem kann ich das DVI bei
mir gar nicht erzeugen, weil ich kein TeX installiert habe.

st...@lk...

RE: [Serveez-discuss] ICMP sockets

[stefan <st...@lk...>]

On Sat, 28 Oct 2000, stefan wrote:

>> richtige Idee, wie ich zwei ICMP sockets miteinader verbinde, da immer
>> alle ICMP sockets auch alle Messages empfangen. Bei UDP sockets gab es
>> ja noch Ports. Das loeste das Problem. Also wenn jemand eine
>> gute Idee hat,

> Naja, ein eigenenes Type feld. Absendeadresse und type feld 
> identifizieren die gegenstelle. wenn man ping (typ 8 und 0 glaub ich),
> dann soll das so sein. die payload zaehlt. mit einem icmp gateway kann man
> halt nur eine verbindung auf einmal haben, das war schon klar.

Ich habe jetzt einfach an den `normalen' ICMP header einfach einen port
drangehangen, der mir die ICMP sockets verbindungsorientiert macht. Auf
diese Art und Weise kann jeder socket filtern, was fuer ihn bestimmt ist,
und was nicht. Damit funktioniert jetzt auch "TCP over ICMP". Ausprobiert
habe ich das ganze, indem ich zwei Tunnel-Server instanziiert habe, die
einerseits von TCP:42425 -> ICMP und andererseits von ICMP -> TCP:80 (mein
lokaler Apache) tunneln. Das geht ziemlich gut, hat aber noch Fehler, die
ich bis jetzt nicht reproduzieren konnte.

Ein weiteres Problem ist dabei aufgetaucht: Wenn man grosse ICMP Packete
(ca. 64 KB) abschickt, dann fragmentiert das System diese (sieht man in
Ethereal). Beim Empfangen dieser Packete merkt der Serveez das aber nicht.
Also er bekommt das Packet vollstaendig und ohne Hinweis darauf, das es
fragmentiert war. Die Sache ist nun die, dasz die Checksumme im IP header
dann nicht mehr stimmt. Vielleicht ist aber auch die Berechnung der
Checksumme im Serveez auch falsch. Das Problem habe ich bis dato erstmal
so umgangen, indem ich nur kleine ICMP Packete (ca. 1KB) sende, dann wird
nicht fragmentiert. Gibt's da eine bessere Loesung ?

st...@lk...

--
-- It's extremely painful to know that to eat I must play Mother
-- Culture's game. I WANT OUT.
--

Re: [Serveez-discuss] ICMP sockets

[Raimi <ra...@cs...>]

On Sat, 28 Oct 2000, stefan wrote:

> der Tunnel Server benutzt das ICMP Interface von Serveez. Leider habe ich
> zu viele Segfaults und andere Fehler darin. Auszerdem habe ich keine

Hehe. http://www.hpl.hp.com/personal/Hans_Boehm/gc/ kuck dir das mal an.
Bin auch grad dabei, aber ich komme wie immer nur schleppend voran.

> richtige Idee, wie ich zwei ICMP sockets miteinader verbinde, da immer
> alle ICMP sockets auch alle Messages empfangen. Bei UDP sockets gab es ja
> noch Ports. Das loeste das Problem. Also wenn jemand eine gute Idee hat,

Naja, ein eigenenes Type feld. Absendeadresse und type feld identifizieren
die gegenstelle. wenn man ping (typ 8 und 0 glaub ich), dann soll das so
sein. die payload zaehlt. mit einem icmp gateway kann man halt nur eine
verbindung auf einmal haben, das war schon klar.

> dann bitte ich darum. Prinzipiell funktioniert der Tunnel-Server schon.
> Man kann IP-Protokoll uebergreifend Ports forwarden.

supa.

sodann

 _  __
| )  |                                "What do you get if you   *    **  |
|\aimund                               multiply 6 by 9?"        * *    * |
|    |                                                          ****  *
   _/acob                                                        *  *** O

             **** Remember: 21 is just half the truth ****

[Serveez-discuss] ICMP sockets

[stefan <st...@lk...>]

Hallo,

der Tunnel Server benutzt das ICMP Interface von Serveez. Leider habe ich
zu viele Segfaults und andere Fehler darin. Auszerdem habe ich keine
richtige Idee, wie ich zwei ICMP sockets miteinader verbinde, da immer
alle ICMP sockets auch alle Messages empfangen. Bei UDP sockets gab es ja
noch Ports. Das loeste das Problem. Also wenn jemand eine gute Idee hat,
dann bitte ich darum. Prinzipiell funktioniert der Tunnel-Server schon.
Man kann IP-Protokoll uebergreifend Ports forwarden.

st...@lk...

--
-- It's extremely painful to know that to eat I must play Mother
-- Culture's game. I WANT OUT.
--

[Serveez-discuss] Testing Gnutella Push Requests

[stefan <st...@lk...>]

Hallo Raimi,

der Gnutella Server kann jetzt theoretisch auch Downloads mit Rechnern
hinter Gateways. D.h., dass der Spider einen Push Request an diesen
Rechner schickt. Koenntest Du das bitte mal testen ?

el...@lk...

--
-- It's extremely painful to know that to eat I must play Mother
-- Culture's game. I WANT OUT.
--