slirp-devel Mailing List for Slirp Maintance Project
Brought to you by:
rogerplant,
strredwolf
Menu
▾
▴
slirp-devel
You can subscribe to this list here.
| 2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(2) |
Jun
|
Jul
(6) |
Aug
(11) |
Sep
(2) |
Oct
(5) |
Nov
(6) |
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
(3) |
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
(7) |
Sep
|
Oct
(1) |
Nov
(1) |
Dec
|
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
(1) |
Jul
|
Aug
(1) |
Sep
(3) |
Oct
(6) |
Nov
|
Dec
(9) |
| 2003 |
Jan
(4) |
Feb
|
Mar
(1) |
Apr
|
May
(1) |
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2004 |
Jan
|
Feb
|
Mar
(1) |
Apr
(1) |
May
|
Jun
(5) |
Jul
(2) |
Aug
|
Sep
(2) |
Oct
|
Nov
(5) |
Dec
(4) |
| 2005 |
Jan
|
Feb
|
Mar
|
Apr
(2) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
| 2006 |
Jan
(3) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(4) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2008 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(5) |
Dec
(4) |
| 2009 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(3) |
Oct
|
Nov
|
Dec
(1) |
| 2010 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2012 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
| 2013 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(3) |
Jul
(1) |
Aug
(1) |
Sep
(1) |
Oct
|
Nov
|
Dec
|
| 2014 |
Jan
|
Feb
|
Mar
(1) |
Apr
(1) |
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2015 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
| 2016 |
Jan
(1) |
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2017 |
Jan
|
Feb
|
Mar
(2) |
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2020 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Marek M. <ma...@gm...> - 2020-01-02 10:09:22
|
Good morning! There seem to be a wider discussion about the future of libslirp. Some suggest to use smoltcp [1]. I tried a different approach. I drafted a slirp4netns-alike code using gvisor netstack: https://gist.github.com/majek/778021e4f95f3e77ada5afcecacbd819 The code is very rough, but shows the potential of netstack. The biggest problem I had with netstack is the routing setup. A) I wasn't able to get routing right, so opted out for assigning 0/0 onto the tun interface internally in netstack. This results in ping's being accepted by netstack. Ping _anything_ from guest will always be responded by netstack. I'm not sure how to work around it. Perhaps extend netstack to have IcmpForwarder, just like we have tcp.Forwarder? B) I'm not sure how to do connection forwarding going from host to guest. This is again, mostly related to routing configuration. Let me know what you think. Cheers, Marek [1] https://github.com/rootless-containers/slirp4netns/issues/171 |
|
From: kong k. <kon...@ou...> - 2017-03-31 04:42:10
|
Hello, I am Barr Kong Khemara, I humbly ask if you are related to my client who died couple of years ago in a car accident here in my country Cambodia. I wish to also inquire if it is possible to have different families with the same last name as yours by coincidence who do not share the same common roots? Kindly get back to me if your email is still Valid to enable me give you the details of my message or make headway in my search. Regards, Kong Khemara |
|
From: Aslamasrar <asl...@gm...> - 2013-09-25 16:23:59
|
من جهاز الـ iPhone الخاص بي |
|
From: N. P. S. <inf...@in...> - 2013-08-26 17:01:35
|
Centro de Reparos NFS - Reparamos todas as marcas e modelos de equipamentos com tecnologias Wireless, VoIP, Network, Telecom, Cameras e Dispositivos de Seguranca. Atendemos a fabricantes, revendas, distribuidores, usuarios corporativos e usuarios finais. Equipamentos VoIP, ATAs, Gateways VoIP, Gateways GSM, Routers E1, Telefones IP, Video-fones IP, IP-PBX. Equipamentos de Rede, Routerboard, Ubiquiti, AP, Backhaul, Equipamentos para Enlaces Ponto a Ponto e Multi-Ponto, Switches, Roteadores, Firewalls, Modem, Cable-Modem, Setup box, Audio e Video Conferencia. Equipamentos de Seguranca, Cameras IP, Cameras IP PTZ, Cameras Panoramicas, DVR, Video Encoders, IPTV, Placas de Captura CFTV e CFTV-IP, entre outros. Saiba que A NFS repara todas as marcas e modelos de equipamentos de conectividade Wireless, VoIP, Network, Telecom e Cameras de fabricacao, nacional e importados. Geralmente o valor do reparo de um equipamento fica entre 25 e 40 porcento do valor de um novo comercializado em mercado nacional e tem garantia absoluta de servico pelo periodo de 3 meses. Com a ampliacao de nossa estrutura e quantidade de colaboradores, garantimos um atendimento personalizado atraves de nossa equipe de atendentes comerciais. A NFS esta preparada para atender desde usuarios ate fabricantes, com total profissionalismo e garantia de satisfacao. Entre em contato conosco e conheca melhor as solucoes que a NFS lhe oferece. A NFS Cresceu e quer que voce e sua empresa participe de nossas conquistas. A NFS Professional Services e uma empresa solidamente estruturada na area de servicos de Reparo, Re-Manufatura, Suporte Tecnico Especializado e Autorizado da marca AudioCodes e Treinamentos com Certificacoes na area de TI. Sua ampla gama de atendimento percorre toda a cadeia na area de TI, desde Operadoras de Telecom (sejam elas moveis, fixas ou de TVs por assinatura), Provedores ISP e WISP, Distribuidores, Revendas, Integradores, Lojistas, Fabricantes ate usuarios Finais, assim como as demandas do mercado corporativo e governos. Os diferenciais da NFS Professional Services provem de sua capacidade tecnica produtiva, da utilizacao inovadora de tecnologia e engenharia na analise e correcao de falhas, de suas aliancas tecnologicas e da reconhecida qualificacao por sua excelencia de servicos, fazendo da execucao com excelencia profissional uma de suas principais caracteristicas. Central de Atendimento Endereco: Rua Serra de Botucatu, 627 - Tatuape - Sao Paulo - SP CEP: 03317-000 Telefones Central de Atendimento: 55 (11) 2093-9155 55 (11) 2385-3977 email: ate...@nf... |
|
From: Mateusz V. <ma...@vi...> - 2013-06-30 10:02:46
|
Hi, Indeed now, when I look at the mailing list archive on sourceforge, I see there have been no meaningful traffic for years. I'm not sure my patch would be relevant, since I did it basing on a slirp code I got somewhere on debian servers, so it's likely to be different than what the slirp maintenance project has (on the sourceforge cvs I see only some oldish v1.0.14beta from 12 years ago...). Could be nice to mark the project on sourceforge as 'abandoned' :) Anyway, I packaged slirp v1.0.17 for a few distros (src packages with my modified code are avaiable, too). If it's of any interest to anyone, here are the packages: http://software.opensuse.org/package/slirp cheers, Mateusz On 06/29/2013 10:22 PM, Marc Singer wrote: > Not sure. I haven't seen traffic on this list in...well...years. I > don't even know if there is an archive. > > Do you want to post your patch? > > I suppose we could put an archive on github. > > > On Sat, Jun 29, 2013 at 7:38 AM, Mateusz Viste <ma...@vi... > <mailto:ma...@vi...>> wrote: > > Hi, > > Just wondering - is the slirp maintenance project still alive? > > I noticed that it haven't been updated since years, and my attempts to > compile it produced buckets of complaints from my compiler (eventually I > managed to compile it, but it required to change lots of functions > declarations). > > I see that lately the Qemu team is quite active on their slirp fork > (that the integrated into qemu for their 'user net' feature) - is there > any chance to see their patches ported to the main slirp tool? > > cheers, > Mateusz |
|
From: Marc S. <el...@bu...> - 2013-06-29 20:22:15
|
Not sure. I haven't seen traffic on this list in...well...years. I don't even know if there is an archive. Do you want to post your patch? I suppose we could put an archive on github. On Sat, Jun 29, 2013 at 7:38 AM, Mateusz Viste <ma...@vi...>wrote: > Hi, > > Just wondering - is the slirp maintenance project still alive? > > I noticed that it haven't been updated since years, and my attempts to > compile it produced buckets of complaints from my compiler (eventually I > managed to compile it, but it required to change lots of functions > declarations). > > I see that lately the Qemu team is quite active on their slirp fork > (that the integrated into qemu for their 'user net' feature) - is there > any chance to see their patches ported to the main slirp tool? > > cheers, > Mateusz > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Windows: > > Build for Windows Store. > > http://p.sf.net/sfu/windows-dev2dev > _______________________________________________ > Slirp-devel mailing list > Sli...@li... > https://lists.sourceforge.net/lists/listinfo/slirp-devel > > |
|
From: Mateusz V. <ma...@vi...> - 2013-06-29 14:38:15
|
Hi, Just wondering - is the slirp maintenance project still alive? I noticed that it haven't been updated since years, and my attempts to compile it produced buckets of complaints from my compiler (eventually I managed to compile it, but it required to change lots of functions declarations). I see that lately the Qemu team is quite active on their slirp fork (that the integrated into qemu for their 'user net' feature) - is there any chance to see their patches ported to the main slirp tool? cheers, Mateusz |
|
From: danichos g. <aga...@ho...> - 2012-09-10 23:35:39
|
Sent from my iPad |
|
From: 李坚 <li...@vc...> - 2012-07-24 09:29:04
|
Hi Cloud I have a slirp source code. Thanks for your email. Regards! |
|
From: bl4 <bl4...@pl...> - 2011-08-14 08:39:24
|
On 08/13/2011 11:49 PM, Marc Singer wrote: > > > On Sat, Aug 13, 2011 at 8:23 AM, bl4 <bl4...@pl... > <mailto:bl4...@pl...>> wrote: > > When I run slirp from the command line on NetBSD amd64, it prints "SLiRP > Ready ..." and exits. > > I found that the select call returns EINVAL because the timeout argument > is invalid. The problem is caused by this code in main.c: > > if ((timeout.tv_usec < 0) || (tmp_time >= 0 && tmp_time < > timeout.tv_usec)) > timeout.tv_usec = (u_int)tmp_time; > > tmp_time is -1, u_int is 32-bit and tv_usec (long) is 64-bit thus > tv_usec becomes 4294967295. The solution is to remove the (u_int) cast > or remove these two lines altogether. > > > I believe that the cast is invalid. The type of tmp_time should be declared > the same as tv_usec. What I don't understand is how the test is succeeding. > I would guess that the intention is that we set tv_usec to tmp_time iff > is it > 0. For these tests to be valid tmp_time must be signed. > > As such, It makes more sense to test explicitly for ~0 instead of using -1. > > Cheers The test succeeds because timeout.tv_usec is -1 too which satisfies the || before tmp_time is checked. Perhaps the intention was to write: if (tmp_time >= 0 && (timeout.tv_usec < 0 || tmp_time < timeout.tv_usec)) -- bl4 |
|
From: bl4 <bl4...@pl...> - 2011-08-13 15:30:22
|
When I run slirp from the command line on NetBSD amd64, it prints "SLiRP Ready ..." and exits. I found that the select call returns EINVAL because the timeout argument is invalid. The problem is caused by this code in main.c: if ((timeout.tv_usec < 0) || (tmp_time >= 0 && tmp_time < timeout.tv_usec)) timeout.tv_usec = (u_int)tmp_time; tmp_time is -1, u_int is 32-bit and tv_usec (long) is 64-bit thus tv_usec becomes 4294967295. The solution is to remove the (u_int) cast or remove these two lines altogether. -- bl4 |
|
From: Mark L. < <mar...@lo...> - 2010-03-09 07:52:08
|
I wonder if someone could help me with a frustrating problem I'm
having with slirp-based networking in UML? (If it would be better to
direct this to one of the UML mailing lists, please let me know.) I'd
be very grateful for any help.
Although this has worked for me successfully in the past, I'm having
trouble getting the "redir" option for slirp to work properly for
connecting to a UML instance. (Network access from the UML machine to
the outside world works fine, it's just the incoming connections that
fail.)
If I run tcpdump on the UML it seems that some packets are directed to
the right port, but there are no replies at all. To describe the
setup in more detail, I'm starting the server with:
linux mem=256M ubda=uml-rootfs-test umid=TWFY con=null ssl=null con0=fd:0,fd:1 con1=xterm eth0=slirp,,./slirp-wrapper
... where ./slirp-wrapper is a script consisting of:
#!/bin/sh
exec slirp-fullbolt -S "redir 8042 80" "redir 2242 22" "$@"
This appears to set up the redirections correctly, since I see the
following output (with some whitespace edited for readability):
[..]
Setting up networking....
Configuring network interfaces...
Slirp v1.0.17 (BETA) FULL_BOLT
Copyright (c) 1995,1996 Danny Gasparovski and others.
All rights reserved.
This program is copyrighted, free software.
Please read the file COPYRIGHT that came with the Slirp
package for the terms and conditions of the copyright.
Logging statistics
Redirecting TCP port 8042 to 10.0.2.15:80
Redirecting TCP port 2242 to 10.0.2.15:22
IP address of Slirp host: 127.0.1.1
IP address of your DNS(s): 10.101.0.1
Your address is 10.0.2.15
(or anything else you want)
Type five zeroes (0) to exit.
[autodetect SLIP/CSLIP, MTU 1500, MRU 1500]
SLiRP Ready ...
done.
INIT: Entering runlevel: 2
Starting enhanced syslogd: rsyslogd.
[..]
The UML machine's root filesystem has the following
/etc/network/interfaces:
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet static
address 10.0.2.15
netmask 255.0.0.0
gateway 10.0.2.15
... and resolv.conf consists of:
nameserver 10.0.2.3
The output of ifconfig and route -n in the UML instance are as
follows:
sandbox:~# ifconfig
eth0 Link encap:Serial Line IP
inet addr:10.0.2.15 Mask:255.0.0.0
UP RUNNING NOARP MTU:1500 Metric:1
RX packets:3 errors:0 dropped:0 overruns:0 frame:0
TX packets:3 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:256
RX bytes:384 (384.0 B) TX bytes:159 (159.0 B)
Interrupt:5
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
sandbox:~# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
10.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 eth0
0.0.0.0 10.0.2.15 0.0.0.0 UG 0 0 0 eth0
The web server running on the UML machine is listening on all
interfaces:
sandbox:~# netstat -ap|egrep apach
tcp 0 0 *:www *:* LISTEN 955/apache2
If I set tcpdump running on the UML machine and make a request from
the host to http://localhost:8042/ then the following is captured:
sandbox:~# tcpdump -n -vvv
tcpdump: listening on eth0, link-type RAW (Raw IP), capture size 96 bytes
16:17:30.869511 IP (tos 0x0, ttl 64, id 17099, offset 0, flags [none], proto TCP (6), length 44) 127.0.1.1.52602 > 10.0.2.15.80: S, cksum 0x96b6 (correct), 157056001:157056001(0) win 8760 <mss 1460>
16:17:36.827335 IP (tos 0x0, ttl 64, id 17100, offset 0, flags [none], proto TCP (6), length 44) 127.0.1.1.52602 > 10.0.2.15.80: S, cksum 0x96b6 (correct), 157056001:157056001(0) win 8760 <mss 1460>
16:17:36.827335 IP (tos 0x0, ttl 64, id 17100, offset 0, flags [none], proto TCP (6), length 44) 127.0.1.1.52602 > 10.0.2.15.80: S, cksum 0x96b6 (correct), 157056001:157056001(0) win 8760 <mss 1460>
16:17:49.091012 IP (tos 0x0, ttl 64, id 17101, offset 0, flags [none], proto TCP (6), length 44) 127.0.1.1.52602 > 10.0.2.15.80: S, cksum 0x96b6 (correct), 157056001:157056001(0) win 8760 <mss 1460>
16:18:01.354694 IP (tos 0x0, ttl 64, id 17102, offset 0, flags [none], proto TCP (6), length 44) 127.0.1.1.52602 > 10.0.2.15.80: S, cksum 0x96b6 (correct), 157056001:157056001(0) win 8760 <mss 1460>
In the UML instance, the equivalent works:
sandbox:~# curl 'http://10.0.2.15/'
<html><body><h1>It works!</h1></body></html>
I'm using the Ubuntu 9.10 packages of user-mode-linux, uml-utilities
and slirp:
slirp 1:1.0.17-2
uml-utilities 20070815-1.1ubuntu2
user-mode-linux 2.6.22-2um-0ubuntu2
The uname -a output of the host machine is:
Linux cava 2.6.31-20-generic #57-Ubuntu SMP Mon Feb 8 09:05:19 UTC 2010 i686 GNU/Linux
... and similarly for the UML guest:
Linux sandbox 2.6.22-rc5 #2 Mon Jul 2 10:14:22 GMT 2007 i686 GNU/Linux
The output in slirp_stats after a run when a couple of requests to
http://localhost:8042/ from the host had failed as described above is:
Slirp 1.0.17 - Debugging Started.
Debugging Started level 15.
IP stats:
9 total packets received (0 were unaligned)
0 with incorrect version
0 with bad header checksum
0 with length too short (len < sizeof(iphdr))
0 with length too small (len < ip->len)
0 with bad header length
0 with bad packet length
0 fragments received
0 fragments dropped
0 fragments timed out
0 packets reassembled ok
0 outgoing packets fragmented
0 total outgoing fragments
0 with bad protocol field
9 total packets delivered
TCP stats:
14 packets sent
0 data packets (0 bytes)
0 data packets retransmitted (0 bytes)
0 ack-only packets (0 delayed)
0 URG only packets
0 window probe packets
0 window update packets
14 control (SYN/FIN/RST) packets
0 times tcp_output did nothing
0 packets received
0 acks (for 0 bytes)
0 duplicate acks
0 acks for unsent data
0 packets received in sequence (0 bytes)
0 completely duplicate packets (0 bytes)
0 packets with some duplicate data (0 bytes duped)
0 out-of-order packets (0 bytes)
0 packets of data after window (0 bytes)
0 window probes
0 window update packets
0 packets received after close
0 discarded for bad checksums
0 discarded for bad header offset fields
2 connection requests
0 connection accepts
0 connections established (including accepts)
2 connections closed (including 0 drop)
2 embryonic connections dropped
2 segments we tried to get rtt (0 succeeded)
12 retransmit timeouts
0 connections dropped by rxmt timeout
0 persist timeouts
2 keepalive timeouts
0 keepalive probes sent
2 connections dropped by keepalive
0 correct ACK header predictions
0 correct data packet header predictions
0 TCP cache misses
UDP stats:
8 datagrams received
0 with packets shorter than header
0 with bad checksums
0 with data length larger than packet
2 UDP socket cache misses
4 datagrams sent
ICMP stats:
1 ICMP packets received
0 were too short
0 with bad checksums
1 with type not supported
0 with bad type feilds
0 ICMP packets sent in reply
Mbuf stats:
2 mbufs allocated (2 max)
1 mbufs on free list
1 mbufs on used list
0 mbufs queued as packets
Proto[state] Sock Local Address, Port Remote Address, Port RecvQ SendQ
tcp[REDIRECT] 4 10.0.2.15 22 127.0.1.1 2242 0 0
tcp[REDIRECT] 3 10.0.2.15 80 127.0.1.1 8042 0 0
udp[232 sec] 6 10.0.2.15 32768 10.0.2.3 53 0 0
VJ compression stats:
0 outbound packets (0 compressed)
0 searches for connection stats (0 misses)
0 inbound uncompressed packets
0 inbound compressed packets
0 inbound unknown type packets
0 inbound packets tossed due to error
|
|
From: Dan L. <dl...@gm...> - 2009-09-06 00:00:27
|
Daniel Lenski <dl...@gm...> writes: > This is the suggested way of testing according to the Debian packagers. > It works perfectly fine for me with most hosts, but I have compiled > Slirp on a couple of SunOS systems where this just doesn't work... pppd > and remote slirp are unable to communicate. > > I've also tried it in CSLIP and SLIP modes, to no avail. I think it's a > problem with how SSH on the SunOS machines constructs the > pseudo-terminal through which Slirp communicates, but I'm not entirely > sure. So I'm wondering if anyone can point out the precise terminal > requirements for it to work. Perhaps I should mention the specific OS on this (remote) system which doesn't seem to work with Slirp: $ uname -a SunOS y.glue.umd.edu 5.10 Generic_139555-08 sun4v sparc SUNW, SPARC-Enterprise-T5220 Dan |
|
From: Daniel L. <dl...@gm...> - 2009-09-05 23:34:50
|
Hi, Can anyone tell me exactly what the requirements are for Slirp to work over a terminal? I'm test it via SSH using a command-line like this: # pppd nodefaultroute noauth nobsdcomp nodetach debug :10.1.2.1 pty "ssh -t us...@re... slirp ppp" This is the suggested way of testing according to the Debian packagers. It works perfectly fine for me with most hosts, but I have compiled Slirp on a couple of SunOS systems where this just doesn't work... pppd and remote slirp are unable to communicate. I've also tried it in CSLIP and SLIP modes, to no avail. I think it's a problem with how SSH on the SunOS machines constructs the pseudo-terminal through which Slirp communicates, but I'm not entirely sure. So I'm wondering if anyone can point out the precise terminal requirements for it to work. Thanks! Dan Lenski |
|
From: Daniel L. <le...@um...> - 2009-09-05 23:32:57
|
Hi, Can anyone tell me exactly what the requirements are for Slirp to work over a terminal? I'm test it via SSH using a command-line like this: # pppd nodefaultroute noauth nobsdcomp nodetach debug :10.1.2.1 pty "ssh -t us...@re... slirp ppp" This is the suggested way of testing according to the Debian packagers. It works perfectly fine for me with most hosts, but I have compiled Slirp on a couple of SunOS systems where this just doesn't work... pppd and remote slirp are unable to communicate. I've also tried it in CSLIP and SLIP modes, to no avail. I think it's a problem with how SSH on the SunOS machines constructs the pseudo-terminal through which Slirp communicates, but I'm not entirely sure. So I'm wondering if anyone can point out the precise terminal requirements for it to work. Thanks! Dan Lenski |
|
From: Marc S. <el...@bu...> - 2008-12-04 22:39:16
|
On Thu, Dec 04, 2008 at 12:32:54PM +0000, Jens Theisen wrote: > Marc Singer wrote: >> While it is true that 10/8 is a network that you can use, it is seldom >> defined as such. A 10/8 network has 2^24 addressable nodes. You are >> defining a point to point network with two endpoints. A /30 is >> sufficient and allows you to use other addresses in the 10/8 address >> space as the need arises. If you assign 10/8 to an interface, it >> means that any 10/8 address is routed through that interface. >> >> The network used by the slirplink script is /28. It's written into >> the script. There are a couple of different addresses used, so I >> elected to give the network 14 distinct addresses. > > This has nothing to do with your script. slirplink uses the net address > only to define the routing, but the initial problem I had was that the > ppp interface didn't stay up (so the step before any routing issues > failed) but came down very short after it was build up - at that point I > didn't call route or ip route yet. I didn't specify any network address > or netmask and I don't do now, I just specified the remote ip address to > be 10.0.2.2 on the call of pppd. I can't see why that would make any > difference to whether the ppp tunnel stays open or not, but it obviously > does. Of course I'm happy to have it working, but in case you also know > why that fixed it, I'd like to hear it. :) It's been too long since I wrote slirplink to remember the ins and outs of the setup procedure. IIRC, you can enable some debugging to make it easier to determine why it misbehaves. I'm glad it's now working for you. Cheers |
|
From: Jens T. <jen...@gm...> - 2008-12-04 12:23:50
|
Marc Singer wrote: > While it is true that 10/8 is a network that you can use, it is seldom > defined as such. A 10/8 network has 2^24 addressable nodes. You are > defining a point to point network with two endpoints. A /30 is > sufficient and allows you to use other addresses in the 10/8 address > space as the need arises. If you assign 10/8 to an interface, it > means that any 10/8 address is routed through that interface. > > The network used by the slirplink script is /28. It's written into > the script. There are a couple of different addresses used, so I > elected to give the network 14 distinct addresses. This has nothing to do with your script. slirplink uses the net address only to define the routing, but the initial problem I had was that the ppp interface didn't stay up (so the step before any routing issues failed) but came down very short after it was build up - at that point I didn't call route or ip route yet. I didn't specify any network address or netmask and I don't do now, I just specified the remote ip address to be 10.0.2.2 on the call of pppd. I can't see why that would make any difference to whether the ppp tunnel stays open or not, but it obviously does. Of course I'm happy to have it working, but in case you also know why that fixed it, I'd like to hear it. :) Jens |
|
From: Marc S. <el...@bu...> - 2008-12-04 05:31:22
|
On Wed, Dec 03, 2008 at 08:16:28PM +0000, Jens Theisen wrote: > Marc Singer wrote: >>> I still don't quite understand in what way 10.0.2.15 and 10.64.64.64 >>> are "not on the same network" - what's the network address / netmask >>> here and why is this relevant? >> >> IIRC, the mask is /24 or /30. >> >> If this is mysterious to you, you may want to do some reading on CIDR >> (Classless Interdomain Routing) and on IP routing. > > I know about networking basics, but what is, in this particular > context, defining the domain of the network (ie. the network > address)? I specified neither /24 nor /30 anywere, so is this > hard-coded in slirp? Why's the default not /8, as you would expect > for 10.*? Is this documented somewhere? While it is true that 10/8 is a network that you can use, it is seldom defined as such. A 10/8 network has 2^24 addressable nodes. You are defining a point to point network with two endpoints. A /30 is sufficient and allows you to use other addresses in the 10/8 address space as the need arises. If you assign 10/8 to an interface, it means that any 10/8 address is routed through that interface. The network used by the slirplink script is /28. It's written into the script. There are a couple of different addresses used, so I elected to give the network 14 distinct addresses. |
|
From: Jens T. <jen...@gm...> - 2008-12-03 20:16:39
|
Marc Singer wrote: >> I still don't quite understand in what way 10.0.2.15 and 10.64.64.64 are >> "not on the same network" - what's the network address / netmask here >> and why is this relevant? > > IIRC, the mask is /24 or /30. > > If this is mysterious to you, you may want to do some reading on CIDR > (Classless Interdomain Routing) and on IP routing. I know about networking basics, but what is, in this particular context, defining the domain of the network (ie. the network address)? I specified neither /24 nor /30 anywere, so is this hard-coded in slirp? Why's the default not /8, as you would expect for 10.*? Is this documented somewhere? Jens |
|
From: Marc S. <el...@bu...> - 2008-11-30 21:45:47
|
On Mon, Nov 24, 2008 at 03:21:49PM +0000, Jens Theisen wrote: > Marc Singer wrote: >> It's been a reeeeally long time since I used this program. I wonder >> if the local/remote addressing is a problem in that they aren't on the >> same network. > > Yes, it works when given an explicit address like you do in your script. > > I still don't quite understand in what way 10.0.2.15 and 10.64.64.64 are > "not on the same network" - what's the network address / netmask here > and why is this relevant? IIRC, the mask is /24 or /30. If this is mysterious to you, you may want to do some reading on CIDR (Classless Interdomain Routing) and on IP routing. Cheers. |
|
From: <_v...@li...> - 2008-11-24 19:14:16
|
Rewrite of some other's broken slirp ping patch. Subshells "/bin/sh -c '/bin/ping $address -c 1'; echo $?", than forks and reads the output. Not stable in Cygwin. /* Don't crash every 3 pings only if slirp is compiled with DEBUG option and is logging to file with high verbosity */ |
|
From: Jens T. <jen...@gm...> - 2008-11-24 15:14:01
|
Marc Singer wrote: > It's been a reeeeally long time since I used this program. I wonder > if the local/remote addressing is a problem in that they aren't on the > same network. Yes, it works when given an explicit address like you do in your script. I still don't quite understand in what way 10.0.2.15 and 10.64.64.64 are "not on the same network" - what's the network address / netmask here and why is this relevant? Thank you very much for that tip. Jens |
|
From: Marc S. <el...@bu...> - 2008-11-22 02:07:31
|
On Fri, Nov 21, 2008 at 11:02:37PM +0000, Jens Theisen wrote: > Hello there, > > this is a simple user question I post here as there is no users list and > I don't know who else to ask. > > Short version: > > pppd noproxyarp updetach debug pty "slirp -P" > > seems to do a successful handshake and opens a new interface for an > instance, but then closes it immediately again. I can't figure out why. > > Long version: > > Really I want to do it to some remote machine, obviously. Given an > existing ssh tunnel on port 2000 (sshing through that works), I do: > > pppd noproxyarp updetach debug pty \ > "ssh -t -p 2000 jens@localhost slirp ppp" > > The connection is build up successfully, but directly after that (so > directly after pppd did fork and stop printing to stdout), I get through > logging: > > Nov 19 12:00:40 apollo pppd[21104]: Script /etc/ppp/ip-up started (pid > 21105) > Nov 19 12:00:40 apollo pppd[21104]: rcvd [IPCP TermReq id=0x3] > Nov 19 12:00:40 apollo pppd[21104]: IPCP terminated by peer > > The last thing before those entries are > > Nov 19 12:00:40 apollo pppd[21099]: local IP address 10.0.2.15 > Nov 19 12:00:40 apollo pppd[21099]: remote IP address 10.64.64.64 It's been a reeeeally long time since I used this program. I wonder if the local/remote addressing is a problem in that they aren't on the same network. I wrote a bit about this and produced a helper script. Perhaps it will help. http://wiki.buici.com/wiki/Slirp_Tunneled_over_SSH |
|
From: Jens T. <jen...@gm...> - 2008-11-21 23:02:48
|
Hello there, this is a simple user question I post here as there is no users list and I don't know who else to ask. Short version: pppd noproxyarp updetach debug pty "slirp -P" seems to do a successful handshake and opens a new interface for an instance, but then closes it immediately again. I can't figure out why. Long version: Really I want to do it to some remote machine, obviously. Given an existing ssh tunnel on port 2000 (sshing through that works), I do: pppd noproxyarp updetach debug pty \ "ssh -t -p 2000 jens@localhost slirp ppp" The connection is build up successfully, but directly after that (so directly after pppd did fork and stop printing to stdout), I get through logging: Nov 19 12:00:40 apollo pppd[21104]: Script /etc/ppp/ip-up started (pid 21105) Nov 19 12:00:40 apollo pppd[21104]: rcvd [IPCP TermReq id=0x3] Nov 19 12:00:40 apollo pppd[21104]: IPCP terminated by peer The last thing before those entries are Nov 19 12:00:40 apollo pppd[21099]: local IP address 10.0.2.15 Nov 19 12:00:40 apollo pppd[21099]: remote IP address 10.64.64.64 which were printed to stdout by pppd before the fork. On the server side running slirp, I only got the following in .slirp_start: IP address of Slirp host: 127.0.0.1 IP address of your DNS(s): [...] Your address is 10.0.2.15 (or anything else you want) Type five zeroes (0) to exit. [talking PPP, 115200 baud] SLiRP Ready ... End log. When called with debugppp, slirp prints the additional slirp_debugppp file, which unfortunately does not contain anything enlightening. One line says LCP terminated at peer's request indicating that the other site initiated the termination. Compiling with debugging and passing -d -1 indeed produces a slirp_debug file, but that contains only unreadable gibberish. :) I also tried not having run the ip-up script, but that doesn't make a difference either. I tried different machines, all running a recent ubuntu. slirp version 1.0.17, ppp version 2.4.4rel-9ubuntu2. Presumably I miss something obvious? Thank you in advance, Jens |
|
From: <_v...@li...> - 2008-05-31 14:37:20
|
The problem: It looks like Slirp's side of doing connection balancing works OK, but I don't know how to configure it's client side. (I use Linux). Single connection works well, but when I trying to use multiple connection, linux creates multiple interfaces ppp0, ppp1, ppp2, ..., Only to ppp0 packets are actually sent (where the routes point), and packets received ppp1, ppp2, ... are just dropped. So that adding additional ssh vi@server "slirp -l 1" unit almost stops the connection. I tried to specify multilink option to pppd, but it don't work. (Looks like slirp don't support CONFIG_PPP_MULTILINK's protocol). Logs: 1. Connection of initial slirp unit: vi-notebook:~/scripts# pppd 10.0.2.15:10.0.2.254 noauth nodetach debug unit 7 pty 'su -l vi -s /usr/bin/ssh "root@194.169.192.19" "/root/killslirp.sh; /root/bin/slirp -P \"redir 2222 10.0.2.15:22\" \"redir 2121 10.0.2.15:21\""' using channel 423 Using interface ppp7 Connect: ppp7 <--> /dev/pts/10 sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x2f90d47d> <pcomp> <accomp>] Slirp v1.0.17 (BETA) Copyright (c) 1995,1996 Danny Gasparovski and others. All rights reserved. This program is copyrighted, free software. Please read the file COPYRIGHT that came with the Slirp package for the terms and conditions of the copyright. Reading config file: /root/.slirprc-0 Reading config file: /root/.slirprc Setting host address to 194.169.192.19 Redirecting TCP port 2222 to 10.0.2.15:22 Redirecting TCP port 2121 to 10.0.2.15:21 IP address of Slirp host: 194.169.192.19 IP address of your DNS(s): 193.28.153.254 Your address is 10.0.2.15 (or anything else you want) Type five zeroes (0) to exit. [talking PPP, 115200 baud] SLiRP Ready ... rcvd [LCP ConfReq id=0x1 <mru 1500> <magic 0xf4ca1d5f> <pcomp> <accomp>] sent [LCP ConfAck id=0x1 <mru 1500> <magic 0xf4ca1d5f> <pcomp> <accomp>] rcvd [LCP ConfAck id=0x1 <asyncmap 0x0> <magic 0x2f90d47d> <pcomp> <accomp>] sent [LCP EchoReq id=0x0 magic=0x2f90d47d] sent [CCP ConfReq id=0x1 <deflate 15> <deflate(old#) 15> <bsd v1 15>] sent [IPCP ConfReq id=0x1 <compress VJ 0f 01> <addr 10.0.2.15>] rcvd [IPCP ConfReq id=0x1 <addr 194.169.192.19> <compress VJ 0f 01>] sent [IPCP ConfNak id=0x1 <addr 10.0.2.254>] rcvd [LCP EchoRep id=0x0 magic=0xf4ca1d5f] rcvd [CCP ConfReq id=0x1] sent [CCP ConfAck id=0x1] rcvd [CCP ConfRej id=0x1 <deflate 15> <deflate(old#) 15>] sent [CCP ConfReq id=0x2 <bsd v1 15>] rcvd [IPCP ConfAck id=0x1 <compress VJ 0f 01> <addr 10.0.2.15>] rcvd [IPCP ConfReq id=0x2 <addr 10.0.2.254> <compress VJ 0f 01>] sent [IPCP ConfAck id=0x2 <addr 10.0.2.254> <compress VJ 0f 01>] Cannot determine ethernet address for proxy ARP local IP address 10.0.2.15 remote IP address 10.0.2.254 Script /etc/ppp/ip-up started (pid 18011) rcvd [CCP ConfNak id=0x2 <bsd v1 14>] sent [CCP ConfReq id=0x3 <bsd v1 14>] rcvd [CCP ConfNak id=0x3 <bsd v1 13>] sent [CCP ConfReq id=0x4 <bsd v1 13>] rcvd [CCP ConfNak id=0x4 <bsd v1 12>] sent [CCP ConfReq id=0x5 <bsd v1 12>] rcvd [CCP ConfNak id=0x5 <bsd v1 11>] sent [CCP ConfReq id=0x6 <bsd v1 11>] rcvd [CCP ConfNak id=0x6 <bsd v1 10>] sent [CCP ConfReq id=0x7 <bsd v1 10>] Script /etc/ppp/ip-up finished (pid 18011), status = 0x0 rcvd [CCP ConfRej id=0x7 <bsd v1 10>] sent [CCP ConfReq id=0x8] rcvd [CCP ConfAck id=0x8] vi-notebook:~/scripts# route add default dev ppp7 Everything works right for now. Trying to add additional connections. vi-notebook:~/scripts# pppd 10.0.2.15:10.0.2.254 noauth nodetach debug pty 'su -l vi -s /usr/bin/ssh -- -t "root@194.169.192.19" "/root/bin/slirp -l 1"' using channel 429 Using interface ppp0 Connect: ppp0 <--> /dev/pts/20 sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x640e96c6> <pcomp> <accomp>] rcvd [LCP ConfReq id=0x1 <mru 1500> <magic 0x3963ff6b> <pcomp> <accomp>] sent [LCP ConfAck id=0x1 <mru 1500> <magic 0x3963ff6b> <pcomp> <accomp>] rcvd [LCP ConfAck id=0x1 <asyncmap 0x0> <magic 0x640e96c6> <pcomp> <accomp>] sent [LCP EchoReq id=0x0 magic=0x640e96c6] sent [CCP ConfReq id=0x1 <deflate 15> <deflate(old#) 15> <bsd v1 15>] sent [IPCP ConfReq id=0x1 <compress VJ 0f 01> <addr 10.0.2.15>] rcvd [LCP EchoRep id=0x0 magic=0x3963ff6b] rcvd [IPCP ConfReq id=0x1 <addr 194.169.192.19> <compress VJ 0f 01>] sent [IPCP ConfNak id=0x1 <addr 10.0.2.254>] rcvd [CCP ConfReq id=0x1] sent [CCP ConfAck id=0x1] rcvd [CCP ConfRej id=0x1 <deflate 15> <deflate(old#) 15> <bsd v1 15>] sent [CCP ConfReq id=0x2] rcvd [IPCP ConfAck id=0x1 <compress VJ 0f 01> <addr 10.0.2.15>] rcvd [IPCP ConfReq id=0x2 <addr 10.0.2.254> <compress VJ 0f 01>] sent [IPCP ConfAck id=0x2 <addr 10.0.2.254> <compress VJ 0f 01>] Cannot determine ethernet address for proxy ARP local IP address 10.0.2.15 remote IP address 10.0.2.254 Script /etc/ppp/ip-up started (pid 19014) rcvd [CCP ConfAck id=0x2] Script /etc/ppp/ip-up finished (pid 19014), status = 0x0 At that time ppp7 says: Opening device /dev/pts/18... Reading config file: /root/.slirprc-1 Opening device /dev/pts/7... Reading config file: /root/.slirprc-1 Additional interface ppp0 appeared. What to do with it? Ignore? Trying to test "boosted" connection. vi@vi-notebook:~$ wget http://www.google.de/ --2008-05-31 17:30:31-- http://www.google.de/ Resolving www.google.de... 66.249.91.99, 66.249.91.103, 66.249.91.104, ... Connecting to www.google.de|66.249.91.99|:80... connected. HTTP request sent, awaiting response... 200 OK Length: unspecified [text/html] Saving to: `index.html.3' [ <=> ] 2,252 512B/s Speed seriously decreased! ppp0 Link encap:Point-to-Point Protocol inet addr:10.0.2.15 P-t-P:10.0.2.254 Mask:255.255.255.255 UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1 RX packets:54 errors:4 dropped:0 overruns:0 frame:0 TX packets:6 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:3 RX bytes:19763 (19.2 KiB) TX bytes:65 (65.0 B) ppp7 Link encap:Point-to-Point Protocol inet addr:10.0.2.15 P-t-P:10.0.2.254 Mask:255.255.255.255 UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1 RX packets:117 errors:1 dropped:0 overruns:0 frame:0 TX packets:230 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:3 RX bytes:38390 (37.4 KiB) TX bytes:15959 (15.5 KiB) Killing offending part of link. vi-notebook:~# kill -INT `cat /var/run/ppp0.pid ` ppp0 says: Terminating on signal 2 Connect time 6.4 minutes. Sent 0 bytes, received 19692 bytes. Script /etc/ppp/ip-down started (pid 19445) sent [LCP TermReq id=0x2 "User request"] Script su -l vi -s /usr/bin/ssh -- -t "root@194.169.192.19" "/root/bin/slirp -l 1" finished (pid 19006), status = 0x82 Modem hangup Connection terminated. Waiting for 1 child processes... script /etc/ppp/ip-down, pid 19445 Script /etc/ppp/ip-down finished (pid 19445), status = 0x0 ppp7 says: rcvd [IPCP TermReq id=0x3] IPCP terminated by peer Connect time 18.9 minutes. Sent 17051 bytes, received 38886 bytes. Script /etc/ppp/ip-down started (pid 19462) sent [IPCP TermAck id=0x3] rcvd [CCP TermReq id=0x2] CCP terminated by peer sent [CCP TermAck id=0x2] Compression disabled by peer. Script /etc/ppp/ip-down finished (pid 19462), status = 0x0 sent [LCP TermReq id=0x2 "No network protocols running"] rcvd [LCP TermAck id=0x2] Connection terminated. Waiting for 1 child processes... script su -l vi -s /usr/bin/ssh "root@194.169.192.19" "/root/killslirp.sh; /root/bin/slirp -P \"redir 2222 10.0.2.15:22\" \"redir 2121 10.0.2.15:21\"", pid 17999 sending SIGTERM to process 17999 vi-notebook:~/scripts# Session terminated, killing shell... ...killed. Connection died. What to do? Background: I use slirp over SSH to route my traffic through the remote VPS. (Behind NAT). Everything works fine, but ISP (University) limits each TCP connection to about 3 kb/s - 30 kb/s (depending on load). Due to misconfiguration of NAT, bandwidth is divided between _connections_, no between hosts, so many students download their files in 30 and more threads to gain higher bandwidth. So in internet-active time, by single SSH/Slirp-connection becomes throttled by hundreds of others' threads and in internet-free time my connection allocates only small part of available bandwidth. |
11 messages has been excluded from this view by a project administrator.
