Re: PLEASE HEEEEEELLLLPPPP ME...
Hi Your problem is that the ports you have allowed are not the only ports FTP uses. FTP makes use of two separate TCP connections. The first is the command connection ( 21/tcp) which is the connection used for logging in , and issuing commands. However when you make a data connection ( retrieving a file, listing a directory) a data connection is opened up. Traditionally , port 20/tcp ( ftp-data) was used. The process being that the server opened a connection to your client machine from port 20. This clearly has issues when combined with firewalls and NAT. The other FTP transfer mode is Passive mode. Here, a data request is made, and the server provides details of what port the client should connect to. The problem you are seeing is because you are not natting all the possible ports through. The best suggestion I have is to install something like jftpgw which will run on your firewall/gateway and act as a FTP proxy back to the FTP server. Regards, Barry - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, July 23, 2003 1:51 PM Subject: PLEASE HEE ME... please HELP !!! Ok... here is my problem that I tried to explain completly ! The situation is the one below: = |SpeedToucheHome Ethernet ADSL Modem| |10.0.0.138/24 | = | 10.0.0.0/24 | == | 10.0.0.1/24 | | (A) 10.1.0.254/24 |- 10.1.0.0/24 - (... DMZ ...) | 192.168.1.254/24| == | 192.168.1.0/24 | ... clients workstations My problem is about the computer A which does not what I would like It does. Currently, this computer has a customized kernel with thoses options: IPFIREWALL IPDIVERT but not IPFILTER !!! maybe it is the problem, I don't know ! in the rc.conf, I made the following configuration firewall_enabled=YES firewall_type=SIMPLE (but I tried too with OPEN) natd_enable=YES natd_interface=tun0 (this is the interface for PPPoE, I think) natd_flags=-f /etc/natd.conf ... and in natd.conf: dynamic interface tun0 redirect_port tcp 10.1.0.1:20-21 20-21 10.1.0.1 is the IP address from my FTP server which is a computer placed in the DMZ. My problem is: from outside, I cannot access to the FTP server... What I can say is: First: My FTP server is OK because from inside, I can access to it from any computer in DMZ or from clients workstations. Secund: The answer to an outside request is connection closed by host. Third: Interface tun0 (the virtual interface for PPPoE) receives the ftp request but does not forward them to ed1 (the outside netcard from A and configured with 10.0.0.1). (I discoverd that with tcpdump). (the others interfaces get no more ftp packets from tun0)... So, what can I do to solve this problem... Thank you Sylvain. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: NAT and PPTP
Julian Elischer wrote: However I do suggest that you discuss the possibility of enhancing mpd with archie to allow allocation of addresses from a pool. I seem to recall (I could be mistaken here) that Archie has been working with a company that does Wi-Fi access points with PPTP. If these use mpd, they must have a workaround for the limitation. So, the code may already exist. IIRC, Archive said that this was a complete (both from scratch and proprietary) implementation of an MPD-like system. That's correct.. the code is not released. I'll ask about it again (but don't keep your hopes up). if that fails, how much would it take to allow mpd to use a pool of addresses? It wouldn't be too hard but would require some major surgery to mpd... but it could use some :-) -Archie A potential feature that could be really cool would be adding dhcpclient/relaying code so that the IP addresses could be queried from a dhcp server. I've seen several commercial implementations of this - but me != good coder :o) - Sten ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
splx() bug in ip_dummynet?
1.24.2.2 of ip_dummynet.c [RELENG_4] has a bug I'm thinking, can someone
comment?
In the below snippet, the value of 's' from splimp() is
overwritten by the return value of alloc_hash(), which is
an errno. If its != 0, then there's a missing splx().
If it is == 0, then splx() is called with the wrong value.
[i've filed a PR against this, and will probably change
the alloc_hash to use a different return value in my tree]
s = splimp();
x-bandwidth = p-bandwidth ;
x-numbytes = 0; /* just in case... */
bcopy(p-if_name, x-if_name, sizeof(p-if_name) );
x-ifp = NULL ; /* reset interface ptr */
x-delay = p-delay ;
set_fs_parms((x-fs), pfs);
if ( x-fs.rq == NULL ) { /* a new pipe */
s = alloc_hash((x-fs), pfs) ;
if (s) {
free(x, M_DUMMYNET);
return s ;
}
x-next = b ;
if (a == NULL)
all_pipes = x ;
else
a-next = x ;
}
splx(s);
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: splx() bug in ip_dummynet?
From: Don Bowman [mailto:[EMAIL PROTECTED]
...
I believe this patch will correct the issue.
Index: ip_dummynet.c
===
RCS file: /usr/cvs/src/sys/netinet/ip_dummynet.c,v
retrieving revision 1.24.2.17.1000.1
retrieving revision 1.24.2.17.1000.2
diff -U3 -r1.24.2.17.1000.1 -r1.24.2.17.1000.2
--- ip_dummynet.c 21 Jun 2003 20:47:59 - 1.24.2.17.1000.1
+++ ip_dummynet.c 24 Jul 2003 15:27:59 - 1.24.2.17.1000.2
@@ -1571,10 +1571,12 @@
if ( x-fs.rq == NULL ) { /* a new pipe */
- s = alloc_hash((x-fs), pfs) ;
- if (s) {
+ int s1;
+ s1 = alloc_hash((x-fs), pfs) ;
+ if (s1) {
free(x, M_DUMMYNET);
- return s ;
+ splx(s);
+ return s1 ;
}
x-next = b ;
if (a == NULL)
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Netgraph, meta and socket PF_NG
you are correct My plan was to use the metadata part of recvmesg() to transfer metadata but never implemented it and it has not been needed. I suggest that you write a very simple node (start with ng_sample.c) that converts metadata to a 'header' prepends it to the data and then pass that up. Alternatively you could look at implementing the recvmesg() metadata transfer. On Thu, 24 Jul 2003, Vincent Jardin wrote: With the regular data, I would like to send an opaque data from a netgraph node to a userland program that has a NG_DATA/PF_NETGRAPH socket. This opaque data is the meta. How can it be performed ? Then, from the userland program, how to send data with an opaque to a NG_DATA/PF_NG socket ? Then this opaque would be a netgraph's meta. It seems that ng_socket does not support this feature, however I am not sure that I understand properly its source code. ;-( Thanks, Vincent ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Netgraph, meta and socket PF_NG
Le Jeudi 24 Juillet 2003 20:26, Julian Elischer a écrit : you are correct My plan was to use the metadata part of recvmesg() to transfer metadata but never implemented it and it has not been needed. I suggest that you write a very simple node (start with ng_sample.c) that converts metadata to a 'header' prepends it to the data and then pass that up. I though about it, however I would like to avoid this case that is not enough generic. Alternatively you could look at implementing the recvmesg() metadata transfer. However I am not a Unix socket expert ;-( I'll look how it can be done. Thanks, Vincent ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Samba: Marginal performance pauses in transfers
Hello everybody, I have a FreeBSD 4.8-STABLE server running Samba 2.2.8a and a workstation running Windows 2000 SP4. Whereas FTP transfers between these boxes average 700 KB/s (10 mbps LAN), Samba transfers are never beyond ~120 KB/s. Trust me, I have tried *everything* I've run into as far as tuning goes, but this is a different problem. The main problem lies in the fact that transfers are not consistent and undergo VERY long, random pauses. My hub's activity LED shows that, during a Samba transfer between these two boxes, no packets are transferred about 70% of the time. Yep, only during about 30% of the total time a transfer takes there is actual network activity--the remaining 70% of the time is taken up by random (both length- and interval-wise) pauses. All my network cards are propery configured, both media- and duplex- wise. There are nearly no collissions, and the 700 KB/s rate I can achieve in FTP transfers shows that Samba has the problem. I can do SMB transfers between the Windows 2000 box and another Windows 98 box at about 600 KB/s, so the culprit is obviously Samba on the FreeBSD box. Because most of the time a transfer takes to complete is wasted on those random pauses, anything I could tune concerning buffer sizes and the like is almost useless because it only takes effect while data is actually being transferred, not during the pauses. I have fiddled with buffer sizes and, by looking at the hub's activity light, I could (visually and easily) see how more or less data was transferred in between the pauses depending on the buffer sizes I chose. However, the pauses stayed consistent throughout all my tests. By using larger buffer sizes, all I could do was push more data through in between the pauses, but my tuning never affected the length or interval of the pauses themselves. Does anyone happen to know what could be causing this problem? Cheers, Nicolas Gieczewski Nix Software Solutions http://www.nixsoftware.com/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Update on nVidia/MCP ethernet
First off, response to my announcement has been amazing. I've received 150 e-mails so far, and they're still coming. Thanks to everyone who has responded. An extra special thanks to those people who agreed to talk to contacts they have within nVidia. I'm still waiting for for info from these people. As soon as I learn something new, I'll pass it along. I have also made some progress on another front. It occured to me that since nVidia is known for GPU expertise rather than networking expertise that maybe their 'proprietary design' wasn't really anything of the sort. Well, I was right: what nVidia calls MCP ethernet is really a Conexant CX25870/1 jedi controller. I have contacted Conexant and am in the process of trying to obtain a copy of the programming manual for this device. There are some NDA issues to deal with, however I've been told they will not prevent me from releasing driver source. I hope to get this resolved soon. Stay tuned. -Bill -- = -Bill Paul(510) 749-2329 | Senior Engineer, Master of Unix-Fu [EMAIL PROTECTED] | Wind River Systems = If stupidity were a handicap, you'd have the best parking spot. = ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Profiling ipfw2 performance
On Thu, Jul 24, 2003 at 06:03:25PM -0400, Eric W. Bates wrote: Can someone please point me to a method for measuring the packet lag between interfaces when using ipfw and/or ipfw2? in RELENG_4, i386 kernels you can add the option options KERN_TIMESTAMP which then allows you to use the TSTMP() macros (defined and documented in /sys/i386/include/param.h) to record timestamps using the TSC register, and export the readings to userland using a sysctl. This way you can get some reasonable numbers in a non-intrusive way. cheers luigi Thanks. Eric W. Bates [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PLEASE HEEEEEELLLLPPPP ME...
Or, switch to using IPFILTER/IPNAT which has special features to handle the case of FTP. MAtt Your problem is that the ports you have allowed are not the only ports FTP uses. FTP makes use of two separate TCP connections. The first is the command connection ( 21/tcp) which is the connection used for logging in , and issuing commands. However when you make a data connection ( retrieving a file, listing a directory) a data connection is opened up. Traditionally , port 20/tcp ( ftp-data) was used. The process being that the server opened a connection to your client machine from port 20. This clearly has issues when combined with firewalls and NAT. The other FTP transfer mode is Passive mode. Here, a data request is made, and the server provides details of what port the client should connect to. The problem you are seeing is because you are not natting all the possible ports through. The best suggestion I have is to install something like jftpgw which will run on your firewall/gateway and act as a FTP proxy back to the FTP server. Regards, Barry - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, July 23, 2003 1:51 PM Subject: PLEASE HEE ME... please HELP !!! Ok... here is my problem that I tried to explain completly ! The situation is the one below: = |SpeedToucheHome Ethernet ADSL Modem| |10.0.0.138/24 | = | 10.0.0.0/24 | == | 10.0.0.1/24 | | (A) 10.1.0.254/24 |- 10.1.0.0/24 - (... DMZ ...) | 192.168.1.254/24| == | 192.168.1.0/24 | ... clients workstations My problem is about the computer A which does not what I would like It does. Currently, this computer has a customized kernel with thoses options: IPFIREWALL IPDIVERT but not IPFILTER !!! maybe it is the problem, I don't know ! in the rc.conf, I made the following configuration firewall_enabled=YES firewall_type=SIMPLE (but I tried too with OPEN) natd_enable=YES natd_interface=tun0 (this is the interface for PPPoE, I think) natd_flags=-f /etc/natd.conf ... and in natd.conf: dynamic interface tun0 redirect_port tcp 10.1.0.1:20-21 20-21 10.1.0.1 is the IP address from my FTP server which is a computer placed in the DMZ. My problem is: from outside, I cannot access to the FTP server... What I can say is: First: My FTP server is OK because from inside, I can access to it from any computer in DMZ or from clients workstations. Secund: The answer to an outside request is connection closed by host. Third: Interface tun0 (the virtual interface for PPPoE) receives the ftp request but does not forward them to ed1 (the outside netcard from A and configured with 10.0.0.1). (I discoverd that with tcpdump). (the others interfaces get no more ftp packets from tun0)... So, what can I do to solve this problem... Thank you Sylvain. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NAT and PPTP
Brett Glass wrote: I'd like to, but to be truthful I don't have much time to spare these days... Would it be possible for you to spend just a few hours on converting code from mpd's pptp_ctrl.c and pptp.c into the basis of the daemon? The daemon would need to accept incoming calls only (which means the code for outgoing calls could be scrubbed), dispatch GRE packets into pipes to instances of ppp -direct label (which would be created as needed), and send data received from those processes out over GRE, adding the correct call ID for that instance. I don't have time to do any real work.. however, the PPTP control layer can be used pretty much as is.. i.e., the files pptp_ctrl.[ch]. It has a fairly clean API that any PPP daemon could use, and all they require is some kind of event support. -Archie __ Archie Cobbs *Halloo Communications* http://www.halloo.com ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NAT and PPTP
At 08:50 PM 7/24/2003, Archie Cobbs wrote: I don't have time to do any real work.. however, the PPTP control layer can be used pretty much as is.. i.e., the files pptp_ctrl.[ch]. It has a fairly clean API that any PPP daemon could use, and all they require is some kind of event support. We wouldn't be doing it quite that way; we'd be using it just to steer the call through PPP (which wouldn't know that it was PPTP; it would just think the call was PPP with MPPE on the CCP layer). So, the PPP implementation wouldn't need to know about PPTP call control. --Brett ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Update on nVidia/MCP ethernet
On Thursday 24 July 2003 06:57 pm, Bill Paul wrote: I have also made some progress on another front. It occured to me that since nVidia is known for GPU expertise rather than networking expertise that maybe their 'proprietary design' wasn't really anything of the sort. Well, I was right: what nVidia calls MCP ethernet is really a Conexant CX25870/1 jedi controller. I have contacted Conexant and am in the process of trying to obtain a copy of the programming manual for this device. There are some NDA issues to deal with, however I've been told they will not prevent me from releasing driver source. AFAIK, CX25870/1 is a video encoder. http://www.conexant.com/products/entry.jsp?id=278 Jung-uk Kim ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
