Re: iSCSI Target For Freebsd
09.03.2012 04:30, David Somayajulu пишет: Hi All, Is there are an iSCSI Software Target that you can recommend. I have tried using istgt ( on Freebsd7.2) with Windows iSCSI Software Initiator. The initiator is able to discover the target however it is unable to login to the target. net/iscsi-target is in ports and seems to be working one. some times use it with windows initiator and all is ok. The login Response shows that thestatus class, status detail =0203 indicating that the requested ITN does not exist at this address Thanks David S. This message and any attached documents contain information from QLogic Corporation or its wholly-owned subsidiaries that may be confidential. If you are not the intended recipient, you may not read, copy, distribute, or use this information. If you have received this transmission in error, please notify the sender immediately by reply e-mail and then delete this message. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org -- Sincerely yours, Artyom Viklenko. --- ar...@aws-net.org.ua | http://www.aws-net.org.ua/~artem ar...@viklenko.net | FreeBSD: The Power to Serve - http://www.freebsd.org ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: RESOLVED: Re: 8.1 Box does not react on ICMP unreachable - need to frag
18.01.2011 14:23, Axel Rau пишет: Am 18.01.2011 um 11:00 schrieb Axel Rau: The DB server returns its query results successfully until an oversized message is being sent (with DF set), which the GW2 refuses with an ICMP unreachable - need to frag (mtu 1492) I could convince the firewall to defragment the packet itself. (-; This was a pf issue (I mixed up option set reassemble and filteropt fragment). I'm still looking for an answer to question 1: 1. Shouldn't DB2 fragment and resend the packet? Generally - yes. Make sure DB2 got ICMP need-frag message and it not blocked. Also, check sysctl variable 'net.inet.tcp.path_mtu_discovery'. Hope this helps. :) -- Sincerely yours, Artyom Viklenko. --- ar...@aws-net.org.ua | http://www.aws-net.org.ua/~artem ar...@viklenko.net | JID: ar...@jabber.aws-net.org.ua FreeBSD: The Power to Serve - http://www.freebsd.org ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: Juniper e3k with ports limitied to 100Mbit and re NICs on MSI MoBo: problems with duplex negotiation (Hetzner host provider discard FreeBSD support due this bug)
11.01.2011 21:29, Lev Serebryakov пишет: Hello, Brian. You wrote 11 января 2011 г., 19:38:25: Very large and famous (due to very attractive prices) hosting provider Hetzner.de discards FreeBSD support on dedicated servers, because these servers can niot negotiate 100Mbit/DUPLEX when switches' ports are limited to 100Mbit (1Gbit connection costs additional money) only under FreeBSD. Linux works fine. How are the switches being forced to 100/full? I don't know, I never work with Juniper e3k switches (And any other Juniper products at all). All I know, that older Juniper Switches in not-so-new DCs of same provider doesn't have this problem, and, on other hand, Linux and Windows 2008 don't have problems with new ones too. If they're doing so by disabling autonegotiation, then that's where some grief may come from. Linux work with autonegotiation, as I can see (It is outpuit from Rescue Linux system on SAME my server, where FreeBSD shows half-duplex even if forced to full-duplex): r...@rescue ~ # mii-tool -v eth0 eth0: 100 Mbit, full duplex, link ok product info: vendor 00:07:32, model 17 rev 2 basic mode: 100 Mbit, full duplex basic status: link ok capabilities: 1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD advertising: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control link partner: 100baseTx-HD ^ Looks very strange for me... 'HD' means half-duplex? May be linux driver defaults to full-duplex if autoneg fails?.. r...@rescue ~ # ethtool eth0 Settings for eth0: Supported ports: [ TP MII ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Half 1000baseT/Full Supports auto-negotiation: Yes Advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Half 1000baseT/Full Advertised auto-negotiation: No Speed: 100Mb/s Duplex: Full Port: MII PHYAD: 0 Transceiver: internal Auto-negotiation: off Supports Wake-on: pumbg Wake-on: g Current message level: 0x0033 (51) Link detected: yes r...@rescue ~ # So, it seems, that autonegotiation is disabled, but it works for Linux, and manual setting of media and mediaopt doesn't help FreeBSD. Also, please note, that when port is in 1Gib mode (which can be buyed for additional money, which I can not afford) FreeBSD works fine. -- Sincerely yours, Artyom Viklenko. --- ar...@aws-net.org.ua | http://www.aws-net.org.ua/~artem ar...@viklenko.net | JID: ar...@jabber.aws-net.org.ua FreeBSD: The Power to Serve - http://www.freebsd.org ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: Juniper e3k with ports limitied to 100Mbit and re NICs on MSI MoBo: problems with duplex negotiation (Hetzner host provider discard FreeBSD support due this bug)
11.01.2011 21:48, Bjoern A. Zeeb пишет: On Tue, 11 Jan 2011, Artyom Viklenko wrote: 11.01.2011 21:29, Lev Serebryakov ?: r...@rescue ~ # mii-tool -v eth0 eth0: 100 Mbit, full duplex, link ok product info: vendor 00:07:32, model 17 rev 2 basic mode: 100 Mbit, full duplex basic status: link ok capabilities: 1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD advertising: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control link partner: 100baseTx-HD ^ Looks very strange for me... 'HD' means half-duplex? May be linux driver defaults to full-duplex if autoneg fails?.. That's probably just because it cannot tell what the peer really uses (autoneg disabled) and prints the sane fall-back but I don't know the code. Is it possible to see status from corresponding port on Juniper switch? Config part for this port on the switch would be also very interesting. -- Sincerely yours, Artyom Viklenko. --- ar...@aws-net.org.ua | http://www.aws-net.org.ua/~artem ar...@viklenko.net | JID: ar...@jabber.aws-net.org.ua FreeBSD: The Power to Serve - http://www.freebsd.org ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: IPFW firewall NAT and active FTP
12.01.2011 01:06, Brett Glass пишет: I'm working with a customer who has a FreeBSD 8.0 firewall, set up with firewall NAT in IPFW. It uses one-to-one static NAT to redirect FTP sessions originating on the outside to an FTP server on the inside. The FTP server is accessible via text-based FTP clients, but not via Web-based clients such as Mozilla Firefox or Internet Explorer. The internal FTP server is also a FreeBSD machine. Does FTP server enforces any limits for sessions per ip? In past I saw that IE can open up to four concurrent sessions. If plain text ftp clients works, IMHO it's not a NAT problem. Also check config of ipfw is it supports both active and passive FTP transfers. He's wondering if the problem has to do with the lack of a firewall punching setting (which exists in natd but not in IPFW's built-in NAT). Can anyone suggest what might be causing the problem? --Brett Glass ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org -- Sincerely yours, Artyom Viklenko. --- ar...@aws-net.org.ua | http://www.aws-net.org.ua/~artem ar...@viklenko.net | JID: ar...@jabber.aws-net.org.ua FreeBSD: The Power to Serve - http://www.freebsd.org ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: Error: em0: Watchdog timeout -- resetting
26.08.2010 00:38, Vladislav V. Prodan пишет:
Add to /etc/rc.local :
ifconfig em0 debug
ifconfig em0 media 100baseTX mediaopt full-duplex
For in rc.conf not working these options:
#ifconfig_em0=100baseTX mediaopt full-duplex
#ifconfig_em0=debug -vlanmtu -vlanhwtag -vlanhwfilter -vlanhwtso -wol
Try
ifconfig_em0=100baseTX mediaopt full-duplex
ifconfig_em0_alias0=debug -vlanmtu -vlanhwtag -vlanhwfilter -vlanhwtso
-wol
Now the network card looks like this:
# ifconfig em0 | grep -v inet
em0: flags=8847UP,BROADCAST,DEBUG,RUNNING,SIMPLEX,MULTICAST metric 0
mtu 1500
options=219bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4,WOL_MAGIC
ether 00:25:90:05:83:7a
nd6 options=29PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL
media: Ethernet 100baseTXfull-duplex
status: active
25.08.2010 0:57, Vladislav V. Prodan wrote:
The server is sometimes off the network card.
It helps just to restart via KVM-IPMI.
MotherBoard: X8SIL/X8SIL-F
BIOS Version: 1.0c
Build Date: 02/05/10
OS: FreeBSD 8.1-RELEASE, FreeBSD 8.1-STABLE, FreeBSD 9.0-CURRENT
What would you recommend to address the problem?
# uname -a
FreeBSD solo.XXX.biz 9.0-CURRENT FreeBSD 9.0-CURRENT #0: Tue Aug 24
15:52:21 EEST 2010 r...@solo.xxx.biz:/usr/obj/usr/src/sys/solo.2 amd64
#pciconf -lv
...
e...@pci0:2:0:0: class=0x02 card=0x060515d9 chip=0x10d38086 rev=0x00
hdr=0x00
vendor = 'Intel Corporation'
device = 'Intel 82574L Gigabit Ethernet Controller (82574L)'
class = network
subclass = ethernet
e...@pci0:3:0:0: class=0x02 card=0x060515d9 chip=0x10d38086 rev=0x00
hdr=0x00
vendor = 'Intel Corporation'
device = 'Intel 82574L Gigabit Ethernet Controller (82574L)'
class = network
subclass = ethernet
...
In /usr/src/sys/dev/e1000/if_em.c:
static void
em_local_timer(void *arg)
{
struct adapter *adapter = arg;
struct ifnet*ifp = adapter-ifp;
struct tx_ring *txr = adapter-tx_rings;
EM_CORE_LOCK_ASSERT(adapter);
em_update_link_status(adapter);
em_update_stats_counters(adapter);
/* Reset LAA into RAR[0] on 82571 */
if (e1000_get_laa_state_82571(adapter-hw) == TRUE)
e1000_rar_set(adapter-hw, adapter-hw.mac.addr, 0);
/*
** Check for time since any descriptor was cleaned
*/
for (int i = 0; i adapter-num_queues; i++, txr++) {
EM_TX_LOCK(txr);
if (txr-watchdog_check == FALSE) {
EM_TX_UNLOCK(txr);
continue;
}
if ((ticks - txr-watchdog_time) EM_WATCHDOG)
goto hung;
EM_TX_UNLOCK(txr);
}
callout_reset(adapter-timer, hz, em_local_timer, adapter);
return;
hung:
device_printf(adapter-dev, Watchdog timeout -- resetting\n);
ifp-if_drv_flags= ~IFF_DRV_RUNNING;
adapter-watchdog_events++;
EM_TX_UNLOCK(txr);
em_init_locked(adapter);
}
Someone will finish the piece for debugging, to further diagnose the error?
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
--
Sincerely yours,
Artyom Viklenko.
---
ar...@aws-net.org.ua | http://www.aws-net.org.ua/~artem
ar...@viklenko.net |
FreeBSD: The Power to Serve - http://www.freebsd.org
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: Error: em0: Watchdog timeout -- resetting
26.08.2010 08:19, Artyom Viklenko пишет:
26.08.2010 00:38, Vladislav V. Prodan пишет:
Add to /etc/rc.local :
ifconfig em0 debug
ifconfig em0 media 100baseTX mediaopt full-duplex
For in rc.conf not working these options:
#ifconfig_em0=100baseTX mediaopt full-duplex
#ifconfig_em0=debug -vlanmtu -vlanhwtag -vlanhwfilter -vlanhwtso -wol
Try
ifconfig_em0=100baseTX mediaopt full-duplex
ifconfig_em0_alias0=debug -vlanmtu -vlanhwtag -vlanhwfilter -vlanhwtso
-wol
Sorry, correct myself
ifconfig_em0=media 100baseTX mediaopt full-duplex
ifconfig_em0_alias0=debug -vlanmtu -vlanhwtag -vlanhwfilter -vlanhwtso
-wol
Now the network card looks like this:
# ifconfig em0 | grep -v inet
em0: flags=8847UP,BROADCAST,DEBUG,RUNNING,SIMPLEX,MULTICAST metric 0
mtu 1500
options=219bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4,WOL_MAGIC
ether 00:25:90:05:83:7a
nd6 options=29PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL
media: Ethernet 100baseTXfull-duplex
status: active
25.08.2010 0:57, Vladislav V. Prodan wrote:
The server is sometimes off the network card.
It helps just to restart via KVM-IPMI.
MotherBoard: X8SIL/X8SIL-F
BIOS Version: 1.0c
Build Date: 02/05/10
OS: FreeBSD 8.1-RELEASE, FreeBSD 8.1-STABLE, FreeBSD 9.0-CURRENT
What would you recommend to address the problem?
# uname -a
FreeBSD solo.XXX.biz 9.0-CURRENT FreeBSD 9.0-CURRENT #0: Tue Aug 24
15:52:21 EEST 2010 r...@solo.xxx.biz:/usr/obj/usr/src/sys/solo.2 amd64
#pciconf -lv
...
e...@pci0:2:0:0: class=0x02 card=0x060515d9 chip=0x10d38086 rev=0x00
hdr=0x00
vendor = 'Intel Corporation'
device = 'Intel 82574L Gigabit Ethernet Controller (82574L)'
class = network
subclass = ethernet
e...@pci0:3:0:0: class=0x02 card=0x060515d9 chip=0x10d38086 rev=0x00
hdr=0x00
vendor = 'Intel Corporation'
device = 'Intel 82574L Gigabit Ethernet Controller (82574L)'
class = network
subclass = ethernet
...
In /usr/src/sys/dev/e1000/if_em.c:
static void
em_local_timer(void *arg)
{
struct adapter *adapter = arg;
struct ifnet *ifp = adapter-ifp;
struct tx_ring *txr = adapter-tx_rings;
EM_CORE_LOCK_ASSERT(adapter);
em_update_link_status(adapter);
em_update_stats_counters(adapter);
/* Reset LAA into RAR[0] on 82571 */
if (e1000_get_laa_state_82571(adapter-hw) == TRUE)
e1000_rar_set(adapter-hw, adapter-hw.mac.addr, 0);
/*
** Check for time since any descriptor was cleaned
*/
for (int i = 0; i adapter-num_queues; i++, txr++) {
EM_TX_LOCK(txr);
if (txr-watchdog_check == FALSE) {
EM_TX_UNLOCK(txr);
continue;
}
if ((ticks - txr-watchdog_time) EM_WATCHDOG)
goto hung;
EM_TX_UNLOCK(txr);
}
callout_reset(adapter-timer, hz, em_local_timer, adapter);
return;
hung:
device_printf(adapter-dev, Watchdog timeout -- resetting\n);
ifp-if_drv_flags= ~IFF_DRV_RUNNING;
adapter-watchdog_events++;
EM_TX_UNLOCK(txr);
em_init_locked(adapter);
}
Someone will finish the piece for debugging, to further diagnose the
error?
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
--
Sincerely yours,
Artyom Viklenko.
---
ar...@aws-net.org.ua | http://www.aws-net.org.ua/~artem
ar...@viklenko.net |
FreeBSD: The Power to Serve - http://www.freebsd.org
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: problem with pptp, using mpd
Mathieu L. wrote: Hello, I am having trouble using mpd, I want to connect to a vpn with pptp (vpn service provided by relakks.com). Here is my configuration: mpd.conf: # default: load relakks relakks: create bundle static B1 set iface route default set ipcp ranges 0.0.0.0/0 0.0.0.0/0 # Enable Microsoft Point-to-Point encryption (MPPE) set bundle enable compression set ccp yes mppc set mppc yes e128 set bundle enable crypt-reqd set mppc yes stateless create link static L1 pptp set link action bundle B1 # Enable both sides to authenticat each other with CHAP set auth disable internal set auth authname lejatorn set auth password set link no pap set link no eap set link yes chap set link mtu 1460 set link keep-alive 10 75 set link max-redial 0 # Configure PPTP and open link set pptp peer pptp.relakks.com set pptp disable windowing set link enable incoming open try to add these: set auth authname your-host-name set link enable no-orig-auth -- Sincerely yours, Artyom Viklenko. --- ar...@aws-net.org.ua | http://www.aws-net.org.ua/~artem FreeBSD: The Power to Serve - http://www.freebsd.org ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: A more pliable firewall
On Thu, 19 Feb 2009, Bakul Shah wrote: I am wondering if there is a more dynamic and scriptable firewall program. The idea is to send it alerts (with sender host address) whenever a dns probe fails or ssh login fails or smtpd finds it has been fed spam or your website is fed bad urls. This program will then update the firewall after a certain number of attempts have been made from a host within a given period. Right now, when I find bad guys blasting packets at me, I add a rule to pf.conf to drop all packets from these hosts but Actually, you can use tables and add these ip-s to tables while leave pf.conf untouchable. The only thing to resolv is to write some daemon which will receive notifyes and update pf tables. It should be not so hard to write such piece of software. all this manual editing is getting old and the internet is getting more and more like the Wild West crossed with the Attack of the Zombies. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org -- Sincerely yours, Artyom Viklenko. --- ar...@aws-net.org.ua | http://www.aws-net.org.ua/~artem FreeBSD: The Power to Serve - http://www.freebsd.org ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: A more pliable firewall
On Friday 20 February 2009 15:30:11 Max Laier wrote: On Friday 20 February 2009 09:28:49 Artyom Viklenko wrote: On Thu, 19 Feb 2009, Bakul Shah wrote: I am wondering if there is a more dynamic and scriptable firewall program. The idea is to send it alerts (with sender host address) whenever a dns probe fails or ssh login fails or smtpd finds it has been fed spam or your website is fed bad urls. This program will then update the firewall after a certain number of attempts have been made from a host within a given period. Right now, when I find bad guys blasting packets at me, I add a rule to pf.conf to drop all packets from these hosts but Actually, you can use tables and add these ip-s to tables while leave pf.conf untouchable. The only thing to resolv is to write some daemon which will receive notifyes and update pf tables. It should be not so hard to write such piece of software. /usr/ports/net-mgmt/pftabled] cat pkg-descr The pftabled daemon is a small helper to make your pf tables reachable from other hosts. You can add/delete/flush IP addresses to/from a remote table with a single UDP datagram. A simple client program is included to do this from the command line. WWW:http://wolfermann.org/pftabled.html Wonderful! Thanks a lot! :) all this manual editing is getting old and the internet is getting more and more like the Wild West crossed with the Attack of the Zombies. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org -- Sincerely yours, Artyom Viklenko. --- ar...@aws-net.org.ua | http://www.aws-net.org.ua/~artem ar...@viklenko.net | FreeBSD: The Power to Serve - http://www.freebsd.org ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: FD_SETSIZE (too many open file descriptors) + BIND
Ott Köstner пишет: JINMEI Tatuya / 神明達哉 wrote: At Wed, 17 Dec 2008 15:20:02 +0200, Ott Köstner o...@zzz.ee wrote: named[63198]: socket: too many open file descriptors last message repeated 26 times Bind version is: BIND 9.4.2-P2 Please try BIND 9.4.3. Even with all attempts to mitigate the trouble and with tweaking parameters, 9.4.2-P2 still has a fundamental limitation on performance. It should work for the vast majority of users, but you really need 9.4.3 if your server is very busy. --- JINMEI, Tatuya Internet Systems Consortium, Inc. Thank You for your advice. Unfortunatelly there is no FreeBSD port of BIND 9.4.3 available at the moment. Hope this will appear soon... BIND 9.5.0-P2 already in ports and seems working well. Giv it a try. Best regards, O.K. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: NAT-T + ipsec integration
On Thursday 11 December 2008 14:39:58 VANHULLEBUS Yvan wrote: On Thu, Dec 11, 2008 at 04:02:01AM -0800, Gabe wrote: Hello all Hi. Does anyone know how to enable nat traversal on freebsd? I've got a site to site ipsec tunnel setup but clients behind the nat can't vpn through it. Any help would be appreciated. Actually, you can apply a patch to src/sys and recompile your kernel with IPSEC_NAT_T options. Patches are available here: http://people.freebsd.org/~vanhu/NAT-T/ And what about patches for 6.4-RELEASE? You can also try to play with Perforce's branch, but it is still work in progress to have a cleaned up version of PFKey interface (it may work, but I just started to set up some testing hosts). To answer the question some people may ask in this thread: the whole patch should be included in TRUNK as soon as PFKey cleanup will be done (which means implemented + heavilly tested + reviewed). Yvan. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org -- Sincerely yours, Artyom Viklenko. --- ar...@aws-net.org.ua | http://www.aws-net.org.ua/~artem ar...@viklenko.net | FreeBSD: The Power to Serve - http://www.freebsd.org ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: NAT-T + ipsec integration
On Fri, 12 Dec 2008, VANHULLEBUS Yvan wrote: On Fri, Dec 12, 2008 at 06:45:20PM +0200, Artyom Viklenko wrote: On Thursday 11 December 2008 14:39:58 VANHULLEBUS Yvan wrote: [] Actually, you can apply a patch to src/sys and recompile your kernel with IPSEC_NAT_T options. Patches are available here: http://people.freebsd.org/~vanhu/NAT-T/ And what about patches for 6.4-RELEASE? I just not tested on 6.4 (almost all my devices moved to 7.x, and the remaining ones will stay in 6.3 for various reasons), but 6.3 patch should work on 6.4 if it compiles cleanly (I did NOT check every single kernel change between 6.3 and 6.4). If people can test it and see some compile/runtime problems, please report them, I'll try to fix them. Just applied the patch to 6.4-RELEASE. Kernel was compiles successfully and ipsec-tools (racoon) also was compiled successufully with NAT-T. Racoon started and reported about NAT-T support. So far so good! Will try to run IPSec tunnel may be in couple of weeks. Thanks a lot! -- Sincerely yours, Artyom Viklenko. --- ar...@aws-net.org.ua | http://www.aws-net.org.ua/~artem FreeBSD: The Power to Serve - http://www.freebsd.org ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: FreeBSD 4.9 - NIS Authentication Problem (SSHD Illegal User ERROR)
David Kramer wrote: **IF this is the wrong list for this topic please let me know which list I should post network services issues to. I am relatively new to FreeBSD but have quite a bit of experience with NIS on Linux. I am currently working on connecting a FreeBSD 4.9 client connection to NIS server running on OpenBSD 3.9. The ypcat commands are working and I can see the passwd and group files, however when I attempt to login to the machine I keep getting SSHD Illegal User Errors. The type of behavior I am seeing would be common on a Linux machine that uses nssswitch.conf to state which objects to pass authentication through, but its missing the nis value for passwd: or group:. Looking through the FreeBSD website I see that nssswitch was introduced in FreeBSD 5.X. For previous versions of FreeBSD and NIS, are there any additional configurations that need to be done? Possibly with PAM? I have the following values in my /etc/rc.conf files: Have you added special records to /etc/group and /etc/master.passwd files? It should be +::: in /etc/group and +: in /etc/master.passwd. Use vipw to edit password file. nisdomainname=myNISdomain nis_client_enable=YES I have followed the FreeBSD NIS/YP Handbook configuration to the T, and still get the illegal user authentication any insight would be greatly appreciated. Thanks much, DK -- Sincerely yours, Artyom Viklenko. --- [EMAIL PROTECTED] | http://www.aws-net.org.ua/~artem [EMAIL PROTECTED] | FreeBSD: The Power to Serve - http://www.freebsd.org ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD as a gigabit router
Cristian KLEIN wrote: Thank you all for your replies. Kirill Ponazdyr wrote: Hi list, A few days ago I tested whether a FreeBSD 7 box is able to handle Gigabit Can anybody point me what the bottleneck of this configuration is? CPU was mostly idle and PCIe 1x should carry way more. Or is the experiment perhaps fundamentally flawed? ICMP is not a good way to perform such tests as many have mentioned, better use iperf. I used this test, because it proved perfect when, almost a decade ago, gigabit appeared. There wasn't anything at that time that could fill 1 Gbps, so we used the routers themselves to do the job. Also, I used this setup to avoid TCPs congestion control mecachnism and sub-maximum bandwidth. Of course, when I said ping -f, I didn't mean a single ping -f, but rather enough ping -f so that the looping packets would saturate the link. You can use option -i instead of -f: ping -nqs 1472 -i 0.1 1.2.3.4 will generate large enougth amount of 1500 bytes packets. Even more, use size more than 1472 and number of packets will be increased. Value of -i parameter can be increased too. But remember about sysctl variable net.inet.ip.maxfragsperpacket. By default, in FreeBSD 6.x it's value is 16. We have a FreeBSD 6.2 / pf box handling 2Gbps of traffic, real traffic, it will probably handle more, we just had no capacities or need to test. Hardware is a Single 2.4 Ghz Xeon with 2 x Intel Quad Pro 1000MT PCI-X Controllers on separate PCI-X Busses. Could you tell me, is there any difference between 1000PT and 1000MT, except the slot type? Also, is there any difference between Intel Desktop and Intel Server adaptors, or are these just marketing buzzwords? ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED] -- Sincerely yours, Artyom Viklenko. --- [EMAIL PROTECTED] | http://www.aws-net.org.ua/~artem FreeBSD: The Power to Serve - http://www.freebsd.org ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: MPD and fragmentation
Mihai Tanasescu wrote: Artyom Viklenko wrote: If you use PF, try to add rule scrub in all fragment rassemble no-df And VERY carefully check your ruleset. May be you block icmp in some place and PMTU doesn't work. As as last resort you can add max-mss some-size to scrub rule. some-size may be some value in range of 1300-1460. Sometimes it helps. Tried playing with the pf options. I have removed from mpd the iface mtu option and now I only have set iface mtu 1460. Still when trying to access www.msn.com (and similar sites) I see with tcpdump: From my systems www.msn.com resolves in 65.54.152.126. When I connect from my book to my freebsd router with pptp - I see mtu 1396 bytes on ng interface: ng5: flags=88d1UP,POINTOPOINT,RUNNING,NOARP,SIMPLEX,MULTICAST mtu 1396 inet 192.168.35.254 -- 192.168.35.1 netmask 0x I connect to Internet via ADSL/PPPoE which runs to same freebsd router with mpd. MTU is 1496. In pf I have scrub in all fragment reassemble no-df max-mss 1452 so, mss is notaffected by max-mss when tcp connection establishes from notebook. But www.msn.com sends packets with mss = 1356 bytes which corresponds with ng interface mtu of 1396. router runs freebsd 5.5 with mpd 3.18 - yes, have plans to upgrade :) in mpd.conf my pptp server configured with pptp_std: set bundle enable compression set bundle disable multilink set bundle enable noretry set bundle max-logins 0 set bundle enable radius-auth set bundle enable radius-acct set iface disable on-demand set iface disable proxy-arp set iface idle 1800 set iface enable tcpmssfix set iface mtu 1460 set iface enable radius-idle radius-session radius-route set link yes acfcomp protocomp set link yes pap set link enable chap-md5 chap-msv1 chap-msv2 chap set link mtu 1460 set link mru 1460 set link keep-alive 10 60 set link max-redial -1 set ipcp yes vjcomp set ipcp dns 192.168.32.253 192.168.32.254 set ipcp nbns 192.168.32.253 set ipcp ranges 192.168.35.254/32 192.168.35.1/28 set ipcp enable radius-ip set ccp yes mppc set ccp yes mpp-e40 set ccp yes mpp-e56 set ccp yes mpp-e128 set ccp yes mpp-stateless set pptp enable incoming set pptp disable originate set pptp disable windowing set pptp disable delayed-ack set radius retries 3 set radius timeout 3 set radius server 192.168.32.253 XXX 1812 1813 set radius me 192.168.32.254 set radius acct-update 300 All works fine. :) After lowering the MSS from pf the communication started like this: 11:25:02.980179 IP (tos 0x0, ttl 127, id 31152, offset 0, flags [DF], proto: TCP (6), length: 48) 86.105.56.134.65390 207.68.183.32.80: S, cksum 0x977a (correct), 942644994:942644994(0) win 65535 mss 1300,nop,nop,sackOK (the outgoing mss got lowered to 1300) 86.105.56.134 = my test IP address on which I'm NAT-ing packets from ng0 with pf 11:25:03.190826 IP (tos 0x0, ttl 63, id 40014, offset 0, flags [none], proto: TCP (6), length: 44) 207.68.183.32.80 86.105.56.134.65390: S, cksum 0x5fb4 (correct), 3691466834:3691466834(0) ack 942644995 win 8190 mss 1400 11:25:03.191677 IP (tos 0x0, ttl 127, id 31155, offset 0, flags [DF], proto: TCP (6), length: 40) 86.105.56.134.65390 207.68.183.32.80: ., cksum 0x9733 (correct), 1:1(0) ack 1 win 65535 11:25:03.192210 IP (tos 0x0, ttl 127, id 31157, offset 0, flags [DF], proto: TCP (6), length: 804) 86.105.56.134.65390 207.68.183.32.80: P 1:765(764) ack 1 win 65535 11:25:03.422363 IP (tos 0x0, ttl 63, id 40290, offset 0, flags [DF], proto: TCP (6), length: 1440) 207.68.183.32.80 86.105.56.134.65390: P 1:1401(1400) ack 765 win 8190 11:25:03.422417 IP (tos 0x0, ttl 64, id 58490, offset 0, flags [DF], proto: ICMP (1), length: 56) 86.105.56.134 207.68.183.32: ICMP 86.105.56.134 unreachable - need to frag (mtu 1396), length 36 IP (tos 0x0, ttl 63, id 40290, offset 0, flags [DF], proto: TCP (6), length: 1440) 207.68.183.32.80 86.105.56.134.65390: [|tcp] The is the ng0 established MTU: ng0: flags=88d1UP,POINTOPOINT,RUNNING,NOARP,SIMPLEX,MULTICAST mtu 1396 inet 192.168.1.129 -- 192.168.1.130 netmask 0x I have upgraded MPD to 4.2 pkg_info | grep mpd mpd-4.2.2 Multi-link PPP daemon based on netgraph(4) I have disabled windowing: set pptp disable windowing I have enabled the multilink for a test: set bundle enable multilink The Ethernet interface (rl0 - 86.105.56.134) that is used both as the endpoint for tunnel connections and for NAT for anything not destined to the local net: rl0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 Also I'm upgrading the system today from 6.1 to 6.2. I tried transferring data inside my net without going through the pf NAT
Re: MPD and fragmentation
Artyom Viklenko wrote: I connect to Internet via ADSL/PPPoE which runs to same freebsd router with mpd. MTU is 1496. In pf I have Sorry, MTU is 1492 bytes, sure. :) -- Sincerely yours, Artyom Viklenko. --- [EMAIL PROTECTED] | http://www.aws-net.org.ua/~artem FreeBSD: The Power to Serve - http://www.freebsd.org ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: MPD and fragmentation
Mihai Tanasescu wrote: Hello, With help from another FreeBSD user on this list I was able to set up an MPD pptp server to allow windows machines to connect to it. Unfortunately now I've stumbled upon some strange behaviors. First of all I'm getting icmp losses even if I use a test LAN to make a tunnel to the local FBSD machine, but these don't seem to affect my transfer rate when trying to get a large file via HTTP from the same machine. What bothers me most is that some sites (like msn.com, microsoft.com, etc) don't seem to be loading. What I first thought about was the mss problem and so I discovered the following: 22:54:36.633254 IP (tos 0x0, ttl 64, id 14254, offset 0, flags [DF], proto: ICMP (1), length: 56) FBSD-IP 207.68.183.32: ICMP FBSD-IP unreachable - need to frag (mtu 1336), length 36 In my config file I have: set iface mtu 1500 set link mtu 1440 set iface enable tcpmssfix My full config is posted here: http://pastebin.com/m66a3c05f My system: FreeBSD 6.1-RELEASE-p17 MPD 4.1 I played a bit with the above mentioned values with no luck unfortunately. I'm still wondering (don't know if I'm right) if a too large packet comes from 207.68.183.32 why doesn't it get fragmented upon being sent via ng0 - pptp1 and instead of this happening my machine sends an ICMP unreachable back. Also I have pf running on that machine with a NAT rule for traffic not destined to the local network (but after several experiments with that nothing changed in regard to the problem I have). I'm banging my head against the wall as I don't know what else to try anymore. Can someone help me out ? If you use PF, try to add rule scrub in all fragment rassemble no-df And VERY carefully check your ruleset. May be you block icmp in some place and PMTU doesn't work. As as last resort you can add max-mss some-size to scrub rule. some-size may be some value in range of 1300-1460. Sometimes it helps. -- Sincerely yours, Artyom Viklenko. --- [EMAIL PROTECTED] | http://www.aws-net.org.ua/~artem FreeBSD: The Power to Serve - http://www.freebsd.org ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: mpd and vlan
Ganbold wrote: Alexander Motin wrote: Hi. Ganbold wrote: Is it possible to give static IP addresses to the users using mpd? How it should be done? User is authenticating with radius server. Your RADIUS server should send FRAMED_IP_ADDRESS attribute to mpd specifying required IP address. When mpd will get that attribute it will propose it to client instead of specified in set ipcp ranges option. I tried it in mpd-3.18, Radius server sends Framed IP Address, however mpd still assigns IP specified in set ipcp ranges 192.168.5.2/32 192.168.5.169/25 What could be a problem? How to solve this issue? Check if you include set ipcp enable radius-ip in your bundle description. -- Sincerely yours, Artyom Viklenko. --- [EMAIL PROTECTED] | http://www.aws-net.org.ua/~artem FreeBSD: The Power to Serve - http://www.freebsd.org ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 6.2 mtu now limits size of incomming packet
Stephen Clark wrote: Artyom Viklenko wrote: Artem Belevich wrote: Here's one example where MTU!=MRU would be useful. Think of asymmetric bandwith-limited ADSL links. Lower MTU would allow lower TX latency for high priority packets when upstream is saturated, yet large MRU on the downstream would be great for downloads. Right now with 6.2 one has to trade off lower latency for faster download. --Artem You can prioritize small packets with ACKs, for example, by other techniques - ALTQ one of them. Unconditional lovering MTU even on ADSL tend to loss throughtput. And let's think about TCP MSS. When TCP connection establishes, TCP stack uses MTU as measure to choose MSS. Any two hosts, connected to single Layer2 network MUST use same MTU. Any other cases lead to hard-to-solve problems. This is all IMHO. But I would not like to see different MTU and MRU on my Ethernet interfaces! :) Yes but the mss is what the endpoints in the connection know about their own mtu's, at this point there is no knowledge of the mtu/mru's of intermediate routers. Steve Why? When two endpoints negotiated tcp connections they do know about remote mss - maximum segment that remote side can receive. PMTU is little bit anothr problem of misconfiguration on firewalls and intermediate routers. Very common situation when users block whole ICMP protocol on their router/host while connects to Internet via PPPoE/PPTP. -- Sincerely yours, Artyom Viklenko. --- [EMAIL PROTECTED] | http://www.aws-net.org.ua/~artem FreeBSD: The Power to Serve - http://www.freebsd.org ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 6.2 mtu now limits size of incomming packet
Artem Belevich wrote: Here's one example where MTU!=MRU would be useful. Think of asymmetric bandwith-limited ADSL links. Lower MTU would allow lower TX latency for high priority packets when upstream is saturated, yet large MRU on the downstream would be great for downloads. Right now with 6.2 one has to trade off lower latency for faster download. --Artem You can prioritize small packets with ACKs, for example, by other techniques - ALTQ one of them. Unconditional lovering MTU even on ADSL tend to loss throughtput. And let's think about TCP MSS. When TCP connection establishes, TCP stack uses MTU as measure to choose MSS. Any two hosts, connected to single Layer2 network MUST use same MTU. Any other cases lead to hard-to-solve problems. This is all IMHO. But I would not like to see different MTU and MRU on my Ethernet interfaces! :) -- Sincerely yours, Artyom Viklenko. --- [EMAIL PROTECTED] | http://www.aws-net.org.ua/~artem FreeBSD: The Power to Serve - http://www.freebsd.org ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 6.2 mtu now limits size of incomming packet
Eli Dart wrote: The networks that are apparently working fine are most likely misconfigured, IMHO. Others have made a case for permitting an interface to accept as large a packet as it can, regardless of configured MTU. That's fine for theory. My operational experience leads me to a different place. If an interface receives a packet that is larger than its configured MTU, I would prefer that the packet be dropped as a giant and a giants counter incremented, regardless of whether the hardware can theoretically receive the packet. In modern networks, an MTU mismatch within a broadcast domain indicates a broken network, IMHO. If the devices in the network are configured to enforce MTU for both tx and rx, more problems get spotted during turnup, rather than surfacing later on as difficult-to-diagnose problems that users only call about after they are truly frustrated. And, if you have a giants counter (or input error counter) you can look at, it makes it straightforward to spot the problem. (one could also stretch a bit and say that enforcing MTU on rx might provide less surprise to code that consumes packets and has knowledge of the MTU setting of an interface.unfortunately I don't know enough about the details of the network stack to know if this is a real concern) 100% agree! :) -- Sincerely yours, Artyom Viklenko. --- [EMAIL PROTECTED] | http://www.aws-net.org.ua/~artem FreeBSD: The Power to Serve - http://www.freebsd.org ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Again two ADSL lines, routing problems
Andrea Venturoli wrote: Hello. I have a setup where a FreeBSD box is connected to two ADSL routers: default gateway is set to the first and, in case of failure, is moved to the other one. This works perfectly for outgoing connections: in the event of the switch, I'll have to reconnect, but that's acceptable. The problem is in the incoming connections: if I get one on the backup router, this will reach the server, which will however answer through its default router. Thus the remote client will see packets coming back from a different host and things won't work. Just to be clear, the packets travel as follows (with source and dest IP in brackets): Client (x.x.x.x) - Backup router (y.y.y.y) Backup router (x.x.x.x) - Server (z.z.z.z) Server (z.z.z.z) - Default router (x.x.x.x) Default router (v.v.v.v) - Client (x.x.x.x) So the client (x.x.x.x) connects to y.y.y.y (the backup ADSL public IP), but gets answers from v.v.v.v (the master ADSL public IP). AFAIK there is no solution to this, but I tought I'd ask before giving my official opinion to my customer. Perhaps there's some sort of hack we could use, that through ipfw/natd/other diverting daemon/whatever delivers answers based on the MAC address of the incoming connections (if the MAC address belongs to the backup router, use that for answers)... does anyone know? You have to enforce simmetrical routing on your FreeBSD box. You can use, for example, PF firewall Using such options and features as labels and route-to/reply-to statemens. Also it is possible with ipfw, but I prefer PF. :) -- Sincerely yours, Artyom Viklenko. --- [EMAIL PROTECTED] | http://www.aws-net.org.ua/~artem FreeBSD: The Power to Serve - http://www.freebsd.org ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Again two ADSL lines, routing problems
On Thu, 12 Jul 2007, Andrea Venturoli wrote: Artyom Viklenko ha scritto: Very brief example (just to show main idea). Assume you have thre interfaces in router fxp0 - lan, fxp1 - adsl1, fxp2 - adsl2. fxp0 - 192.168.0.1, fxp1 - 192.168.1.2, fxp2 - 192.168.2.2 adsl1 - 192.168.1.1, adsl2 - 192.168.2.1 $server=192.168.0.2 $adsl1=192.168.1.1 $adsl2=192.168.2.1 pass in on fxp1 inet from any to $server keep state tag ADSL1 pass in on fxp2 inet from any to $server keep state tag ADSL2 pass out on fxp0 reply-to (fxp1 $adsl1) from any to $server tagged ADSL1 keep state pass out on fxp0 reply-to (fxp2 $adsl2) from any to $server tagged ADSL2 keep state This is just part of whole rulebase regarding your problem. Packets coming in via adsl1 will pass and got tagged by ADSL1 tag. Also, state will be created. Then packet will pass out to server, state will be created. and all replies from server will be frowarded back via adsl1. Same for traffic from adsl2. Thank you very much, this might do the trick. However, in your example the two ADSL routers are on separate interfaces, while in the setup I have there's only one external interface (and a switch). Would this work the same, by tagging based on MAC address? Even if the machine is not acting as a bridge? Should I create a bridge0 interface, even if it would actually not bridge anything? Besides, I don't really understand what fxp0 has to do with this: the box which is connected to the two ADSL is running the server, so in the above example $server would be 192.168.0.1 itself. If I understand correctly I should do something on the line of: $adsl1=192.168.0.1 $adsl1mac=aa:bb:cc:dd:ee:ff $adsl2=192.168.0.2 $adsl2mac=gg:hh:ii:jj:kk:ll //Tag based on MAC address Unfortunately, PF does not work with layer 2 data like MAC addresses. pass in on fxp0 reply-to (fxp0 $adsl1) inet from any to $server tagged ADSL1 keep state pass in on fxp0 reply-to (fxp0 $adsl2) inet from any to $server tagged ADSL2 keep state This should work. Also, is is possible to set up two aliases on FreeBSD box for server and redurect connections from adsl routers to different addresses on it. And then route back packets from server to adsl routers based on ip. One last question: could I use this, while still filtering with ipfw as I do now? Can the two firewalls cooperate? Would this be too much trouble (even if I have a non trivial ruleset working)? While it is possible to use two firewalls on the same system, I won't recommend to do so until you have some special requirements in layer 2 filtering. E.g. if you need to filter some cleints based on their MAC address. IPFW alone also can do what you want. PF way just more elegant. :) You have yo deside how would you differentiate packets going back from your server. If you have two incoming interfaces it is much simpler. If you have managed switch, you can create separate VLAN for each ADSL and two vlan interfaces on FreeBSD. You can do this even with dumb unmanaged swich. Or use two ip addresses on server. Someone can suggest a way with ipfw? I found this: http://archive.netbsd.se/?ml=dfbsd-usersa=2005-10t=1361976 (the last message). It would involve creating a second net on the same ethernet segment, but I can live with that (altough it is going to be slightly more compilcated since I'm also using CARP). Any opinion on this? -- Sincerely yours, Artyom Viklenko. --- [EMAIL PROTECTED] | http://www.aws-net.org.ua/~artem FreeBSD: The Power to Serve - http://www.freebsd.org ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ppp/peers/* files
Jim Stapleton wrote: That partially worked. I could only ping 192.168.1.1 on my local setup (router). I used $ mpd pptp0 However, I couldn't access the work DNS either. The latter output of MPD looked like: == pptp0] IPCP: rec'd Configure Ack #4 link 0 (Ack-Sent) IPADDR IP-ADDR-A [pptp0] IPCP: state change Ack-Sent -- Opened [pptp0] IPCP: LayerUp IP-ADDR-A - IP-ADDR-B [pptp0] IFACE: Up event [pptp0] setting interface ng0 MTU to 1396 bytes [pptp0] exec: /sbin/ifconfig ng0 IP-ADDR-A IP-ADDR-B netmask 0x -link0 [pptp0] exec: /sbin/route add IP-ADDR-A -iface lo0 [pptp0] exec: /sbin/route add 0.0.0.0 IP-ADDR-B [pptp0] exec: command returned 256 == I could ping IP-ADDR-A and IP-ADDR-B after running mpd, but I could not ping them before running it, or after shutting it down. Both are valid IP addresses on my works internal network. Aside from my nve0 and l0 devices, which look normal, ifconfig displays the following: == ng0: flags=88d1UP,POINTOPOINT,RUNNING,NOARP,SIMPLEX,MULTICAST mtu 1396 inet IP-ADDR-A -- IP-ADDR-B netmask 0x == I could not ping the DNS servers. Any suggestions? I think you need static route to your VPN server. After setting up tullel your default route changes. This can lead to incorrect routing. -- Sincerely yours, Artyom Viklenko. --- [EMAIL PROTECTED] | http://www.aws-net.org.ua/~artem FreeBSD: The Power to Serve - http://www.freebsd.org ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ppp/peers/* files
On Tue, 26 Jun 2007, Jim Stapleton wrote: What man/handbook pages/sections should I look at to get a clue. I'm so far from having one, I don't even know the direction... see handbook section about networking. simply speaking enter route add ip-of-vpn-server ip-of-your-lan-gateway then start MPD and check is all ok. if yes, you can add this route to /etc/rc.conf using static_routes variable. Thanks, -Jim Stapleton On 6/26/07, Artyom Viklenko [EMAIL PROTECTED] wrote: Jim Stapleton wrote: That partially worked. I could only ping 192.168.1.1 on my local setup (router). I used $ mpd pptp0 However, I couldn't access the work DNS either. The latter output of MPD looked like: == pptp0] IPCP: rec'd Configure Ack #4 link 0 (Ack-Sent) IPADDR IP-ADDR-A [pptp0] IPCP: state change Ack-Sent -- Opened [pptp0] IPCP: LayerUp IP-ADDR-A - IP-ADDR-B [pptp0] IFACE: Up event [pptp0] setting interface ng0 MTU to 1396 bytes [pptp0] exec: /sbin/ifconfig ng0 IP-ADDR-A IP-ADDR-B netmask 0x -link0 [pptp0] exec: /sbin/route add IP-ADDR-A -iface lo0 [pptp0] exec: /sbin/route add 0.0.0.0 IP-ADDR-B [pptp0] exec: command returned 256 == I could ping IP-ADDR-A and IP-ADDR-B after running mpd, but I could not ping them before running it, or after shutting it down. Both are valid IP addresses on my works internal network. Aside from my nve0 and l0 devices, which look normal, ifconfig displays the following: == ng0: flags=88d1UP,POINTOPOINT,RUNNING,NOARP,SIMPLEX,MULTICAST mtu 1396 inet IP-ADDR-A -- IP-ADDR-B netmask 0x == I could not ping the DNS servers. Any suggestions? I think you need static route to your VPN server. After setting up tullel your default route changes. This can lead to incorrect routing. -- Sincerely yours, Artyom Viklenko. --- [EMAIL PROTECTED] | http://www.aws-net.org.ua/~artem FreeBSD: The Power to Serve - http://www.freebsd.org ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED] -- Sincerely yours, Artyom Viklenko. --- [EMAIL PROTECTED] | http://www.aws-net.org.ua/~artem FreeBSD: The Power to Serve - http://www.freebsd.org ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ppp/peers/* files
Jim Stapleton wrote: I can't find a way to specify mppe-128 for either pptp or pppd in the man files, and every doc I see (including the man pages examples, which don't work when I specify it in the file) seem to suggest that I use either mppe-128 or require-mppe-128 for pppd, neither of which work. Any suggestions? As far as I know, pppd in FreeBSD does not support natively mppc and needs patches. (Maybe this functionality provided by pptp.) But MPD does! And it support it using in-kernel netgraph subsystem. So, I suggest to install mpd and set it up to connect to your Windows VPN server. Your configs may look like this. mpd.conf file: default: load pptp0 pptp0: new -i ng0 pptp0 pptp0 set bundle enable compression set bundle disable multilink set bundle authname your-username set bundle password your-password set iface disable on-demand set iface idle 0 set iface mtu 1460 set iface route default set link yes acfcomp protocomp set link disable pap set link accept chap-md5 chap-msv1 chap-msv2 chap set link enable no-orig-auth set link mtu 1460 set link mru 1460 set link keep-alive 10 60 set ipcp yes vjcomp set ipcp ranges 0.0.0.0/0 0.0.0.0/0 set ccp yes mppc set ccp yes mpp-e40 set ccp yes mpp-e56 set ccp yes mpp-e128 set ccp yes mpp-stateless set pptp peer ip-of-your-vpn-server set pptp disable incoming set pptp enable originate out-call set pptp disable windowing set pptp disable delayed-ack open iface mpd.links file: pptp0: set link type pptp Also make shure you have loaded (or compiled in kernel): ng_bpf.ko netgraph.ko ng_ether.ko ng_iface.ko ng_ksocket.ko ng_mppc.ko rc4.ko ng_netflow.ko ng_ppp.ko ng_pptpgre.ko ng_socket.ko ng_tee.ko ng_vjc.ko ng_tty.ko ng_async.ko Hope this helps. -- Sincerely yours, Artyom Viklenko. --- [EMAIL PROTECTED] | http://www.aws-net.org.ua/~artem FreeBSD: The Power to Serve - http://www.freebsd.org ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ppp/peers/* files
Jim Stapleton wrote: where do I find the valid commands I can put in these files (yes, still on the never ending saga to get VPN working on my BSD machine so I don't need to boot windows) peers files contains the same options as /etc/ppp/options or /etc/ppp/options.ttyxx files - generally speaking, any options valid for pppd. So, see 'man pppd'. I don't know about your VPN scenario, but anyway I would recommend you to give mpd a tyr. -- Sincerely yours, Artyom Viklenko. --- [EMAIL PROTECTED] | http://www.aws-net.org.ua/~artem FreeBSD: The Power to Serve - http://www.freebsd.org ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Re[6]: mpd pppoe client problems
quote who=Alexei Hello, Artyom. Why do you use ipnat and ipfw? May be better to use one firewall? ipfilter itself or ipfw with natd or ng-nat. I used to use ipfw as a firewall.. and natd makes too heavy cpu load. Try to use ipfilter or pf. They do nat in kernel. Or you can use ng_nat with ipfw. I'm not shure but ipfilter allow to define rules with interfaces which does not exist at the time of firewall activation (at least PF can). Also, you don't need to restart ntpd each time your interface goes up. Same for named and apache. Typically. May be you have some very interesting requirements to do so?.. Em.. Well.. After system startup there is no external interface (ng or tun) to bind to. How can I make those applications bind to the new interface after it gone up? Do you really need to bind them to particular interface? If you bind, for example, apache to wildcard address 0.0.0.0, (as in default configuration), it will work with new interfaces and addresses. If you use some kind of ip-based virtualhost configuration, you can bind it to some local private IP, and redirect incoming traffic to that address. This local ip will always be available for apache. natd, as i know, bind itself to ALL ips on system. And it will syncronize well with external time sources when they are beacame available. I have dialup ppp connection at home and I have ntpd. When link is up, it syncronizes with sources, when link is down it lost syncronization until next availability of connection. And I do not restart it every time link does up. Your named, I think, can be binded to your internal address. But it can send queries with any address available at the time of sending this request depending on routing information. Try to keep things as simple as possible! :) -- Sincerely yours, Artyom Viklenko. --- [EMAIL PROTECTED] | http://www.aws-net.org.ua/~artem FreeBSD: The Power to Serve - http://www.freebsd.org ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: mpd pppoe client problems
quote who=Alexei Hello world. My provider give me access to the net via pppoe, so I decided to use mpd as a client. I've compiled into the kernel some netgraph modules, edited a little default mpd config and started it via rc.d. Everything looked ok, connection established, but no packets walked throw interface. When I tried to stop mpd, it didn't. It looked like 'Waiting for pids: 1234, 1234, 1234, 1234' ets.. So I had to use kill -9 and ngctl shutdown to stop mpd. What should I do to make mpd work fine? # mpd.conf default: load maryno maryno: new -i ng0 PPPoE PPPoE set iface route default set iface up-script /usr/local/etc/mpd/inet-up.sh set iface disable on-demand set iface idle 0 set bundle disable multilink set bundle authname my-corrext-login set bundle password my-cool-pass set link no acfcomp protocomp set link disable pap chap set link accept chap set link mtu 1498 ^ first, check this set link keep-alive 10 60 set ipcp yes vjcomp set ipcp ranges 0.0.0.0/0 0.0.0.0/0 open also check your firewall. -- Sincerely yours, Artyom Viklenko. --- [EMAIL PROTECTED] | http://www.aws-net.org.ua/~artem FreeBSD: The Power to Serve - http://www.freebsd.org ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Re[2]: mpd pppoe client problems
quote who=Alexei Hello. set link mtu 1498 ^ first, check this What should I put there? BTW, how can it make mpd ignore rc.d stop command? set link mtu 1492 check with ps command in which state mpd is when issuing rc.d stop command. mine config: new -i ng0 PPPoE PPPoE set iface addrs 1.1.1.1 2.2.2.2 set iface disable on-demand set iface idle 0 set iface enable tcpmssfix set bundle disable multilink set bundle disable compression set bundle authname XX set bundle password YY set link no acfcomp protocomp set link disable pap chap set link accept chap set link mtu 1492 set link mru 1492 set link keep-alive 10 60 set ipcp no vjcomp set ipcp ranges 0.0.0.0/0 0.0.0.0/0 open iface and in mpd.links: PPPoE: set link type pppoe set pppoe iface rl0 set pppoe service ProviderName set pppoe disable incoming set pppoe enable originate works fine also check your firewall. Nothing prevents it + ppp works fine. (But I don't like it for high cpu load) much better to show your rulebase -- Sincerely yours, Artyom Viklenko. --- [EMAIL PROTECTED] | http://www.aws-net.org.ua/~artem FreeBSD: The Power to Serve - http://www.freebsd.org ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Re[2]: mpd pppoe client problems
quote who=Alexei Hello. set link mtu 1498 ^ first, check this What should I put there? BTW, how can it make mpd ignore rc.d stop command? also check your firewall. Nothing prevents it + ppp works fine. (But I don't like it for high cpu load) BTW, user-level ppp performs TCP MSS fix. MPD does not in client mode. Use your firewall to correct this. -- Sincerely yours, Artyom Viklenko. --- [EMAIL PROTECTED] | http://www.aws-net.org.ua/~artem FreeBSD: The Power to Serve - http://www.freebsd.org ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Re[2]: mpd pppoe client problems
quote who=Alexei On Tue, 12 Dec 2006 12:48:25 +0200 (EET) Artyom Viklenko [EMAIL PROTECTED] wrote: Changed mtu mru, nothing changed. # /usr/local/etc/rc.d/mpd.sh stop Stopping mpd. Waiting for PIDS: 47927, 47927, 47927, 47927, 47927, 47927, 47927, 47927, 47927, 47927, 47927, 47927, 47927, 47927, 47927, 47927, 47927, 47927, 47927, 47927, 47927, 47927, 47927, 47927, 47927, 47927, 47927, 47927, 47927, 47927, 47927, 47927, 47927, 47927, 47927, 47927, 47927^C ## (before i interrupted rc.d script) [EMAIL PROTECTED] ps -auxww | grep mpd root 47927 0,0 0,4 2720 1492 ?? Is 19:26 0:00,01 /usr/local/sbin/mpd -b root 47936 0,0 0,3 1644 1080 ?? I19:26 0:00,00 sh -c /usr/local/etc/mpd/inet-up.sh ng0 inet 81.88.209.42 81.88.208.255 mylogin /dev/null 21 Would you show us content of your inet-up.sh script? And output of `netstat -inlb`, `netstat -rna` when mpd established connection. root 47937 0,0 0,3 1644 1076 ?? I19:26 0:00,01 /bin/sh /usr/local/etc/mpd/inet-up.sh ng0 inet 81.88.209.42 81.88.208.255 nylogin dmn48208 0,0 0,2 1452 832 p0 R+ 19:28 0:00,00 grep mpd root 48062 0,0 0,3 1764 1220 p1 S+ 19:27 0:00,05 /bin/sh /usr/local/etc/rc.d/mpd.sh stop [EMAIL PROTECTED] top -n 500 | grep 47927 47927 root1 80 2720K 1492K wait 0:00 0.00% mpd -- Grats, Alexei, [EMAIL PROTECTED] -- Sincerely yours, Artyom Viklenko. --- [EMAIL PROTECTED] | http://www.aws-net.org.ua/~artem FreeBSD: The Power to Serve - http://www.freebsd.org ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
