Re: kern/147191: Problems with ppp -nat [pppoe], ipfw, dummynet
The following reply was made to PR kern/147191; it has been noted by GNATS. From: Jose M Rodriguez To: bug-follo...@freebsd.org, jos...@freebsd.jazztel.es Cc: Subject: Re: kern/147191: Problems with ppp -nat [pppoe], ipfw, dummynet Date: Sat, 29 May 2010 21:27:05 +0200 Sorry for the noise, you can close this It's a ducmented efect of one_pass=1 I'm rewriting the rules and using one_pass=0 -- josemi ___ 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: kern/147191: [ppp] Problems with ppp -nat [pppoe], ipfw, dummynet
The following reply was made to PR kern/147191; it has been noted by GNATS.
From: Jose M Rodriguez
To: bug-follo...@freebsd.org, jos...@freebsd.jazztel.es
Cc:
Subject: Re: kern/147191: [ppp] Problems with ppp -nat [pppoe], ipfw, dummynet
Date: Wed, 02 Jun 2010 02:37:20 +0200
This is a multi-part message in MIME format.
--080505020803060701030501
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Seems that this must be reopen.
After redo the rules to work with one_pass=0, problems of all sort still
alive.
- ppp nat seems to consume all translated traffic 'in to out', with or
without one_pass set.
but traffic 'out to in' hit ipfw rules following specs
- after changing to mpd5 + natd, problems are even more strange, and
firewall mostly works
only if local net traffic is done LAST and not FIRST. But some NATed
apps fails (jdownloader, bitcomet file donloader), while others works
(firefox and his file downloader)
My vote is for some problem with libalias.
At the moment, I MUST put the sharper FIRST, catching the traffic coming
from local net.
I'm very busy now, but can go over this again after 2 weeks.
Attached rc.firewall mostly working with mpd5 + natd as reference
--080505020803060701030501
Content-Type: text/plain;
name="rc.firewall.router.1"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename="rc.firewall.router.1"
#!/bin/sh -
# Copyright (c) 1996 Poul-Henning Kamp
# All rights reserved.
#
# Redistribution and use in source and binary forms, with or without
# modification, are permitted provided that the following conditions
# are met:
# 1. Redistributions of source code must retain the above copyright
#notice, this list of conditions and the following disclaimer.
# 2. Redistributions in binary form must reproduce the above copyright
#notice, this list of conditions and the following disclaimer in the
#documentation and/or other materials provided with the distribution.
#
# THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
# ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
# IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
# ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
# FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
# DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
# OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
# HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
# LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
# OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
# SUCH DAMAGE.
#
# $FreeBSD: src/etc/rc.firewall,v 1.60.2.3 2010/04/14 15:03:58 ume Exp $
#
# $Log$
#
# Setup system for ipfw(4) firewall service on AHS router
#
# Configuration:
# firewall_resetports:
# List of TCP ports reset on incoming
# firewall_myservices:
# List of TCP ports on which this host offers services.
# firewall_myudpports:
# List of UDP ports on which this host offers services.
# firewall_logdeny:
# Boolean (YES/NO) specifying if the default denied packets should be
# logged (in /var/log/security).
# firewall_nologports:
# List of TCP/UDP ports for which denied incoming packets are not logged.
# firewall_oif:
# Outside IPv4 network interface, default to tun0.
# firewall_iifaces:
# Inside network interface list.
# firewall_net_${iface}
# IPv4 network definition for each of the previous interfaces.
# firewall_p2p_${iface}
# List of address ports for opened TCP/UDP ports on ${iface}
# firewall_p2p_uids
# List of uids of p2p daemons running on me
# predefined
firewall_resetports="53,113,135-139,445"
firewall_p2p_uids="mlnet transmission"
for u in ${firewall_p2p_uids}; do
eval ${u}_enable="NO"
done
mpd_enable="NO"
# Suck in the configuration variables.
if [ -z "${source_rc_confs_defined}" ]; then
if [ -r /etc/defaults/rc.conf ]; then
. /etc/defaults/rc.conf
source_rc_confs
elif [ -r /etc/rc.conf ]; then
. /etc/rc.conf
fi
fi
. /etc/rc.subr
. /etc/network.subr
afexists inet6
ipv6_available=$?
# macros
fwcmd="/sbin/ipfw"
ifaces=${firewall_iifaces}
if checkyesno mpd_enable ; then
oif=${firewall_oif-ng0}
else
oif=${firewall_oif-tun0}
fi
log=""
# Set quiet mode if requested
checkyesno firewall_quiet && fwcmd="${fwcmd} -q"
# Flush out the list before we begin.
${fwcmd} -f flush
# setup loopback
${fwcmd} add 100 pass all from any to
Re: kern/147191: [ppp] Problems with ppp -nat [pppoe], ipfw, dummynet
The following reply was made to PR kern/147191; it has been noted by GNATS.
From: Jose M Rodriguez
To: bug-follo...@freebsd.org
Cc:
Subject: Re: kern/147191: [ppp] Problems with ppp -nat [pppoe], ipfw, dummynet
Date: Wed, 02 Jun 2010 04:31:49 +0200
This is a multi-part message in MIME format.
--090100060803090709040905
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
El 02/06/2010 2:37, Jose M Rodriguez escribió:
> Seems that this must be reopen.
> ...
Seems this one worked, but I don't remember this last time I use ipfw on
FreeBSD-7
--090100060803090709040905
Content-Type: text/plain;
name="rc.firewall.router.4"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename="rc.firewall.router.4"
#!/bin/sh -
# Copyright (c) 1996 Poul-Henning Kamp
# All rights reserved.
#
# Redistribution and use in source and binary forms, with or without
# modification, are permitted provided that the following conditions
# are met:
# 1. Redistributions of source code must retain the above copyright
#notice, this list of conditions and the following disclaimer.
# 2. Redistributions in binary form must reproduce the above copyright
#notice, this list of conditions and the following disclaimer in the
#documentation and/or other materials provided with the distribution.
#
# THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
# ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
# IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
# ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
# FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
# DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
# OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
# HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
# LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
# OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
# SUCH DAMAGE.
#
# $FreeBSD: src/etc/rc.firewall,v 1.60.2.3 2010/04/14 15:03:58 ume Exp $
#
# $Log$
#
# Setup system for ipfw(4) firewall service on AHS router
#
# Configuration:
# firewall_resetports:
# List of TCP ports reset on incoming
# firewall_myservices:
# List of TCP ports on which this host offers services.
# firewall_myudpports:
# List of UDP ports on which this host offers services.
# firewall_logdeny:
# Boolean (YES/NO) specifying if the default denied packets should be
# logged (in /var/log/security).
# firewall_nologports:
# List of TCP/UDP ports for which denied incoming packets are not logged.
# firewall_oif:
# Outside IPv4 network interface, default to tun0.
# firewall_iifaces:
# Inside network interface list.
# firewall_net_${iface}
# IPv4 network definition for each of the previous interfaces.
# firewall_p2p_${iface}
# List of address ports for opened TCP/UDP ports on ${iface}
# firewall_p2p_uids
# List of uids of p2p daemons running on me
# predefined
firewall_resetports="53,113,135-139,445"
firewall_p2p_uids="mlnet transmission"
for u in ${firewall_p2p_uids}; do
eval ${u}_enable="NO"
done
mpd_enable="NO"
# Suck in the configuration variables.
if [ -z "${source_rc_confs_defined}" ]; then
if [ -r /etc/defaults/rc.conf ]; then
. /etc/defaults/rc.conf
source_rc_confs
elif [ -r /etc/rc.conf ]; then
. /etc/rc.conf
fi
fi
. /etc/rc.subr
. /etc/network.subr
afexists inet6
ipv6_available=$?
# macros
fwcmd="/sbin/ipfw"
ifaces=${firewall_iifaces}
if checkyesno mpd_enable ; then
oif=${firewall_oif-ng0}
else
oif=${firewall_oif-tun0}
fi
log=""
# Set quiet mode if requested
checkyesno firewall_quiet && fwcmd="${fwcmd} -q"
# Flush out the list before we begin.
${fwcmd} -f flush
# setup loopback
${fwcmd} add 100 pass all from any to any via lo0
${fwcmd} add 200 deny all from any to 127.0.0.0/8
${fwcmd} add 300 deny all from 127.0.0.0/8 to any
# setup ipv6 mandatory
if [ $ipv6_available -ne 0 ]; then
${fwcmd} add 400 deny all from any to ::1
${fwcmd} add 500 deny all from ::1 to any
# DAD
${fwcmd} add pass ipv6-icmp from :: to ff02::/16
# RS, RA, NS, NA, redirect...
${fwcmd} add pass ipv6-icmp from fe80::/1o to fe80::/10
${fwcmd} add pass ipv6-icmp from fe80::/1o to ff02::/16
# IMCPv6 destination unreachable, NS, NA, toobig
${fwcmd} add pass ipv6-icmp from any to any icmp6 types 1,2,135,136
fi
# setup tables
${fwcmd} table all flus
Re: kern/147191: [ppp] Problems with ppp -nat [pppoe], ipfw, dummynet
El 03/06/2010 9:15, Ian Smith escribió: On Wed, 2 Jun 2010, Jose M Rodriguez wrote: > The following reply was made to PR kern/147191; it has been noted by GNATS. > > From: Jose M Rodriguez > To: bug-follo...@freebsd.org > Cc: > Subject: Re: kern/147191: [ppp] Problems with ppp -nat [pppoe], ipfw, dummynet > Date: Wed, 02 Jun 2010 04:31:49 +0200 [..] > El 02/06/2010 2:37, Jose M Rodriguez escribió: > > Seems that this must be reopen. > > ... > Seems this one worked, but I don't remember this last time I use ipfw on > FreeBSD-7 > [..] > Content-Disposition: attachment; >filename="rc.firewall.router.4" > > #!/bin/sh - > # Copyright (c) 1996 Poul-Henning Kamp > # All rights reserved. [..] > # $FreeBSD: src/etc/rc.firewall,v 1.60.2.3 2010/04/14 15:03:58 ume Exp $ I had to do a 'diff -uw rc.firewall.1.60.2.3 rc.firewall.router.4' (and before that, vs your previous rc.firewall.router.1) to follow what was going on here; you've added some 'interesting' stuff (esp dummynet), but I think your main problem is the placement of the NAT rule, where you've merged it into what is otherwise based on the 'workstation' ruleset. ... I don't have much experience doing ipfw setups, but I've setup docens of boxes with ipfilter. I don't think this maybe a 'rule' problem. I expect two hits, one IN and other OUT, per IP packet. But maybe this is NOT the case. I do things as I learned to do: - lo0 - local lans (big traffic, more simple) - outside (less traffic, complex) My initial setup (rc.firewall.router.4) uses ppp -nat, without natd. and one_pass=1 (without I Know). It mostly works, and I learn that I must setup one_pass=0 to get the packet again on ipfw after dummynet. As I can read, this must also matters to ppp -nat. So I expect that a packed passed IN from local lan, after translated, hit the firewall as XMIT on tun0. I near sure this is not the case. Can anyone probe this? So I must put the dummynet catching incoming traffic from lan to be translated later by ppp. This setup is NOW WORKING, with the sharper being effective and without problems with ppp -nat rc.firewall.router.1 it's another history, after the problems with ppp, using mpd5 and natd. I can't test this well, and the way things go are really odd, but this is how I get things mostly working. What I noted on this setup is that I must pass the traffic incoming from local lan LAST, or NATP is not fuction at all (I use to do LAN traffic very first by performance reasons). I begin to think in a libalias problem (inside natd this time), but I'm also in doubt about the two IN/OUT hits. Maybe there's only one hit as IN/OUT, as from a bridge hook? In any case, the gotos (skipto) are placed not only as logic, but also to get counts of packets and try to see what's going on. I know that the natd rule in not at the very first (/etc/rc.firewall use to put it as rule 25, even before 100 lo0.) but also near sure that no traffic that can matters natd (via oif, ng0) is passed or denied before that. This matters about being able to catch incoming lan Traffic before translated. This maybe my first test when I got time again. Replace natd at rule 25 and do again LAN traffic at FIRST. Also thinking in doing an altq/pf test. And I added SOME line to my ipfw Notes: - put dummynet VERY FIRST, if possible on INCOMING, and be sure that sysctl net.inet.ip.fw.one_pass=0. - FreeBSD don't expect by default any firewall processing after libalias. But now, I'm very busy, really -- josemi ___ 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"
[no subject]
Can someone take a look on PR bin/67550? The protocol correctness maybe not important, but the tftp blocksize option speed up our net boots a lot. thanks in advance, -- josemi -- Using Opera's revolutionary e-mail client: http://www.opera.com/m2/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Fwd: tftp block size server support
I'm not sure if this hot the list. Sorry, smtp realy problems --- Forwarded message --- From: "Jose M Rodriguez" <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject:Date: Sun, 19 Sep 2004 23:53:18 +0200 Can someone take a look on PR bin/67550? The protocol correctness maybe not important, but the tftp blocksize option speed up our net boots a lot. thanks in advance, -- josemi -- Using Opera's revolutionary e-mail client: http://www.opera.com/m2/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
General diskless problems.
After seen some mail about initdiskless, I recall that have some problems with diskless/pxe last time. Maybe of general interest. - can't mount a NFS root from a tftp operate loader - can't mount a NFS root froma a BOOTP configured kernel. This seems related to a bug in the loader/kernel kenv. Loader pass a nfsiohandle via kenv without check. If the loader doesn't do any NFS operation, it's a pretty invalid all zeroes nfsiohandle that messed kernel nfsroot mount. - PXE i/o problems. intel PXE i/o is NON_BLOCKING. It is supposed blocking on all the UDP code. Also seems recall a bios I/O buffer configured as a packet buffer. Sorry. I missed to report this (think). -- josemi ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
still problems closing TCP(ftp) streams
Hi, This is latest RELENG_5_3 I still have problems closing tcp (mainly ftp) streams, but can't see any special. This is at home. adsl router (pppoa, mtu/mru 1500), doing NAPT. local net working great. Linux and Windows working well. no time/stream pattern observed. Can anyone see something strange in this tcpdump output? It is hang at ftp stream closing. thanks, -- josemi 23:18:34.615860 IP (tos 0x0, ttl 64, id 53638, offset 0, flags [DF], length: 58) antares.redesjm.local.53853 > zeppo.rediris.es.ftp: P [tcp sum ok] 336:342(6)ack 3473 win 33304 23:18:34.664133 IP (tos 0x0, ttl 53, id 64936, offset 0, flags [DF], length: 100) zeppo.rediris.es.ftp > antares.redesjm.local.53853: P 3473:3521(48) ack 342 win 24616 23:18:34.664483 IP (tos 0x0, ttl 64, id 60305, offset 0, flags [DF], length: 64) antares.redesjm.local.57291 > zeppo.rediris.es.48994: S [tcp sum ok] 3275417208:3275417208(0) win 65535 23:18:34.712948 IP (tos 0x0, ttl 57, id 64937, offset 0, flags [DF], length: 64) zeppo.rediris.es.48994 > antares.redesjm.local.57291: S [tcp sum ok] 3492715774:3492715774(0) ack 3275417209 win 24616 23:18:34.713048 IP (tos 0x0, ttl 64, id 25778, offset 0, flags [DF], length: 52) antares.redesjm.local.57291 > zeppo.rediris.es.48994: . [tcp sum ok] 1:1(0) ack 1 win 33304 23:18:34.713206 IP (tos 0x0, ttl 64, id 54756, offset 0, flags [DF], length: 58) antares.redesjm.local.53853 > zeppo.rediris.es.ftp: P [tcp sum ok] 342:348(6)ack 3521 win 33304 23:18:34.765188 IP (tos 0x0, ttl 53, id 64938, offset 0, flags [DF], length: 82) zeppo.rediris.es.ftp > antares.redesjm.local.53853: P [tcp sum ok] 3521:3551(30) ack 348 win 24616 23:18:34.769997 IP (tos 0x8, ttl 57, id 64939, offset 0, flags [DF], length: 427) zeppo.rediris.es.48994 > antares.redesjm.local.57291: P 1:376(375) ack 1 win24616 23:18:34.770505 IP (tos 0x8, ttl 57, id 64940, offset 0, flags [DF], length: 52) zeppo.rediris.es.48994 > antares.redesjm.local.57291: F [tcp sum ok] 376:376(0) ack 1 win 24616 23:18:34.770606 IP (tos 0x0, ttl 64, id 26519, offset 0, flags [DF], length: 52) antares.redesjm.local.57291 > zeppo.rediris.es.48994: . [tcp sum ok] 1:1(0) ack 377 win 33304 23:18:34.771493 IP (tos 0x0, ttl 64, id 38399, offset 0, flags [DF], length: 52 ) antares.redesjm.local.57291 > zeppo.rediris.es.48994: F [tcp sum ok] 1:1(0) ack 377 win 33304 23:18:34.823060 IP (tos 0x8, ttl 57, id 64941, offset 0, flags [DF], length: 52) zeppo.rediris.es.48994 > antares.redesjm.local.57291: . [tcp sum ok] 377:377(0) ack 2 win 24616 23:18:34.856005 IP (tos 0x0, ttl 64, id 13732, offset 0, flags [DF], length: 52) antares.redesjm.local.53853 > zeppo.rediris.es.ftp: . [tcp sum ok] 348:348(0)ack 3551 win 33304 23:18:34.902684 IP (tos 0x0, ttl 53, id 64942, offset 0, flags [DF], length: 105) zeppo.rediris.es.ftp > antares.redesjm.local.53853: P 3551:3604(53) ack 348 win 24616 23:18:34.904000 IP (tos 0x0, ttl 64, id 40099, offset 0, flags [DF], length: 58) antares.redesjm.local.53853 > zeppo.rediris.es.ftp: P [tcp sum ok] 348:354(6)ack 3604 win 33304 23:18:34.954132 IP (tos 0x0, ttl 53, id 64943, offset 0, flags [DF], length: 101) zeppo.rediris.es.ftp > antares.redesjm.local.53853: P 3604:3653(49) ack 354 win 24616 23:18:34.954477 IP (tos 0x0, ttl 64, id 54766, offset 0, flags [DF], length: 64) antares.redesjm.local.61346 > zeppo.rediris.es.35835: S [tcp sum ok] 3860012610:3860012610(0) win 65535 23:18:35.045985 IP (tos 0x0, ttl 64, id 54734, offset 0, flags [DF], length: 52) antares.redesjm.local.53853 > zeppo.rediris.es.ftp: . [tcp sum ok] 354:354(0)ack 3653 win 33304 23:18:37.946156 IP (tos 0x0, ttl 64, id 51670, offset 0, flags [DF], length: 64) antares.redesjm.local.61346 > zeppo.rediris.es.35835: S [tcp sum ok] 3860012610:3860012610(0) win 65535 23:18:41.146258 IP (tos 0x0, ttl 64, id 17586, offset 0, flags [DF], length: 64) antares.redesjm.local.61346 > zeppo.rediris.es.35835: S [tcp sum ok] 3860012610:3860012610(0) win 65535 23:18:44.346350 IP (tos 0x0, ttl 64, id 35811, offset 0, flags [DF], length: 48) antares.redesjm.local.61346 > zeppo.rediris.es.35835: S [tcp sum ok] 3860012610:3860012610(0) win 65535 23:18:47.546497 IP (tos 0x0, ttl 64, id 30435, offset 0, flags [DF], length: 48) antares.redesjm.local.61346 > zeppo.rediris.es.35835: S [tcp sum ok] 3860012610:3860012610(0) win 65535 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: about a usb adsl modem driver
El Viernes, 3 de Diciembre de 2004 17:50, Roman Kurakin escribió: > Jose M Rodriguez wrote: > >Hi, > > > >I've got a eagle usb adsl modem and get ready to work on FreeBSD > > support for it. > > [...] > > > >My first idea was a sppp based one, that can be ported to all xBSD. > > But now I think that a netgraph thing must be a better first > > contact. > > Note, with Netgraph you may use sppp via ng_sppp(4). Also it is not > to hard to > implement a dual driver. But I sugest to not do that way, especialy > if you want to > support multiple branches. I know how hard is that ;-). > (http://www.cronyx.ru/software/sigma.html) > If your implementation would work with sppp (via ng_sppp(4)) or you > would need > smth additional from sppp(4) let me know. > > rik > Well, this may depend of noted interest. I can work on RELENG_5_3 or RELENG_4, but I need some commiter that can take this into HEAD. I found Netgraph the easy path. A, let's say, ng_uadsl limited only to move aal5 between the modem and netgraph may be enough to use routed protocols, bridged mode, pppoe, pppoa, pptp, user-ppp, sppp, ... just with some equivalents of frame relay nodes and atm_llc, adapted to rfc2684. The hard part of this solution is that we need more userland work to sync all this stuff. Also, I noted that most of home adsl connections are of just only three categories: - IPv4 routed (generally LLC) - pppoe over ethernet bridge (Only LLC) - pppoa (generally VCMux, but also LLC) I think this can be taken by a sppp derived work. pppoa may be really direct (just PDU test/adjust), but the other need more work. IPv4 routed needs some kinda of bypass control, to use only the basic if interface after sppp. pppoe (only client) may be implemented in a single step with ethernet bridge encapsulation as a dial extension. Also, an auto mode for pppoe/pppoa-LLC/pppoa-VCMux may be implemented without too much problem (rotatory mode selection in sucesive dial attemps). Support form OpenBSD must be easy, but NetBSD is another story. This implementation is heavily affected by pppoe works and really differ from FreeBSD/OpenBSD. Also, the usb part needs works. A eagle implementation based on ueagle must be easy. but this driver is, right now, too much 'eagle oriented'. I'll prefer a 'ugen derived' model (used by net/pppoa). Or, at last, a more generic driver. This needs really 'too much manpower' that I can expend now. So, if noboby else have any more to say, I'll work it only two basic directions, time permitting: - a sppp based, pppoa only driver for eagle, derived from ueagle, for RELENG_5. - a ng_ueagle node for RELENG_5 derived from ueagle. thanks for your time, -- josemi ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: about a usb adsl modem driver
El Viernes, 3 de Diciembre de 2004 20:58, Andre Oppermann escribió: > Jose M Rodriguez wrote: > > El Viernes, 3 de Diciembre de 2004 17:50, Roman Kurakin escribió: > >>Jose M Rodriguez wrote: > >>>Hi, > >>> > >>>I've got a eagle usb adsl modem and get ready to work on FreeBSD > >>>support for it. > >>>[...] [...] > > I found Netgraph the easy path. A, let's say, ng_uadsl limited only > > to move aal5 between the modem and netgraph may be enough to use > > routed protocols, bridged mode, pppoe, pppoa, pptp, user-ppp, sppp, > > ... just with some equivalents of frame relay nodes and atm_llc, > > adapted to rfc2684. > > There is an extensive Netgraph ATM framework in FreeBSD 5.x written > by [EMAIL PROTECTED] The only thing you need to do is the hardware > driver for the ADSL USB modem. This one of the main reasons to 'go netgraph'. In fact, the actual ueagle driver uses NATM. But noted strong differences between atm boards and adsl modems. - atm boards are hardware assisted. usb adsl modems are bare assisted. - atm boards support better signaling, multiple channels, ... usb adsl modems just one PVC with uni signaling. So I realize that try to get a NATM/NETGRAPH hardware driver may be too work for little gain. Right now, I think that maintain a ng_uadsl closer enough to ng_atm must be a better solution. In other words, take harti work as a reference, but let uadsl independent of atm works. -- josemi ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: about a usb adsl modem driver
El Sábado, 4 de Diciembre de 2004 01:56, Bruce M Simpson escribió: > On Fri, Dec 03, 2004 at 09:25:56PM +0100, Jose M Rodriguez wrote: > > But noted strong differences between atm boards and adsl modems. > > > > - atm boards are hardware assisted. usb adsl modems are bare > > assisted. - atm boards support better signaling, multiple channels, > > ... usb adsl modems just one PVC with uni signaling. > > Not really. See below. > > > So I realize that try to get a NATM/NETGRAPH hardware driver may be > > too work for little gain. > > Actually writing a NATM driver is far easier than writing a HARP > driver. And Harti's newer drivers for ATM cards are, in fact, NATM > drivers. You only need to implement Netgraph hooks. You don't need to > worry about implementing Netgraph protocol nodes, generally. > I think so. The actual ueagle driver do that, only needs NetGraph aditions. My objections to implement NATM are related to the final operation. What you get througt NATM is of low interest for usb adsl users. You don't need signaling managers, multipe channels, ... I think that a direct, one PVC, usb adsl version of ng_atm will do the work. I think implement the netgraph support directly in the usb driver. About the rest of the ng_ nodes involved, I think the only problem is ng_atmllc. To be a generic aal5 frame diverter, it lacks some funtionality like VCMux support or ppp VcMux/LLC autoswitch. > You might want to contact Benno Rice, he was working on a software > AAL5 kernel module to augment netnatm, which would help if you're > targeting the lower end ADSL hardware. > My initial plans was implement this as part of the driver, but I no have any objections to this. But I'll prefer take this in the future, when we have a working driver (Well, another. ueagle really works on RELENG_5). Any pointer on this is welcome. -- josemi > Regards, > BMS ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD kernel pppd - mppe/mschapv1/2/radius support
El Sábado, 4 de Diciembre de 2004 23:19, Valentin Nechayev escribió: > Fri, Nov 26, 2004 at 13:24:31, anthonyv wrote about "FreeBSD kernel pppd - mppe/mschapv1/2/radius support": > > After extensively googling FreeBSD pppd's support for mppe, > > mschapv1, mschapv2 and radius, I've stumbled into a mess of patches > > for very random versions of pppd and FreeBSD. > > Does anyone have a running setup of FreeBSD's pppd with support for > > these features, or perhaps a patch that encompasses all of these > > features, making a complete solution? > > If not, any comments on the matter are still appreciated. (And > > yes, I've tried mpd and user-ppp, but neither one suits my needs > > sufficiently) > > MPPE isn't possible due to lack of support in kernel for PPP terminal > discipline. > For others, you can use port (net/pppd23) as base. This is the most > reasonable variant now (2.4 aren't ported to *BSD, 2.3.11 is last > 2.3) > Not really, NetBSD pppd is 2.4 based. -- josemi ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
[OT] aal5 pdu CRC
Hi, get some free time to work in uadsl, but have a problem. Hope someone that can read ITU I.363 can answer this. Every usb adsl modem implementation I see doesn't obey aal5 pdu encoding standards, which requires that the PDU trailer come at the begin of a fresh cell. So, I think that the modem must rework this and generate two cells on the wire. Due how this modems works, I doubt that the modem recalculate PDU CRC itself, So... Can someone confir if the CRC covers the PAD? I'm begin to think that the CRC only covers the playload and the pdu-trailer. -- josemi ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [OT] aal5 pdu CRC
El Jueves, 27 de Enero de 2005 16:10, Harti Brandt escribió: > On Thu, 27 Jan 2005, Jose M Rodriguez wrote: > > JMR>Hi, > JMR> > JMR>get some free time to work in uadsl, but have a problem. Hope someone > that JMR>can read ITU I.363 can answer this. > JMR> > JMR>Every usb adsl modem implementation I see doesn't obey aal5 pdu > encoding JMR>standards, which requires that the PDU trailer come at the > begin of a fresh JMR>cell. > > That is not true. The trailer must be on the END of a cell. Before the > trailer there will be padding bytes so that this happens. If, for example, > you have a one byte PDU the AAL5 PDU will consist of 1 byte information, > 39 bytes padding and 8 bytes trailer. > At last, rfc1483 and the received logic side seems to point that this is true. Most implementations sync the begin of a new PDU after detect the last cell by header test. Also, PDU lenght and crc is decode from a fixed ptr on the ENDPDU cell (lenght=cell[2]..cell[3], crc=cell[4]..cell[7]). > JMR> > JMR>So, I think that the modem must rework this and generate two cells on > the JMR>wire. Due how this modems works, I doubt that the modem > recalculate PDU CRC JMR>itself, So... > JMR> > JMR>Can someone confir if the CRC covers the PAD? I'm begin to think that > the CRC JMR>only covers the playload and the pdu-trailer. > > The CRC covers everything but the CRC. The PAD must be filled with zeros > though. > This is not so clean. This pad may be take as a cell pad or as a PDU pad. If this is take as a cell pad, it may not be part of the CRC (the ENDPDU cell is also paded from 8 to 48). My first guest is that the pad is part of the PDU, but I really doubt that the modem may be able to do a full CRC reclaculation. > harti -- josemi ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: VLAN Bridge with layer2 filtering
El Martes, 26 de Abril de 2005 09:56, Csaba Urban escribió: > Hi, > > I have a number of users on a VLAN enabled switch - each users on his > own VLAN. They have fixed IP address sharing the same IP subnet and > gateway. > I want to grant them access to the internet throug a FreeBSD box > which prevents them from communicating with each other in Layer2 > and which also prevents them to use other user's IP or MAC. I don't > want to use static ARP so it seems that best solution is a VLAN > enabled filtering bridge - in each VLAN only one certain IP address > is allowed. > A litle OT. Can this setup be achieve using pppoe over the VLANS? I don't have any experience using pppoe over vlans. -- josemi ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: PPP-layer Echo
El Miércoles, 27 de Abril de 2005 19:23, Crist J. Clark escribió:
> I want to do something rather simple, but a quick look at
> documentation ("man ppp") didn't give me an answer, and I'm
> rather pressed for time.
>
> All I want to do is send an echo-request and listen for the
> echo-reply at the PPP layer. Note that I am talking about
> pings _at the link layer,_ not IP layer pings. A quick look
> at the ppp(8) manpage didn't seem to indicate any tools for
> sending or receiving PPP-layer echoes. If ppp(8) doesn't have
> the ability, does anyone have any other _simple_ suggestions
> for doing this (e.g. dunno if it's worth writing a netgrap(4)
> node for this unless its really simple)?
>
This is FreeBSD-5.4RC3
man ppp ...
lqr
Default: Disabled and Accepted. This option decides if Link
Quality Requests will be sent or accepted. LQR is a protocol
that allows ppp to determine that the link is down without rely-
ing on the modems carrier detect. When LQR is enabled, ppp sends
the QUALPROTO option (see ``set lqrperiod'' below) as part of the
LCP request. If the peer agrees, both sides will exchange LQR
packets at the agreed frequency, allowing detailed link quality
monitoring by enabling LQM logging. If the peer doesn't agree,
and if the ``echo'' option is enabled, ppp will send LCP ECHO
requests instead. These packets pass no information of interest,
but they MUST be replied to by the peer.
Whether using LQR or LCP ECHO, ppp will abruptly drop the connec-
tion if 5 unacknowledged packets have been sent rather than send-
ing a 6th. A message is logged at the PHASE level, and any
appropriate ``reconnect'' values are honoured as if the peer were
responsible for dropping the connection.
Refer to the ``enable echo'' command description for differences
in behaviour prior to ppp version 3.4.2.
...
echo
Default: Disabled. When this option is enabled, ppp will send
LCP ECHO requests to the peer at the frequency defined by
``echoperiod''. Note, LQR requests will supersede LCP ECHO
requests if enabled and negotiated. See ``set lqrperiod'' below
for details.
Prior to ppp version 3.4.2, ``echo'' was considered enabled if
lqr was enabled and negotiated, otherwise it was considered dis-
abled. For the same behaviour, it is now necessary to ``enable
lqr echo'' rather than just ``enable lqr''.
...
echo is allways acepted, as this is part of lcp. You only need take a
look to the logs (/var/log/ppp.log, fyi).
Apr 28 07:07:14 antares ppp[785]: tun0: LCP: deflink:
RecvEchoRequest(98) state = Opened
Apr 28 07:07:14 antares ppp[785]: tun0: LCP: deflink: SendEchoReply(98)
state = Opened
Apr 28 07:07:44 antares ppp[785]: tun0: LCP: deflink:
RecvEchoRequest(99) state = Opened
Apr 28 07:07:44 antares ppp[785]: tun0: LCP: deflink: SendEchoReply(99)
state = Opened
Apr 28 07:08:15 antares ppp[785]: tun0: LCP: deflink:
RecvEchoRequest(100) state = Opened
Apr 28 07:08:15 antares ppp[785]: tun0: LCP: deflink: SendEchoReply(100)
state = Opened
Ap
--
josemi
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
enable dummynet from /etc/rc.d
Hi, This is FreeBSD-5.4 RC3 I'm working in a replacement rc.firewall script and found no /etc/rc.d method to launch dummynet (load module). Right now, dummynet is kernel based, but I want this be able to work from stock kernel (ipfw, ipfw6, dummynet from modules). I missed some rc.conf var or rc.d/ module? If this will be added, maybe /etc/rc.d/ipfw the right place? And what about firewall_dummynet for the controlling knob? -- josemi ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: enable dummynet from /etc/rc.d
El Lunes, 2 de Mayo de 2005 05:02, Giovanni P. Tirloni escribió: > Jose M Rodriguez wrote: > > Hi, > > > > This is FreeBSD-5.4 RC3 > > > > I'm working in a replacement rc.firewall script and found no > > /etc/rc.d method to launch dummynet (load module). > > > > Right now, dummynet is kernel based, but I want this be able to > > work from stock kernel (ipfw, ipfw6, dummynet from modules). > > > > I missed some rc.conf var or rc.d/ module? > > > > If this will be added, maybe /etc/rc.d/ipfw the right place? > > > > And what about firewall_dummynet for the controlling knob? > > It seems like a good idea. > > IMHO, you should create a 'dummynet' script in /etc/rc.d that > required ipfw (using rcorder(8)) keywords). And a dummynet_enable > option would make sense. > I can't see any need of and aditional dummynet script. I'm not running and aditional daemon (like the natd case), only loading a prerequired module when needed. > But how would you integrate with the ipfw rules ? You can kldload > ipfw and load ipfw rules, then kldload dummynet.. but what about the > dummynet rules order in this case ? > I can't see this point. ipfw rules are loaded from etc/rc.d/ipfw sourcing $firewall-script. The kernel must have dummynet functionality (in kernel or from module) before this is done if there're plans to use dummynet. This is allready done for the ipfw module here. > Your idea of changing /etc/rc.d/ipfw makes sense but, again, we've > the rules order problem and how that script is going to guess what > rules (dummynet) we don't want to load.. I Think this kind of functionality is diffrent. You're suppoused to define firewall_dummynet="YES" when you're using dummynet in $firewall-script. But it's to you put the rules here by other means. You can allways add in /etc/rc.conf: firewall_script="/etc/rc.firewall.local" and checkyesno $firewall_dummynet before do dummynet rules. -- josemi ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ipfw broken with bridge under 5.x (5.3 and 5.4)
El Miércoles, 4 de Mayo de 2005 16:24, Josef Karthauser escribió: > It appear that ipfw doesn't work with bridge in 5.3 and 5.4. The > symptoms are that the bridge stops forwarding packets altogether, > for me a few minutes after it is set up. It takes a > > # net.link.ether.bridge_ipfw=0 && sleep 5 && > net.link.ether.bridge_ipfw=1 > > to get it back up and running, which it does, but only for a few > minutes before it stops working again. The five second sleep is > sometimes too long, and sometimes not enough time. > > Would someone in the know be able to help me to trouble shoot it? > (I'm scared of ipfw! :). > > Thanks! > Joe Are your rules stopping arp or so? Remember make pass this kind of traffic at layer2. -- josemi ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ipfw broken with bridge under 5.x (5.3 and 5.4)
El Miércoles, 4 de Mayo de 2005 16:47, Jose M Rodriguez escribió: > El Miércoles, 4 de Mayo de 2005 16:24, Josef Karthauser escribió: > > It appear that ipfw doesn't work with bridge in 5.3 and 5.4. The > > symptoms are that the bridge stops forwarding packets altogether, > > for me a few minutes after it is set up. It takes a > > > > # net.link.ether.bridge_ipfw=0 && sleep 5 && > > net.link.ether.bridge_ipfw=1 > > > > to get it back up and running, which it does, but only for a few > > minutes before it stops working again. The five second sleep is > > sometimes too long, and sometimes not enough time. > > > > Would someone in the know be able to help me to trouble shoot it? > > (I'm scared of ipfw! :). > > > > Thanks! > > Joe > > Are your rules stopping arp or so? Remember make pass this kind of > traffic at layer2. > sorry, forgot the rule. Try something like this at the beginning of your ruleset: pass not ip from any to any layer2 -- josemi ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ipfw broken with bridge under 5.x (5.3 and 5.4)
On Wed, May 04, 2005 at 06:18:51PM +0100, Josef Karthauser wrote: > On Wed, May 04, 2005 at 06:13:22PM +0100, Gavin Atkinson wrote: > > > > I believe I am seeing similar problems to you, though uptime for me is > > generally measurable in days rather than minutes. I've found that > > adding an explicit "allow all from any to any" and then removing it > > again seems to get it working. I will test your solution when mine > > fails again. > > > > It appears that the solution is obtained by adding the rule: > > allow ip from any to any layer2 mac-type arp > > to the beginning of the firewall list. IPFW2 drops non-IP traffic > whereas IPFW1 passes it though. This is the reason why my configuration > stopped working after the upgrade. > What point me that we must solve the ip <-> all problem in ipfw2 ip from any to any match all traffic, not only ip. So this must be deprecated and all used instead. Also, this must be take in account when pretty-print is done. Apart of this, I'm still have problems with ipfw and rules without body: - skipto 3 + skipto 3 all from any to any -- josemi ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
tftpd blksize option for stock tftpd
Hi, I ports PR bin/67550 time ago, with minor fixes to tftpd protocol impl. and support for blksize option. Can someone review this before RELENG_6? Tested here with pxelinux clients. -- josemi ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Routes not deleted after link down
El Domingo, 19 de Junio de 2005 10:48, Michal Vanco escribió: > On Sunday 19 June 2005 10:29, Gleb Smirnoff wrote: > > On Sat, Jun 18, 2005 at 10:14:32PM +0200, Jose M Rodriguez wrote: > > J> Second, you may need a route daemon for this. ospf is a well > > known J> canditate where convergence in case of lost link is a > > must. > > > > While an OSPF daemon may stop advertising the affected route to its > > neighbors, the kernel will still have the route installed and thus > > the box won't be able to contact other hosts on the connected net, > > while they are reachable via alternate pass. > > Routing protocol should be responsible for removing affected routes > from FIB. For example quagga should remove all routes learned via > particular ospf neighbour when that neighbour is not reachable > anymore due to link goes down. But in case when no daemons are used > (`static' and `connected' are also `routing protocols'), kernel > should be responsible for doing that. > > > I've checked that Cisco routers remove route from FIB when > > interface link goes down. I haven't checked Junipers yet. > > Junipers do the same. It is the only feasible behaviour for router. > > > From my viewpoint, removing route (or marking it unusable) is a > > correct behavior for router. Not sure it is correct for desktop. > > Sure. > > > My vote is that we should implement this functionality and make it > > switchable via sysctl. I'd leave the default as is. > I'm not sure of this. I also think that a devd or monitor daemon will be enough and easy to implement. I think NetBSD have allready some kinda of net monitor daemon for pppoe support (via sppp). Not sure if route support is included. But seems easy and clean that a kernel based solution. -- josemi > Agree. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
nfe net driver for nfroce chipsets working on RELENG_6
Hi,
I'm using the nfe driver from current in RELENG_6 with a little patch
merge from openbsd cvs repo. Workking great on a home network (MCP51).
Due the fact that nve seems a dead end, are any plans to MFC the nfe
driver soon?
patch attached.
--
josemi
--- if_nfe.c.orig Sun Nov 12 23:52:01 2006
+++ if_nfe.cMon Nov 13 05:37:40 2006
@@ -1668,7 +1668,14 @@
bus_dmamap_t map;
bus_dma_segment_t segs[NFE_MAX_SCATTER];
int error, i, nsegs;
- u_int16_t flags = NFE_TX_VALID;
+ u_int16_t flags = 0, /* don't activate the first fragment */
+ *fflags; /* mark TX_VALID late */
+#if NVLAN > 0
+ u_int32_t vtag = 0;
+
+ if (m0->m_flags & M_VLANTAG)
+ vtag = htole32(NFE_TX_VTAG | m0->m_pkthdr.ether_vtag);
+#endif
map = sc->txq.data[sc->txq.cur].tx_data_map;
@@ -1686,15 +1693,11 @@
return ENOBUFS;
}
-
-#ifdef NFE_CSUM
- if (m0->m_pkthdr.csum_flags & CSUM_IP)
- flags |= NFE_TX_IP_CSUM;
- if (m0->m_pkthdr.csum_flags & CSUM_TCP)
- flags |= NFE_TX_TCP_CSUM;
- if (m0->m_pkthdr.csum_flags & CSUM_UDP)
- flags |= NFE_TX_TCP_CSUM;
-#endif
+ /* Take account of the first fragment */
+ if (sc->nfe_flags & NFE_40BIT_ADDR)
+ fflags = &sc->txq.desc64[sc->txq.cur].flags;
+ else
+ fflags = &sc->txq.desc32[sc->txq.cur].flags;
for (i = 0; i < nsegs; i++) {
data = &sc->txq.data[sc->txq.cur];
@@ -1709,9 +1712,9 @@
desc64->length = htole16(segs[i].ds_len - 1);
desc64->flags = htole16(flags);
#if NVLAN > 0
- if (m0->m_flags & M_VLANTAG)
- desc64->vtag = htole32(NFE_TX_VTAG |
- m0->m_pkthdr.ether_vtag);
+ desc64->vtag = vtag;
+ /* vtag belong to the first fragment only */
+ vtag = 0;
#endif
} else {
desc32 = &sc->txq.desc32[sc->txq.cur];
@@ -1721,26 +1724,34 @@
desc32->flags = htole16(flags);
}
- /* csum flags and vtag belong to the first fragment only */
- if (nsegs > 1) {
- flags &= ~(NFE_TX_IP_CSUM | NFE_TX_TCP_CSUM);
- }
+ /* Next fragments must be valid */
+ flags |= NFE_TX_VALID;
sc->txq.queued++;
sc->txq.cur = (sc->txq.cur + 1) % NFE_TX_RING_COUNT;
}
/* the whole mbuf chain has been DMA mapped, fix last descriptor */
- if (sc->nfe_flags & NFE_40BIT_ADDR) {
- flags |= NFE_TX_LASTFRAG_V2;
- desc64->flags = htole16(flags);
- } else {
- if (sc->nfe_flags & NFE_JUMBO_SUP)
- flags |= NFE_TX_LASTFRAG_V2;
- else
- flags |= NFE_TX_LASTFRAG_V1;
- desc32->flags = htole16(flags);
- }
+ if (sc->nfe_flags & NFE_40BIT_ADDR)
+ desc64->flags |= htole16(NFE_TX_LASTFRAG_V2);
+ else
+ desc32->flags |=
+ htole16((sc->nfe_flags & NFE_JUMBO_SUP)?
+ NFE_TX_LASTFRAG_V2:
+ NFE_TX_LASTFRAG_V1);
+
+ /* now do the first fragment with Checksum and TX valid */
+
+#ifdef NFE_CSUM
+ if (m0->m_pkthdr.csum_flags & CSUM_IP)
+ flags |= NFE_TX_IP_CSUM;
+ if (m0->m_pkthdr.csum_flags & CSUM_TCP)
+ flags |= NFE_TX_TCP_CSUM;
+ if (m0->m_pkthdr.csum_flags & CSUM_UDP)
+ flags |= NFE_TX_TCP_CSUM;
+#endif
+
+ *fflags |= htole16(flags);
data->m = m0;
data->active = map;
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
