Re: ENOBUFS
Petri Helenius wrote: The 900Mbps are similar to what I see here on similar hardware. What kind of receive performance do you observe? I haven´t got that far yet. Less :-) Let me tell you tomorrow, don't have the numbers here right now. 600Mbps per interface. I´m going to try this out also on -CURRENT to see if it changes anything. Interrupts do not seem to pose a big problem because I´m seeing only a few thousand em interrupts a second but since every packet involves a write call there are 100k syscalls a second. So maybe syscalls/second are the bottleneck. On -current, try enabling zero copy sockets, it seems to help somewhat. Other than that, I've not found -current to be much different in terms of performance. If you're just interested in maxing throughput, try sending over TCP with large write sizes. In that case, syscall overhead is less, since you amortize it over multiple packets. (But there are different issues that can limit TCP throughput.) I´ll try changing the packet sizes to figure out optimum. I think I remember that 4K packets were fastest with the em hardware in our case. Lars -- Lars Eggert [EMAIL PROTECTED] USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: RFC: eliminating the _IP_VHL hack.
In message [EMAIL PROTECTED], Garrett Wollman writes: Much better to delete the bogus BYTE_ORDER kluge from ip.h. (Note that the definition of the bitfields in question has nothing whatsoever to do with the actual byte order in use; it simply relies on the historical behavior of compilers which allocated space for bitfields in BYTE_ORDER order.) Do you intend to complete the task you originally started ? What is your plan for 3rd party software ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-net in the body of the message
Re: RFC: eliminating the _IP_VHL hack.
In message [EMAIL PROTECTED], Bruce Evans writes: On Tue, 15 Oct 2002, Jeffrey Hsu wrote: The side effect of having some source-files using the _IP_VHL hack and some not is that sizeof(struct ip) varies from file to file, which at best is confusing an at worst the source of some really evil bugs. There is no such effect, or ip would not work. s/,/ with our current compilers and architectures,/ I would therefore propose to eliminate the _IP_VHL hack from the kernel to end this state of (potential) confusion This would remove the least unportable version. Could be, but there is no point in us having two different versions, neither of which is guaranteed to be portable, in particular when one of the two is private to FreeBSD and not even consistently used there. For reference: NetBSD hasn't got the _IP_VHL but has a __packed__ on the structure. OpenBSD hasn't got the _IP_VHL either, but hasn't adopted the __packed__ from NetBSD. Linux also uses bitfields and endianess #ifdefs. These workarounds are even more unportable than bit-fields. However, there is no problem with struct ip yet, because everything is manually packed to work with all C compilers on all systems. This will break on systems with 64-bit ints, since sizeof(struct ip) == 20 is not a multiple of 8. Good point. I'll ammend my proposal to include a __packed__ and a CTASSERT on the size of struct ip == 20. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-net in the body of the message
RE: MPD PPTP tunneling intermittantly fails
I'm just using Windows clients, so there are no OS X clients.
Here's the ngctl output:
chung# ngctl msg ng0:inet.ppp.link0 getstats
Rec'd response getstats (3) from ng0:inet.ppp.link0:
Args: { xmitPackets=1967 xmitOctets=209321 xmitLoneAcks=395 xmitDrops=345
recvPackets=1590 recvOctets=248518 recvAckTimeouts=55 }
As you can tell, the connection hasn't transmitted much data before it's
already become problematic. The drop count to packet count on transmits and
timeouts on recv's seems awfully high given everything is just on a local
area network. Here's my physical topology:
Inside 10.0.0.0/8 {10.0.0.1 - MPD Machine - 192.168.0.1}
--- 192.168.0.0/24 Protected clients
|
| Outside Internet
IP
-
Each net address on the MPD machine has its own Ethernet card. In addition,
pinging the MPD machine from either side results in no packet loss and 1ms
latency.
Here's some more information if that helps:
chung# kldstat
Id Refs AddressSize Name
1 10 0xc010 2bce78 kernel
29 0xc0b71000 9000 netgraph.ko
31 0xc0b7a000 3000 ng_socket.ko
41 0xc0b7d000 3000 ng_iface.ko
51 0xc0b8 6000 ng_ppp.ko
61 0xc0b86000 4000 ng_bpf.ko
71 0xc0b8a000 4000 ng_vjc.ko
81 0xc0b8e000 4000 ng_pptpgre.ko
91 0xc0b93000 4000 ng_ksocket.ko
101 0xc0b98000 3000 ng_mppc.ko
chung# uname -a
FreeBSD chung.yikes.com 4.6.2-RELEASE FreeBSD 4.6.2-RELEASE #0: Wed Aug 28
00:07:12 PDT 2002
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/CHUNG_KERN_FW i386
Thanks for your help,
Leonard
-Original Message-
From: Archie Cobbs [mailto:[EMAIL PROTECTED]]
Sent: Monday, October 14, 2002 2:44 PM
To: Leonard Chung
Cc: [EMAIL PROTECTED]
Subject: Re: MPD PPTP tunneling intermittantly fails
Leonard Chung writes:
The problem that I'm having is that MPD starts properly and I can
successfully connect to the service using Windows clients. However, when I
ping internal hosts, the first five or so work fine, and then beyond that
packets start getting lost, with a loss rate of around 50%. These tests
are
run over a local network with two subnets, so packet loss shouldn't be a
problem. So although I can currently connect and create a tunnel, it isn't
very useful as beyond any initial DNS queries, file transfers, etc. fail
completely.
Are you using Mac OS X clients? If so, you may need the
latest patch to ng_pptpgre(4) to work around a problem:
http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netgraph/ng_pptpgre.c.diff?r1=
1.25r2=1.26
Otherwise, I haven't heard of anyone else having that particular problem..
See if you have errors reported by 'ngctl msg ng0:inet.ppp.link0 getstats'
(replace 'ng0' with the appropriate inteface name).
Also, is there any way to get DHCP to work with MPD rather than hard wire
IPs directly into MPD's config files?
Unfortunately not.
I'm guessing this is probably just something easy that I'm missing. My
config files and an MPD trace are below.
These look reasonable.
-Archie
__
Archie Cobbs * Packet Design * http://www.packetdesign.com
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-net in the body of the message
Re: CFR: m_tag patch
On Fri, 11 Oct 2002 11:12:02 -0700,
Sam Leffler [EMAIL PROTECTED] said:
struct m_tag {
SLIST_ENTRY(m_tag) m_tag_link; /* List of packet tags
*/
u_int16_t m_tag_id; /* Tag ID */
u_int16_t m_tag_len; /* Length of data */
u_int32_t m_tag_cookie; /* Module/ABI */
};
(snip)
Sorry for interrupting, but please let me make it sure. Do you intend
to hide the additional member from other modules than the m_tag
internal? I'm afraid a story that (e.g.) some code fragments in the
network layer directly refers to m_tag_cookie, which will break source
level compatibility with other BSDs (when the code fragments are
shared with others). As suz said before, we (KAME) are very much
afraid of this kind of story.
The changes I'm proposing for KAME code make no references to m_tag_cookie.
Things should be clear when you have a patch to look at.
I know that, but what I'm worrying about is a story that *.c under
netinet[6] will have a direct reference to m_tag_cookie *in the
future. Then we'll need to separate the code fragments like this:
#if defined(__FreeBSD__) __FreeBSD__ = 5
if (mtag-m_tag_cookie != PACKET_TAG_IPSEC_OUT_DONE
mtag-m_tag_cookie !=
PACKET_TAG_IPSEC_OUT_CRYPTO_NEEDED)
continue;
#else
if (mtag-m_tag_id != PACKET_TAG_IPSEC_OUT_DONE
mtag-m_tag_id !=
PACKET_TAG_IPSEC_OUT_CRYPTO_NEEDED)
continue;
#endif
(derived from the current KAME's ip6_output.c)
We've experienced a lot of headaches due to this type of
incompatibility. I fully understand that once some changes are
incorporated to a particular BSD, the BSD developers are free to
modify the code based on their local policy, even if the result
introduces the incompatibility with other BSDs. Of course, there
should be a reason for the modification, and the change may provide a
better behavior. So, I can only ask, please understand our position
(that needs to handle all *BSDs) and consider a compromise.
I'm working on
getting that to you.
Yes, I noticed that, thanks. I'll take a closer look at it later.
JINMEI, Tatuya
Communication Platform Lab.
Corporate RD Center, Toshiba Corp.
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-net in the body of the message
Re: cvs commit: src/sys/dev/kbd atkbdcreg.h
In message [EMAIL PROTECTED], Bruce Evans writes: This kind of bug is a _really_ horribly thing as we end up with one bit of code thinking a particular structure is 136 bytes and another that it is only 112 bytes. Ideally all places would remember to #include the right opt_foo.h file, but I think in practice file containing the variable sized struct should #include it explicitly as a precaution. Ideally, header files wouldn't have any variable sized structs or anything else that depends on options. Core headers have to be much more careful about this because including an options header nested would break most modules and everything outside of the kernel (apart from the bug that modules and things outside of the kernel have no way to determine the correct value for the option). I agree. Suggestions for the best way of fixing struct ipq in ip_var.h hereby solicited. I can see that MAC just unceremonously put their own field in there, and I guess that is the most sensible thing to do, despite the RAM this may cost during a DoS attack. Objections to this patch: Index: ip_var.h === RCS file: /home/ncvs/src/sys/netinet/ip_var.h,v retrieving revision 1.66 diff -u -r1.66 ip_var.h --- ip_var.h16 Oct 2002 01:54:44 - 1.66 +++ ip_var.h16 Oct 2002 07:35:44 - @@ -68,10 +68,8 @@ u_short ipq_id; /* sequence id for reassembly */ struct mbuf *ipq_frags; /* to ip headers of fragments */ struct in_addr ipq_src,ipq_dst; -#ifdef IPDIVERT u_int32_t ipq_div_info; /* ipfw divert port flags */ u_int16_t ipq_div_cookie; /* ipfw divert cookie */ -#endif struct label ipq_label; /* MAC label */ }; #endif /* _KERNEL */ -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-net in the body of the message
dynamic load of em/fxp/bge
I am trying to load the if_em, if_fxp, if_bge drivers via /boot/loader.conf. I've added if_fxp_load=YES if_bge_load=YES if_em_load=YES The problem is that the bge driver doesn't load. It will if I manually load it after startup with kldload. The issue seems to be a dependency on miibus, both fxp and bge want to load it, bge gets an error that its already loaded. I tried putting 'miibus_load=YES' in loader.conf, but the same affect is seen. I've tried from the boot prompt doing an explicit load of these manually in each order, but to no avail. As a work-around, I've placed an kldload if_bge in rc.network before the 'ifconfig -l'. Any suggestions on why the fxp/bge don't play nice when loaded automatically, but will work if run manually? Is there a timing thing that the fxp hasn't initialised its miibus yet? I have: fxp0 fxp1 bge0 in this particular machine. The bge will get miibus2 (eventually), leaving fxp0 to have miibus0, fxp1 to have miibus1 I think. Suggestions? --don To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-net in the body of the message
Re: ENOBUFS
On Wed, Oct 16, 2002 at 08:57:19AM +0300, Petri Helenius wrote: how large are the packets and how fast is the box ? Packets go out at an average size of 1024 bytes. The box is dual P4 Xeon 2400/400 so I think it should qualify as fast ? I disabled yes, it qualifies as fast. With this kind of box, a trivial program can send short (18 byte payload, 64 byte total) UDP frames at 5-600kpps, with quite a bit of time i suspect is being spent in the userland-kernel transition (with some tricks to skip that i went up to ~680kpps). The information I´m looking for is how to instrument where the hard to tell -- see if short packets you get the same performance i mention above, then maybe try some tricks such as sending short bursts (5-10 pkts at a time) on each of the interfaces. Maybe using a UP kernel as opposed to an SMP one might give you slightly better performance, i am not sure though. There might be some minor optimizations here and there which could possibly help (e.g. make th em driver use m_getcl(), remove IPSEC from the kernel if you have it) but you are essentially close to the speed you can get with that box (within a factor of 2, probably). cheers luigi on a fast box you should be able to generate packets faster than wire speed for sizes around 500bytes, meaning that you are going to saturate the queue no matter how large it is. cheers luigi em-interface is running 66/64 and is there a way to see interface queue depth? em0: Intel(R) PRO/1000 Network Connection, Version - 1.3.14 port 0x3040-0x307f mem 0xfc22-0xfc23 irq 17 at device 3.0 on pci2 em0: Speed:1000 Mbps Duplex:Full pcib2: PCI to PCI bridge (vendor=8086 device=1460) at device 29.0 on pci1 IOAPIC #2 intpin 0 - irq 16 IOAPIC #2 intpin 6 - irq 17 IOAPIC #2 intpin 7 - irq 18 pci2: PCI bus on pcib2 The OS is 4.7-RELEASE. Pete To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-net in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-net in the body of the message
Re: CFR: m_tag patch
Actually from what i have read on previous postings on this thread,
the only additional check that you might/will need is to make sure
that m_tag_cookie corresponds to the GENERIC ABI.
Also note that in your example the code should be conditional
on __FreeBSD_version and not on __FreeBSD__
cheers
luigi
On Wed, Oct 16, 2002 at 07:03:33PM +0900, JINMEI Tatuya / ?$B?@L@C#:H?(B wrote:
...
Sam Leffler [EMAIL PROTECTED] said:
struct m_tag {
SLIST_ENTRY(m_tag) m_tag_link; /* List of packet tags
*/
u_int16_t m_tag_id; /* Tag ID */
u_int16_t m_tag_len; /* Length of data */
u_int32_t m_tag_cookie; /* Module/ABI */
};
(snip)
Sorry for interrupting, but please let me make it sure. Do you intend
to hide the additional member from other modules than the m_tag
internal? I'm afraid a story that (e.g.) some code fragments in the
network layer directly refers to m_tag_cookie, which will break source
level compatibility with other BSDs (when the code fragments are
shared with others). As suz said before, we (KAME) are very much
afraid of this kind of story.
The changes I'm proposing for KAME code make no references to m_tag_cookie.
Things should be clear when you have a patch to look at.
I know that, but what I'm worrying about is a story that *.c under
netinet[6] will have a direct reference to m_tag_cookie *in the
future. Then we'll need to separate the code fragments like this:
#if defined(__FreeBSD__) __FreeBSD__ = 5
if (mtag-m_tag_cookie != PACKET_TAG_IPSEC_OUT_DONE
mtag-m_tag_cookie !=
PACKET_TAG_IPSEC_OUT_CRYPTO_NEEDED)
continue;
#else
if (mtag-m_tag_id != PACKET_TAG_IPSEC_OUT_DONE
mtag-m_tag_id !=
PACKET_TAG_IPSEC_OUT_CRYPTO_NEEDED)
continue;
#endif
(derived from the current KAME's ip6_output.c)
We've experienced a lot of headaches due to this type of
incompatibility. I fully understand that once some changes are
incorporated to a particular BSD, the BSD developers are free to
modify the code based on their local policy, even if the result
introduces the incompatibility with other BSDs. Of course, there
should be a reason for the modification, and the change may provide a
better behavior. So, I can only ask, please understand our position
(that needs to handle all *BSDs) and consider a compromise.
I'm working on
getting that to you.
Yes, I noticed that, thanks. I'll take a closer look at it later.
JINMEI, Tatuya
Communication Platform Lab.
Corporate RD Center, Toshiba Corp.
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-net in the body of the message
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-net in the body of the message
Re: cvs commit: src/sys/dev/kbd atkbdcreg.h
Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Bruce Evans writes: Ideally, header files wouldn't have any variable sized structs or anything else that depends on options. Core headers have to be much more careful about this because including an options header nested would break most modules and everything outside of the kernel (apart from the bug that modules and things outside of the kernel have no way to determine the correct value for the option). I agree. Suggestions for the best way of fixing struct ipq in ip_var.h hereby solicited. Please use a union; things like diversion information result in other information not being used. It makes no sense to uniformly bloat all memory allocations for minority features, merely for the sake of uniformity. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-net in the body of the message
RE: ENOBUFS
Sam Leffler wrote: Try my port of the netbsd kttcp kernel module. You can find it at http://www.freebsd.org/~sam this seems to use some things from netbsd like so_rcv.sb_lastrecord and SBLASTRECORDCHK/SBLASTMBUFCHK. Is there something else I need to apply to build it on freebsd -STABLE? --don ([EMAIL PROTECTED] www.sandvine.com) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-net in the body of the message
Re: ENOBUFS
Sam Leffler wrote: Try my port of the netbsd kttcp kernel module. You can find it at http://www.freebsd.org/~sam this seems to use some things from netbsd like so_rcv.sb_lastrecord and SBLASTRECORDCHK/SBLASTMBUFCHK. Is there something else I need to apply to build it on freebsd -STABLE? Sorry, I ported Jason's tail pointer stuff to -stable before kttcp so it assumes that's installed. If you don't want to redo kttcp you might try applying thorpe-stable.patch from the same directory. FWIW I've been running with that patch in my production systems for many months w/o incident. I never committed it because I didn't see noticeable performance improvements. Sam To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-net in the body of the message
mpd - Radius
Hi, I'm now evaluating if its difficult to extend mpd with radius authentication (with libradius). I have some questions: 1. Will be in auth.c the function AuthGetData() the right place to put Radius stuff? 2. What was the intention behind the function CustomAuthData()? 3. How should radius configured in the mpd.conf, is something like: set bundle radius /etc/radius.conf ok? bye, -- -- -- E-mail: [EMAIL PROTECTED] JAWA Management Software GmbH Liebenauer Hauptstr. 200 A-8041 GRAZ Tel: ++43-(0)316-403274-12 Fax: ++43-(0)316-403274-10 GSM: ++43-(0)676-93 96 698 homepage: http://www.jawa.at - privat --- E-mail: [EMAIL PROTECTED] homepage: http://www.inode.at/mbretter -- To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-net in the body of the message
Re: CFR: m_tag patch
On Wed, 16 Oct 2002 07:46:10 -0700, Luigi Rizzo [EMAIL PROTECTED] said: Actually from what i have read on previous postings on this thread, the only additional check that you might/will need is to make sure that m_tag_cookie corresponds to the GENERIC ABI. (I re-read the thread) perhaps the example in my previous message wasn't good (and it was at least incorrect). According to the discussion on the thread, we'll probably keep m_tag_cookie being 0 and use m_tag_id in (e.g.) ip6_output.c. So, we'll be happy if this convention is kept (and will be kept) at least under netinet6. It would be good to make more explicit comments on the intended usage, not just a single comment for the m_tag_cookie member: u_int32_t m_tag_cookie; /* Module/ABI */ Also note that in your example the code should be conditional on __FreeBSD_version and not on __FreeBSD__ We (KAME) actually need __FreeBSD__, because we want to keep a single code base for all *BSDs (again, I know this is our local issue). But, whether or not we need __FreeBSD__ (in addition to __FreeBSD_version) is a minor point. From our point view, we do want to avoid any ifdef for separating different *BSDs. Thanks, JINMEI, Tatuya Communication Platform Lab. Corporate RD Center, Toshiba Corp. [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-net in the body of the message
Re: CFR: m_tag patch
On Thu, Oct 17, 2002 at 03:07:07AM +0900, JINMEI Tatuya / ?$B?@L@C#:H?(B wrote: ... (I re-read the thread) perhaps the example in my previous message wasn't good (and it was at least incorrect). According to the discussion on the thread, we'll probably keep m_tag_cookie being 0 and use m_tag_id in (e.g.) ip6_output.c. So, we'll be happy if this convention is kept (and will be kept) at least under netinet6. unfortunately this will not prevent code from having to check that the m_tag_cookie actually corresponds to the value you want, to make sure that your code does not misinterpret as own tags generated/destined to other clients. Am I correct, Sam ? Correct. If you explicitly look inside the m_tag structure instead of using one of the m_tag_* routines to search then you will need to validate m_tag_cookie to avoid interpreting tags created by other modules. The comments I wrote in mbuf.h for this stuff describe this and say that when writing code that is to be compatible with other systems one should always use MTAG_ABI_COMPAT and the openbsd-compatible m_tag_get and m_tag_find routines. m_tag_cookie was mainly added so that netgraph could piggyback on top of the facility and remove it's private code. At some point it may be worthwhile to talk with the openbsd+netbsd folks about adopting this new m_tag facility. Sam To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-net in the body of the message
Re: CFR: m_tag patch
On Wed, 16 Oct 2002, Luigi Rizzo wrote: On Thu, Oct 17, 2002 at 03:07:07AM +0900, JINMEI Tatuya / ?$B?@L@C#:H?(B wrote: ... (I re-read the thread) perhaps the example in my previous message wasn't good (and it was at least incorrect). According to the discussion on the thread, we'll probably keep m_tag_cookie being 0 and use m_tag_id in (e.g.) ip6_output.c. So, we'll be happy if this convention is kept (and will be kept) at least under netinet6. unfortunately this will not prevent code from having to check that the m_tag_cookie actually corresponds to the value you want, to make sure that your code does not misinterpret as own tags generated/destined to other clients. Am I correct, Sam ? yes but this is always done with macros, and the OpenBSD compatible macros also check for the correct cookie value. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-net in the body of the message
Re: mpd - Radius
Hi, Julian Elischer wrote: On Wed, 16 Oct 2002, Michael Bretterklieber wrote: Hi, I'm now evaluating if its difficult to extend mpd with radius authentication (with libradius). I have some questions: 1. Will be in auth.c the function AuthGetData() the right place to put Radius stuff? No. I wrote a small program wich is able to make radius-auth. Now I'm integrating it into mpd and auth.c is the wrong place. The right place will be pap.c or chap.c or ... 2. What was the intention behind the function CustomAuthData()? mpd was written for use in the InterJet, which had a separate database controlling everything. you could hook in to that database using that (from memory) Archie wil answer I'm sure and give more info.. also check how 'ppp' does it's radius stuff. yes, I took many things from ppp. No I'm trying for the first shot only to make pap-auth with radius. 3. How should radius configured in the mpd.conf, is something like: set bundle radius /etc/radius.conf ok? bye, -- -- -- E-mail: [EMAIL PROTECTED] JAWA Management Software GmbH Liebenauer Hauptstr. 200 A-8041 GRAZ Tel: ++43-(0)316-403274-12 Fax: ++43-(0)316-403274-10 GSM: ++43-(0)676-93 96 698 homepage: http://www.jawa.at - privat --- E-mail: [EMAIL PROTECTED] homepage: http://www.inode.at/mbretter -- To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-net in the body of the message -- -- -- E-mail: [EMAIL PROTECTED] JAWA Management Software GmbH Liebenauer Hauptstr. 200 A-8041 GRAZ Tel: ++43-(0)316-403274-12 Fax: ++43-(0)316-403274-10 GSM: ++43-(0)676-93 96 698 homepage: http://www.jawa.at - privat --- E-mail: [EMAIL PROTECTED] homepage: http://www.inode.at/mbretter -- To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-net in the body of the message
Re: mpd - Radius
Hi, Now I got pap-radius-auth with mpd to work :-) I made it now with a static define. The next step will be to add the appropriate config-param for mpd.conf. Are there any hints, a small howto would be great? Something like: - naming conventions of param - where to add param - how to access param bye, Julian Elischer wrote: On Wed, 16 Oct 2002, Michael Bretterklieber wrote: Hi, I'm now evaluating if its difficult to extend mpd with radius authentication (with libradius). I have some questions: 1. Will be in auth.c the function AuthGetData() the right place to put Radius stuff? 2. What was the intention behind the function CustomAuthData()? mpd was written for use in the InterJet, which had a separate database controlling everything. you could hook in to that database using that (from memory) Archie wil answer I'm sure and give more info.. also check how 'ppp' does it's radius stuff. 3. How should radius configured in the mpd.conf, is something like: set bundle radius /etc/radius.conf ok? bye, -- -- -- E-mail: [EMAIL PROTECTED] JAWA Management Software GmbH Liebenauer Hauptstr. 200 A-8041 GRAZ Tel: ++43-(0)316-403274-12 Fax: ++43-(0)316-403274-10 GSM: ++43-(0)676-93 96 698 homepage: http://www.jawa.at - privat --- E-mail: [EMAIL PROTECTED] homepage: http://www.inode.at/mbretter -- To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-net in the body of the message -- -- -- E-mail: [EMAIL PROTECTED] JAWA Management Software GmbH Liebenauer Hauptstr. 200 A-8041 GRAZ Tel: ++43-(0)316-403274-12 Fax: ++43-(0)316-403274-10 GSM: ++43-(0)676-93 96 698 homepage: http://www.jawa.at - privat --- E-mail: [EMAIL PROTECTED] homepage: http://www.inode.at/mbretter -- To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-net in the body of the message
xl driver and POLLING
Has there been any work done on adding POLLING support to the xl driver? -- Darcy Buskermolen Wavefire Technologies Corp. ph: 250.717.0200 fx: 250.763.1759 http://www.wavefire.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-net in the body of the message
Re: xl driver and POLLING
http://gosho.interbgc.com/if_xl.c.diff - Original Message - From: Darcy Buskermolen [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, October 17, 2002 12:31 AM Subject: xl driver and POLLING Has there been any work done on adding POLLING support to the xl driver? -- Darcy Buskermolen Wavefire Technologies Corp. ph: 250.717.0200 fx: 250.763.1759 http://www.wavefire.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-net in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-net in the body of the message
possible routed bug
Hi,
I've encountered a possible bug in routed code that's interfering
with path mtu discovery mechanism. Routed deletes any cloned route
as soon as it sees one (with exception of arp routes in the local
ethernet), including protocol cloned routes served as holders for
path mtu information. Could anyone confirm this is not an intended
behavior?
This symptom of this bug is the breakdown of the pmtu discovery
process. It is easily reproduced with a machine behind a PPPoE
router (or any router limits MTU to below 1500) and running routed.
With this seutp, send an email larger than 1500 to your friend at
stanford or mit, you will find the email couldn't be delivered.
Start tcpdump and watch your email and icmp traffic, you will see
an icmp response ICMP_NEEDFRAG for the first 1500-byte tcp packet,
but *NO* immediate retransmission with reduced packet size in
response to the icmp message, the next retransmission will occur
10ms later when the retransmit timer expires and with the same 1500
byte packet.
Following is my proposed fix. Basically treat the protocol cloned
routes the same way as we treat arp routes (in fact also cloned),
that is, ignore them.
Index: table.c
===
RCS file: /home/ncvs/src/sbin/routed/table.c,v
retrieving revision 1.16
diff -u -r1.16 table.c
--- table.c 18 Feb 2002 20:35:19 - 1.16
+++ table.c 16 Oct 2002 18:33:53 -
@@ -,9 +,9 @@
continue;
/* ignore ARP table entries on systems with a merged route
-* and ARP table.
+* and ARP table, or any other cloned routes
*/
- if (rtm-rtm_flags RTF_LLINFO)
+ if (rtm-rtm_flags (RTF_LLINFO | RTF_WASCLONED))
continue;
/* ignore multicast addresses
@@ -1259,6 +1259,11 @@
if (m.r.rtm.rtm_flags RTF_LLINFO) {
trace_act(ignore ARP %s, str);
+ continue;
+ }
+
+ if (m.r.rtm.rtm_flags RTF_WASCLONED) {
+ trace_act(ignore clone %s, str);
continue;
}
Thanks
-lq
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-net in the body of the message
Re: mpd - Radius
Hi, mpd - basic radius (pap only) support now finished, see attachements. two new files: radius.h radius.c four modified files: Makefile bund.h bund.c pap.c (I hope I got all changes files) You can activate radius by adding this config-param: set bundle radius /etc/radius.conf you have to remove the comment in the Makefile from RADIUS_AUTH=yes. bye, Michael Bretterklieber wrote: Hi, Now I got pap-radius-auth with mpd to work :-) I made it now with a static define. The next step will be to add the appropriate config-param for mpd.conf. Are there any hints, a small howto would be great? Something like: - naming conventions of param - where to add param - how to access param bye, Julian Elischer wrote: On Wed, 16 Oct 2002, Michael Bretterklieber wrote: Hi, I'm now evaluating if its difficult to extend mpd with radius authentication (with libradius). I have some questions: 1. Will be in auth.c the function AuthGetData() the right place to put Radius stuff? 2. What was the intention behind the function CustomAuthData()? mpd was written for use in the InterJet, which had a separate database controlling everything. you could hook in to that database using that (from memory) Archie wil answer I'm sure and give more info.. also check how 'ppp' does it's radius stuff. 3. How should radius configured in the mpd.conf, is something like: set bundle radius /etc/radius.conf ok? bye, -- -- -- E-mail: [EMAIL PROTECTED] JAWA Management Software GmbH Liebenauer Hauptstr. 200 A-8041 GRAZ Tel: ++43-(0)316-403274-12 Fax: ++43-(0)316-403274-10 GSM: ++43-(0)676-93 96 698 homepage: http://www.jawa.at - privat --- E-mail: [EMAIL PROTECTED] homepage: http://www.inode.at/mbretter -- To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-net in the body of the message -- -- -- E-mail: [EMAIL PROTECTED] JAWA Management Software GmbH Liebenauer Hauptstr. 200 A-8041 GRAZ Tel: ++43-(0)316-403274-12 Fax: ++43-(0)316-403274-10 GSM: ++43-(0)676-93 96 698 homepage: http://www.jawa.at - privat --- E-mail: [EMAIL PROTECTED] homepage: http://www.inode.at/mbretter -- mpd_radius.tar.gz Description: application/gzip
RFC: BSD network stack virtualization
Hi all, on http://www.tel.fer.hr/zec/BSD/vimage/ you can find the patches against 4.7-RELEASE kernel sources, which provide the functionality of maintaining multiple independent network stack images within a single operating system kernel. No userland patches are necessary, except an additional virtual image management utility. Within a patched kernel, every process and network interface belongs to an unique virtual image, which provides the independent: - set of network interfaces and userland processes; - interface addresses and routing tables; - TCP, UDP, raw protocol control blocks; - network traffic counters / statistics; - set of net.inet tunable sysctl variables; - ipfw and dummynet instance; - system load and CPU usage accounting and scheduling From the userland perspective, all the virtualization modifications within the kernel have been designed to preserve the complete API/ABI compatibility, so absolutely all existing userland binaries should be able to run unmodified on the virtualized kernel. There are many possible applications of having multiple independent instances of the network stack within a single kernel, just to mention VPN provisioning, virtual hosting, and network simulation... I'd be glad to hear your comments on the code and suggestions for the further development. Have fun! Marko To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-net in the body of the message
Re: mpd - Radius
Michael Bretterklieber writes: Now I got pap-radius-auth with mpd to work :-) Cool! You may want to contact Brendan Bank [EMAIL PROTECTED] because he's also working on mpd+RADIUS. It would be nice if you two could coordinate and maybe review each other's code... I made it now with a static define. The next step will be to add the appropriate config-param for mpd.conf. Are there any hints, a small howto would be great? Something like: - naming conventions of param - where to add param - how to access param Probably these should be bundle-level commands, right? You can use the examples that already exist as a starting point. Cheers, -Archie __ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-net in the body of the message
Re: MPD PPTP tunneling intermittantly fails
Leonard Chung writes:
I'm just using Windows clients, so there are no OS X clients.
Here's the ngctl output:
chung# ngctl msg ng0:inet.ppp.link0 getstats
Rec'd response getstats (3) from ng0:inet.ppp.link0:
Args: { xmitPackets=1967 xmitOctets=209321 xmitLoneAcks=395 xmitDrops=345
recvPackets=1590 recvOctets=248518 recvAckTimeouts=55 }
That doesn't look so good. But it doesn't look crazy from the
netgraph side, just like a lot of packets are being dropped.
There must be something specific about your setup that causes this.
You're using 4.6.2? Try applying all of the patches in sys/netgraph
that are in 4.7-REL that you don't have in 4.6.2... ?
-Archie
__
Archie Cobbs * Packet Design * http://www.packetdesign.com
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-net in the body of the message
Patch for review: only report protocol data via EVFILT_READ filter
Currently, the value returned in a kevent's data member by the
EVFILT_READ filter is number of bytes in the socket buffer which
includes control and out-of-band data. However, this isn't particularly
useful as any read(), readv(), or readmsg() for the amount of data
reported may block if there is any non-protocol data in the buffer. And
being that there is no way for userland applications to determine if, and
if so how much, non-protocol data is in the buffer, the reported value
cannot be trusted for anything useful.
PR 30634 touches on this issue; UDP sockets are particularly visible
examples since they always include 16 bytes of address information in
addition to the datagram received. However, from reading the code it
would appear that OOB data can cause a similar problem for TCP sockets.
It seems that the overriding issue is that the read* API takes the
number of bytes of protocol data to read whereas kevent() reports the
total number of bytes available (protocol or administrative). The
attached patch, which I would appreciate your comments on, modifies
kevent() to report just the number of bytes of protocol data.
As an aside, it appears that the FIONREAD ioctl (sys_socket.c:soo_ioctl)
and stat(2) on a socket (sys_socket.c:soo_stat) also return the total
number of bytes (protocol data other otherwise) in the socket buffer.
For similar reasons as described above, I suspect that these should be
also modified to return just the number of bytes of actual data. Unless
someone knows of an explicit example otherwise, I don't think changing the
value reported via these interfaces would break any existing applications
as they are probably expecting the new behaviour anyway.
Thanks,
Kelly
(P.S. I've already sent a version of this patch, made against -stable,
to Jonathan, but I haven't heard anything from him in almost a week)
--
Kelly Yancey -- kbyanc@{posi.net,FreeBSD.org}
Index: sys/socketvar.h
===
RCS file: /home/ncvs/src/sys/sys/socketvar.h,v
retrieving revision 1.94
diff -u -p -r1.94 socketvar.h
--- sys/socketvar.h 17 Aug 2002 02:36:16 - 1.94
+++ sys/socketvar.h 16 Oct 2002 21:34:13 -
-105,6 +105,7 struct socket {
u_int sb_hiwat; /* max actual char count */
u_int sb_mbcnt; /* chars of mbufs used */
u_int sb_mbmax; /* max chars of mbufs to use */
+ u_int sb_ctl; /* non-data chars in buffer */
int sb_lowat; /* low water mark */
int sb_timeo; /* timeout for read/write */
short sb_flags; /* flags, see below */
-227,6 +228,8 struct xsocket {
/* adjust counters in sb reflecting allocation of m */
#definesballoc(sb, m) { \
(sb)-sb_cc += (m)-m_len; \
+ if ((m)-m_type != MT_DATA) \
+ (sb)-sb_ctl += (m)-m_len; \
(sb)-sb_mbcnt += MSIZE; \
if ((m)-m_flags M_EXT) \
(sb)-sb_mbcnt += (m)-m_ext.ext_size; \
-235,6 +238,8 struct xsocket {
/* adjust counters in sb reflecting freeing of m */
#definesbfree(sb, m) { \
(sb)-sb_cc -= (m)-m_len; \
+ if ((m)-m_type != MT_DATA) \
+ (sb)-sb_ctl -= (m)-m_len; \
(sb)-sb_mbcnt -= MSIZE; \
if ((m)-m_flags M_EXT) \
(sb)-sb_mbcnt -= (m)-m_ext.ext_size; \
Index: kern/uipc_socket.c
===
RCS file: /home/ncvs/src/sys/kern/uipc_socket.c,v
retrieving revision 1.132
diff -u -p -r1.132 uipc_socket.c
--- kern/uipc_socket.c 5 Oct 2002 21:23:46 - 1.132
+++ kern/uipc_socket.c 16 Oct 2002 21:32:01 -
-1785,6 +1785,7 filt_soread(struct knote *kn, long hint)
struct socket *so = (struct socket *)kn-kn_fp-f_data;
kn-kn_data = so-so_rcv.sb_cc;
+ kn-kn_data -= so-so_rcv.sb_ctl;
if (so-so_state SS_CANTRCVMORE) {
kn-kn_flags |= EV_EOF;
kn-kn_fflags = so-so_error;
Re: MPD PPTP tunneling intermittantly fails
On Wed, Oct 16, 2002 at 05:01:59PM -0700, Archie Cobbs wrote: | That doesn't look so good. But it doesn't look crazy from the | netgraph side, just like a lot of packets are being dropped. | There must be something specific about your setup that causes this. Specific is MPPE. I have the same problem here. I am digging the problem at slow pace. So far I discoverd that mpd set mtu on interface too early, thus without MPPE header size. But the real problem, is the huge amount of CCP Reset Requests from win client. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-net in the body of the message
Realtek 8150 support
Hi, Are there any development on a Realtek 8150 USB NIC driver? Been searching all over and all I can find are Linux drivers. -- Best regards, Michael mailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-net in the body of the message
Re: mpd - Radius
Hi, Archie Cobbs schrieb: Michael Bretterklieber writes: Now I got pap-radius-auth with mpd to work :-) Cool! You may want to contact Brendan Bank [EMAIL PROTECTED] because he's also working on mpd+RADIUS. It would be nice if you two could coordinate and maybe review each other's code... I made it now with a static define. The next step will be to add the appropriate config-param for mpd.conf. Are there any hints, a small howto would be great? Something like: - naming conventions of param - where to add param - how to access param Probably these should be bundle-level commands, right? You can use the examples that already exist as a starting point. yes. I implemented it at bundle level. But I think it will better to have something like this in the mpd.conf: - gobal switch to enable radius support. - switches for the different layers (link, bundle) where radius can be used (because Radius can more the Authentication) bye, Cheers, -Archie __ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-net in the body of the message -- -- -- E-mail: [EMAIL PROTECTED] JAWA Management Software GmbH Liebenauer Hauptstr. 200 A-8041 GRAZ Tel: ++43-(0)316-403274-12 Fax: ++43-(0)316-403274-10 GSM: ++43-(0)676-93 96 698 homepage: http://www.jawa.at - privat --- E-mail: [EMAIL PROTECTED] homepage: http://www.inode.at/mbretter -- To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-net in the body of the message
