Re: NVIDIA MCP51 Ethernet Interface
Angelo Turetta wrote: Joe Holden wrote: Hi collective, It's an Athlon 64 board, with an MCP51 NIC, this card is supported under Linux using the forcedeth driver, having taken a look at if_nve.c, it doesn't appear to be supported. It's supported by the nfe(4) driver, which has already been committed to 7-CURRENT. For 6-STABLE (and 6.2-RELEASE, previous releases did not even bootstrap on that chipset), please follow the discussions regarding nve/nfe at: http://www.freebsd.org/cgi/query-pr.cgi?pr=108861 and http://docs.freebsd.org/cgi/getmsg.cgi?fetch=127522+0+archive/2007/freebsd-net/20070211.freebsd-net Hope this helps Angelo Turetta Thanks, what about the IDE controller etc, are those all supported? My serial console for that machine isn't currently working, so I won't be able to check if it boots until its connected up. Thanks, Joe ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Unable to connect broadband
Hi folks, FreeBSD-6.2-amd64 Onboard NIC Motherboard ASUS M2N-E [url]http://www.excaliberpc.com/ASUS_M2N-E_nForce570_Ultra_Motherboard/M2N-E/partinfo-id-567211.html[/url] Fixed IP address IP address of server (LAN) - 192.168.0.10 Just finished "standard installation" to install the captioned OS. On "Choose Distributions" windown selected "All system sources, binaries and X Window System" On "Network interface information required" window, no NIC was found; [url]http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/install-post.html[/url] so "PLIP0" was selected. Everything went throught w/o problem. On reboote "xterm" was started with evoking "startx. But unable to connect outside World. The onboard NIC seems not detected. # ifconfig[code]plip0: flags=108851 mtu 1500 lo0: flags=8049 mtu 16384 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 inet6 :: prefixlen 128 inet 127.0.0.1 netmask 0xff00[/code] # ping 192.168.0.10[code]PING 192.168.0.10(192.168.0.10): 56 data bytes ping: sendto: No route to host ping: sendto: No route to host ..[/code] Please advise how to fix the problem. TIA B.R. satimis -- View this message in context: http://www.nabble.com/Unable-to-connect-broadband-tf3257481.html#a9056579 Sent from the freebsd-net mailing list archive at Nabble.com. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Status of iwi vs. iwiNG?
I'd like to know the status of the iwi driver vs. iwiNG. I've been using iwiNG for some time now and I don't see any notes in the CVS log of iwi that the changes have been merged. Dave. -- |David Gilbert, Independent Contractor. | Two things can be | |Mail: [EMAIL PROTECTED]| equal if and only if they | |http://daveg.ca | are precisely opposite. | =GLO ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: mpd sometimes hangs the whole system?
Max Laier wrote: [ Removing -stable from CC ] On Monday 19 February 2007 15:57, Alex Povolotsky wrote: mpd (fresh) on FreeBSD 6.1p12 sometimes hangs system, totally, to reset. Tried two completely different boxes, so it cannot be a hardware problem. I'm updating to 6.2 now, but have little hope. What can I turn on in kernel to fix it or at least to make computer reboot? How do you figure it's mpd related? Did you collect *any* debugging information at all? How about enabling DDB and WITNESS? A "hanging" system usually suggests a deadlock. WITNESS should turn up possible causes. Also, could you check if setting debug.mpsafenet=0 in loader.conf helps? Well, I'll try new kernel tomorrow; I've rebuild non-SMP kernel, so mpsafenet should not be of any use? Alex. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: mpd sometimes hangs the whole system?
Richard Tector wrote: Or perhaps it doesn't. All I can remember is it requires the bpf netgraph module. ng_bpf is not from this opera. It does just packets filtering by bpf-like filter program and it is not related to interfaces and traffic capturing. -- Alexander Motin [EMAIL PROTECTED] Optima Telecom ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: mpd sometimes hangs the whole system?
Hi. Alex Povolotsky wrote: mpd (fresh) on FreeBSD 6.1p12 sometimes hangs system, totally, to reset. Tried two completely different boxes, so it cannot be a hardware problem. I'm updating to 6.2 now, but have little hope. What can I turn on in kernel to fix it or at least to make computer reboot? I didn't check this, but have heard that this can hapend if you are trying to send tunnel (pptp/l2tp/...) traffic inside this tunnel. It can make infinite loop and consume all possible resources. Check your routing table for possible traffic loop. -- Alexander Motin [EMAIL PROTECTED] Optima Telecom ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: mpd sometimes hangs the whole system?
Alex Povolotsky пишет: mpd (fresh) on FreeBSD 6.1p12 sometimes hangs system, totally, to reset. Tried two completely different boxes, so it cannot be a hardware problem. It's easy to reproduce? Can you try make debug-friendly kernel? http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug-deadlocks.html http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/serialconsole-setup.html http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug-online-ddb.html I'm updating to 6.2 now, but have little hope. What can I turn on in kernel to fix it or at least to make computer reboot? See the above links. -- WBR, Andrey V. Elsukov ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: mpd sometimes hangs the whole system?
[ Removing -stable from CC ] On Monday 19 February 2007 15:57, Alex Povolotsky wrote: > mpd (fresh) on FreeBSD 6.1p12 sometimes hangs system, totally, to > reset. Tried two completely different boxes, so it cannot be a hardware > problem. > > I'm updating to 6.2 now, but have little hope. What can I turn on in > kernel to fix it or at least to make computer reboot? How do you figure it's mpd related? Did you collect *any* debugging information at all? How about enabling DDB and WITNESS? A "hanging" system usually suggests a deadlock. WITNESS should turn up possible causes. Also, could you check if setting debug.mpsafenet=0 in loader.conf helps? -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News pgpYchNwANq7I.pgp Description: PGP signature
Re: mpd sometimes hangs the whole system?
Alex Povolotsky wrote: > Richard Tector wrote: >> Alex Povolotsky wrote: >>> Richard Tector wrote: Alex Povolotsky wrote: > mpd (fresh) on FreeBSD 6.1p12 sometimes hangs system, totally, to > reset. Tried two completely different boxes, so it cannot be a > hardware problem. > Which version of mpd are you using? Have you tried the latest version from ports, 4.1? I've read it fixes a *lot* of problems found with the older versions. >>> >>> 3.18_5; Is mpd 4 100% backwards compartible? >> >> Yes, 4.x should work just fine with your 3.x configuration files. >> >>> And, what's worse, I've heard of exactly the same problem on 4.0. >>> Kernel _freeze_ should be something kernel-related, I fear. >> >> Quite possible. It involves putting the interfaces in promiscuous mode >> so could be due to a bug in your network card driver. What interfaces >> are you using? > > Proimisc?... hmm... fxp. Rock solid thing, as far as I can remember. Can > try em instead I have the same problem but use a sis nic - so I doubt it's the nic driver... (and if going to promiscuous mode was unstable on different drivers I guess some people would start to complain ;) ) (I have never encountered a crash when I started a sniffing program) -- Armin Pirkovitsch [EMAIL PROTECTED] ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
setting TCP timeouts
Is it possible to tweak various TCP timeouts in FreeBSD 6.2? Such as: how long a connection can stay in a FIN_WAIT_2 state. TIA ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: NVIDIA MCP51 Ethernet Interface
Joe Holden wrote: Hi collective, It's an Athlon 64 board, with an MCP51 NIC, this card is supported under Linux using the forcedeth driver, having taken a look at if_nve.c, it doesn't appear to be supported. It's supported by the nfe(4) driver, which has already been committed to 7-CURRENT. For 6-STABLE (and 6.2-RELEASE, previous releases did not even bootstrap on that chipset), please follow the discussions regarding nve/nfe at: http://www.freebsd.org/cgi/query-pr.cgi?pr=108861 and http://docs.freebsd.org/cgi/getmsg.cgi?fetch=127522+0+archive/2007/freebsd-net/20070211.freebsd-net Hope this helps Angelo Turetta ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Unable to connect broadband
satimis wrote: Hi folks, FreeBSD-6.2-amd64 ... The onboard NIC seems not detected. In the absence of required information, I speculate your machine has msk(4) or another recent chipset which may be supported in FreeBSD-CURRENT but not FreeBSD-STABLE. Please post the full output of 'pciconf -lv' from booting a recent FreeSBIE version to the list and hopefully someone can offer more help. Regards, BMS ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Status of iwi vs. iwiNG?
On Mon, Feb 19, 2007 at 12:02:45PM -0500, David Gilbert wrote: > I'd like to know the status of the iwi driver vs. iwiNG. I've been > using iwiNG for some time now and I don't see any notes in the CVS log > of iwi that the changes have been merged. what/where is iwiNG ? luigi ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
ntop anyone?
Hello. I've installed ntop on a FreeBSD 6.1 machine, it works, but always says that no traffic was collected (yes). Any hint? Is this port working, or, as it was in the past, broken? bye & Thanks av. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Status of iwi vs. iwiNG?
On Tuesday 20 February 2007 15:23, Luigi Rizzo wrote: > On Mon, Feb 19, 2007 at 12:02:45PM -0500, David Gilbert wrote: > > I'd like to know the status of the iwi driver vs. iwiNG. I've been > > using iwiNG for some time now and I don't see any notes in the CVS > > log of iwi that the changes have been merged. > > what/where is iwiNG ? The code David probably referers to was committed in "if_iwi.c rev. 1.35, Thu Apr 27 21:43:37 2006 UTC (9 months, 3 weeks ago)" and has been availabe from http://people.freebsd.org/~mlaier/new_iwi/ before. -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News pgpXjhlrHOv7m.pgp Description: PGP signature
Re: Unable to connect broadband
Hi Bruce, > Please post the full output of 'pciconf -lv' from booting a recent > FreeSBIE version to the list and hopefully someone can offer more > help. Ran; # pciconf -lv > /home/satimis/pciconf.txt I have the file created containing all output. My problem is how to copy it here, no floppy drive on the FreeBSD-6.2-amd64 box. There is another HD, running slamd64-11.0 Linux, connected to SATA-1 slot of the PC. FreeBSD-6.2-amd64 is connected to SATA-2 slot. I booted SATA-2 running FreeBSD. I can't find the HD on SATA-1 # df only displaying HD on SATA-2 (FreeBSD). # ls /dev ad4 ad4s1 ad4s2 ad4s3 ad4s4 ad4s5 ad4s6 I suppose they are the HD connect to SATA-1. # mount /dev/ad4s2 /mnt ... incorrect super block Tried /ad4s3/4/5/6 with the same result I can't mount the HD on SATA-1 to copy the file on slamd64-11.0 box. Then I can copy its content here when running slamd64 Linux. I put a thumb-drive on FreeBSD box but I can't find it. # fdisk -l did not work on FreeBSD Please help. I have only xterm windows running on FreeBSD box. TIA B.R. Stephen Liu Send instant messages to your online friends http://uk.messenger.yahoo.com ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: mpd sometimes hangs the whole system?
Andrey V. Elsukov wrote: Alex Povolotsky пишет: mpd (fresh) on FreeBSD 6.1p12 sometimes hangs system, totally, to reset. Tried two completely different boxes, so it cannot be a hardware problem. It's easy to reproduce? Can you try make debug-friendly kernel? RELATIVELY easy. It happens about once a day or more often; but it requires someone to press Reset. http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug-deadlocks.html http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/serialconsole-setup.html http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug-online-ddb.html Thanks a lot, I've added invariants and witness; if it won't yield any information, I'll try more. So far, this cursed thing is working with some load for 2 hours, that's much. It does NOT, surely NOT try to tunnel tunnelled traffic; any serialconsole setup is useless since it is also a main gateway. If it dies, nothing but physical access can help. Alex. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: mpd sometimes hangs the whole system?
At 11:35 AM 2/20/2007, Alex Povolotsky wrote: Thanks a lot, I've added invariants and witness; if it won't yield any information, I'll try more. So far, this cursed thing is working with some load for 2 hours, that's much. It does NOT, surely NOT try to tunnel tunnelled traffic; any serialconsole setup is useless since it is also a main gateway. If it dies, nothing but physical access can help. Although not a hard fast rule, I have found that if the box locks up to the point where a BREAK on the serial console does not send it to the debugger prompt, is usually a sign of a hardware lockup as opposed to a software bug. What is the chipset of the MB ? Does ichwd work with it to reset it ? ---Mike ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: mpd sometimes hangs the whole system?
Mike Tancsa wrote: At 11:35 AM 2/20/2007, Alex Povolotsky wrote: Thanks a lot, I've added invariants and witness; if it won't yield any information, I'll try more. So far, this cursed thing is working with some load for 2 hours, that's much. It does NOT, surely NOT try to tunnel tunnelled traffic; any serialconsole setup is useless since it is also a main gateway. If it dies, nothing but physical access can help. Although not a hard fast rule, I have found that if the box locks up to the point where a BREAK on the serial console does not send it to the debugger prompt, is usually a sign of a hardware lockup as opposed to a software bug. Well... I'll try to get to the box and try serial console.. What is the chipset of the MB ? Does ichwd work with it to reset it ? Whoops! Thanks, I'll give a try device = '82801BA/CA/DB/DBL/EB/ER/FB (ICH2/3/4/4/5/5/6), 6300ESB Hub Interface to PCI Bridge' you mean this thing, yes? Alex. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: mpd sometimes hangs the whole system?
Sten Daniel Soersdal wrote: Richard Tector wrote: Alex Povolotsky wrote: Richard Tector wrote: Alex Povolotsky wrote: mpd (fresh) on FreeBSD 6.1p12 sometimes hangs system, totally, to reset. Tried two completely different boxes, so it cannot be a hardware problem. Which version of mpd are you using? Have you tried the latest version from ports, 4.1? I've read it fixes a *lot* of problems found with the older versions. 3.18_5; Is mpd 4 100% backwards compartible? Yes, 4.x should work just fine with your 3.x configuration files. And, what's worse, I've heard of exactly the same problem on 4.0. Kernel _freeze_ should be something kernel-related, I fear. Quite possible. It involves putting the interfaces in promiscuous mode so could be due to a bug in your network card driver. What interfaces are you using? I'm not sure why mpd would want to put any interface in promiscuous mode. Neither pppoe, pptp nor l2tp would require promiscuous mode as they use either strictly unicast or ethernet broadcast. Perhaps you could provide some information as the situation where promiscuous mode is necessary? It doesn't. Was my mistake. It's been a while since I've used it first hand and I just remembered the requirement of ng_bpf, as I explained in a later mail. Richard smime.p7s Description: S/MIME Cryptographic Signature
Re: mpd sometimes hangs the whole system?
Richard Tector wrote: > Alex Povolotsky wrote: >> Richard Tector wrote: >>> Alex Povolotsky wrote: mpd (fresh) on FreeBSD 6.1p12 sometimes hangs system, totally, to reset. Tried two completely different boxes, so it cannot be a hardware problem. >>> Which version of mpd are you using? Have you tried the latest version >>> from ports, 4.1? I've read it fixes a *lot* of problems found with >>> the older versions. >> >> 3.18_5; Is mpd 4 100% backwards compartible? > > Yes, 4.x should work just fine with your 3.x configuration files. > >> And, what's worse, I've heard of exactly the same problem on 4.0. >> Kernel _freeze_ should be something kernel-related, I fear. > > Quite possible. It involves putting the interfaces in promiscuous mode > so could be due to a bug in your network card driver. What interfaces > are you using? > I'm not sure why mpd would want to put any interface in promiscuous mode. Neither pppoe, pptp nor l2tp would require promiscuous mode as they use either strictly unicast or ethernet broadcast. Perhaps you could provide some information as the situation where promiscuous mode is necessary? -- Sten Daniel Soersdal ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ipfw limit src-addr woes
Ian Smith wrote:
On Mon, 19 Feb 2007, admin wrote:
> Ian Smith wrote:
> > On Mon, 19 Feb 2007, admin wrote:
> > > Andre Santos wrote:
> > > > On 2/18/07, admin <[EMAIL PROTECTED]> wrote:
> > > >
> > > >> Hi, I'm trying to use ipfw's limit clause to limit the number of
> > > >> connections a single IP can have at the same time in a transparent
> > > >> web-proxy environment:
> > > >>
> > > >> 00350 skipto 401 tcp from x.x.x.x/x,y.y.y.y/y,z.z.z.z/z to any
dst-port
> > > >> 80 in via if0 setup limit src-addr 10
> > > >> 00401 fwd local.ip.ad.dr,8080 tcp from x.x.x.x/x to any dst-port 80
> > > >> ... the rest fwd...
> > > >>
> > > >> as I understand the manpage, when the current number of connectiions
is
> > > >> below 10, the action "skipto" is performed, else, the packet is
dropped
> > > >> and the search terminates. But...
> >
> > No, a packet is not dropped on a condition that fails a skipto test.
> >
> The manpage doesn't make this point clear.
You pretty much have to read it all .. several times .. a year. One of
the things you note is that each rule is tested until a packet is either
allowed or denied by a rule, even until '65535 deny ip from any to any'.
> limit {src-addr | src-port | dst-addr | dst-port} N
> The firewall will only allow N connections with the same
> set of parameters as specified in the rule.
Yes, for this rule. It still needs to be applied to an allow or deny
(or forward, divert etc, anything that terminates the search).
> To limit the number of connections a user can open you can use the
> following type of rules:
> ipfw add allow tcp from my-net/24 to any setup limit src-addr 10
> ipfw add allow tcp from any to me setup limit src-addr 4
Yes. Notice that these are allow rules, so the search terminates when
successfully matched. It is assumed you'll later have rule/s denying
what you've not allowed. True, this is not stated with every example.
> I'm assuming the packet gets silently dropped when the limit is
> overloaded but gets acted upon otherwise due to the stateful "limit"
> behaviour (keep-state in disguise). Just do a "skipto" when there's a
> state entry and that's it. And that's why the counter grows for
> established connections too, even though there's a "setup" modifier.
Can't tell without seeing your whole ruleset, but now that you know that
the skipto rule has NOT dropped the setup packets that don't match that
rule (including those exceeding the src-addr limit), I suspect you'll
find another rule has allowed them, on some other condition, later on.
Wrong: the implied "check-state" done by the "limit" lets the connection
through (i.e. performs the action) iff there's state recorded for it
(src-addr+src-port+dst-addr+dst-port). If however it's a SYN packet
incoming and the number of current states is trying to cross the limit,
the SYN packet is implicitly dropped and the search terminates.
This is not to say that I completely understand the things going on when
the connections start building up (different timeouts?) but the above
conclusion is based on what simulation has shown. The whole ruleset fits
on one screen, there's an "allow ip from any to any" in the end, so I'm
pretty sure I'm not crazy :-)
> As for the problem, it seems to me that all this noise is because of
> different timeouts in ipfw and TCP layer/whatever. The dynamic state
> entry for a connection expires while netstat -na still show the
> connection as ESTABLISHED, or, worse, the state entry is still there but
> the corresponding connection is in some half-closed state (FIN_WAIT_2,
> CLOSE_WAIT, LAST_ACK). The first case allows many more connections than
> "limit", while the second case won't let many good clients connect due
> to their buggy browsers not closing connections and letting the count
> build up. Could this be it?
I don't believe so. They can only have been established in the first
place if the setup packet has been, somewhere in your ruleset, allowed.
Yup. Then, after setting up the connections, the state times out earlier
than the actual connection shown by netstat! Gotta play a bit more with
the *_lifetime sysctls... And yes (answering to someone else on the
list), net.inet.ip.fw.dyn_keepalive is on: I don't tend to mess with the
default values of things I don't understand or care about... only what's
absolutely necessary.
Here it seems they're allowed (at least the ones from x.x.x.x/x) by the
fwd at 401 which has no 'setup' constraint, and will fwd both setup AND
established packets from x.x.x.x/x .. other rules, y and z, presumably.
Replaying .. trying not to do quite so much in one rule, but given you
can't just 'allow' here, since you want to run your fwd rules later:
> 00350 skipto 401 tcp from x.x.x.x/x,y.y.y.y/y,z.z.z.z/z to any dst-port \
> 80 in via if0 setup limit src-addr 10
0
If you run IS-IS please contact me
Anyone out there running IS-IS on a FreeBSD machine, please contact me. It's my understanding that IS-IS requires link-layer multicast support. Therefore I would like to hear from anyone who is running an implementation of it on FreeBSD successfully. I want to make sure it continues to operate in the 6.2-STABLE and 7.0-CURRENT code bases, given that we plan a lot of changes to Ethernet and how it works in those code bases. If you could let me know which implementation of IS-IS you're using, how long you've been running it for, how large the network you route with IS-IS is, and which FreeBSD releases you have been using, that would be most useful. Thank you in advance! Regards, BMS ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ipfw limit src-addr woes
admin wrote: Wrong: the implied "check-state" done by the "limit" lets the connection through (i.e. performs the action) iff there's state recorded for it (src-addr+src-port+dst-addr+dst-port). If however it's a SYN packet incoming and the number of current states is trying to cross the limit, the SYN packet is implicitly dropped and the search terminates. This is not to say that I completely understand the things going on when the connections start building up (different timeouts?) but the above conclusion is based on what simulation has shown. The whole ruleset fits on one screen, there's an "allow ip from any to any" in the end, so I'm pretty sure I'm not crazy :-) One thing to keep in mind is that a 'check-state' rule works by effectively jumping to the rule that did the 'keep-state' and re-executing it.. (and incrementing its stats). ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ioctl: SIOCADDMULTI (howto?)
Here is a better patch for the netstat output. I haven't had time to
look at the kernel yet.
If this patch is good for you I'll commit it on -CURRENT. It cleans up
the group membership output significantly and displays the Link-layer
information separately.
If anyone 'out there' has been relying on this output in scripts, please
tell me.
BMS
--- mcast.c.orig Sat Feb 17 18:12:28 2007
+++ mcast.c Tue Feb 20 23:26:41 2007
@@ -71,21 +71,39 @@
#define MYIFNAME_SIZE 128
void
-ifmalist_dump(void)
+ifmalist_dump_af(struct ifmaddrs *ifmap, int af)
{
- struct ifmaddrs *ifmap, *ifma;
+ struct ifmaddrs *ifma;
sockunion_t *psa;
char myifname[MYIFNAME_SIZE];
char addrbuf[INET6_ADDRSTRLEN];
char *pcolon;
void *addr;
- char *pifname, *plladdr, *pgroup;
+ char *pafname, *pifname, *plladdr, *pgroup;
- if (getifmaddrs(&ifmap))
- err(EX_OSERR, "getifmaddrs");
+ if (!((af == AF_INET) || (af == AF_LINK)
+#ifdef INET6
+ || (af == AF_INET6)
+#endif
+ ))
+ return;
+
+ switch (af) {
+ case AF_INET:
+ pafname = "IPv4";
+ break;
+ case AF_INET6:
+ pafname = "IPv6";
+ break;
+ case AF_LINK:
+ pafname = "Link-layer";
+ break;
+ }
- fputs("IPv4/IPv6 Multicast Group Memberships\n", stdout);
- fprintf(stdout, "%-20s\t%-16s\t%s\n", "Group", "Gateway", "Netif");
+ fprintf(stdout, "%s Multicast Group Memberships\n", pafname);
+ fprintf(stdout, "%-20s\t%-16s\t%s\n", "Group",
+ "Next Hop/L2 Address",
+ "Netif");
for (ifma = ifmap; ifma; ifma = ifma->ifma_next) {
@@ -94,16 +112,32 @@
/* Group address */
psa = (sockunion_t *)ifma->ifma_addr;
+ if (psa->sa.sa_family != af)
+ continue;
switch (psa->sa.sa_family) {
case AF_INET:
pgroup = inet_ntoa(psa->sin.sin_addr);
break;
+#ifdef INET6
case AF_INET6:
addr = &psa->sin6.sin6_addr;
inet_ntop(psa->sa.sa_family, addr, addrbuf,
sizeof(addrbuf));
pgroup = addrbuf;
break;
+#endif
+ case AF_LINK:
+ if ((psa->sdl.sdl_alen == ETHER_ADDR_LEN) ||
+ (psa->sdl.sdl_type == IFT_ETHER)) {
+pgroup =
+ether_ntoa((struct ether_addr *)&psa->sdl.sdl_data);
+ } else {
+pgroup = addr2ascii(AF_LINK,
+&psa->sdl,
+sizeof(struct sockaddr_dl),
+addrbuf);
+ }
+ break;
default:
continue; /* XXX */
}
@@ -116,14 +150,20 @@
plladdr = inet_ntoa(psa->sin.sin_addr);
break;
case AF_LINK:
-if (psa->sdl.sdl_type == IFT_ETHER)
- plladdr = ether_ntoa((struct ether_addr *)&psa->sdl.sdl_data);
-else
- plladdr = link_ntoa(&psa->sdl);
+if (psa->sdl.sdl_type == IFT_ETHER) {
+ plladdr =
+ether_ntoa((struct ether_addr *)&psa->sdl.sdl_data);
+} else {
+ plladdr = addr2ascii(AF_LINK,
+ &psa->sdl,
+ sizeof(struct sockaddr_dl),
+ addrbuf);
+}
break;
}
- } else
+ } else {
plladdr = "";
+ }
/* Interface upon which the membership exists */
psa = (sockunion_t *)ifma->ifma_name;
@@ -143,6 +183,23 @@
fprintf(stdout, "%-20s\t%-16s\t%s\n", pgroup, plladdr, pifname);
}
+}
+
+void
+ifmalist_dump(void)
+{
+ struct ifmaddrs *ifmap;
+
+ if (getifmaddrs(&ifmap))
+ err(EX_OSERR, "getifmaddrs");
+
+ ifmalist_dump_af(ifmap, AF_LINK);
+ fputs("\n", stdout);
+ ifmalist_dump_af(ifmap, AF_INET);
+ fputs("\n", stdout);
+#ifdef INET6
+ ifmalist_dump_af(ifmap, AF_INET6);
+#endif
freeifmaddrs(ifmap);
}
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ioctl: SIOCADDMULTI (howto?)
Jouke Witteveen wrote:
I hope someone can find a spare minute to look at if_findmulti. It
would help me quite much.
I verified with mtest that FreeBSD cannot delete an AF_LINK multicast
membership, reproduced with both 7-CURRENT and 6.2-RELEASE.
if_findmulti() appears to be doing a possibly incorrect comparison.
sa_equal() is not valid for use with AF_LINK in some cases, as
sockaddr_dl has deeper structure than a simple array of bytes.
Thanks for finding this bug -- it would have affected XORP's IS-IS
implementation further on in time.
Further testing would be appreciated. If the fix is good I will merge,
though it should perhaps be a more general fix for sa_equal().
BMS
Index: src/sys/net/if.c
===
RCS file: /home/ncvs/src/sys/net/if.c,v
retrieving revision 1.265
diff -u -p -r1.265 if.c
--- src/sys/net/if.c 30 Nov 2006 15:02:01 - 1.265
+++ src/sys/net/if.c 21 Feb 2007 00:34:12 -
@@ -2123,8 +2123,16 @@ if_findmulti(struct ifnet *ifp, struct s
IF_ADDR_LOCK_ASSERT(ifp);
TAILQ_FOREACH(ifma, &ifp->if_multiaddrs, ifma_link) {
- if (sa_equal(ifma->ifma_addr, sa))
- break;
+ if (sa->sa_family == AF_LINK) {
+ struct sockaddr_dl *sdl = (struct sockaddr_dl *)sa;
+
+ if (bcmp(LLADDR((struct sockaddr_dl *)ifma->ifma_addr),
+ LLADDR(sdl), sdl->sdl_alen) == 0)
+break;
+ } else {
+ if (sa_equal(ifma->ifma_addr, sa))
+break;
+ }
}
return ifma;
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
mpd success stories, anyone?
Hello! Is there anybody here who can say "I'm running mpd with 400 pptp connections, and it works without a flaw"? I mean 400 ACTIVE connections. If yes, I'll ask lots of questions. If no, I'll have to look for other pptp server. Cannot afford CISCO right now. Alex. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ipfw limit src-addr woes
On Tue, 20 Feb 2007, Julian Elischer wrote: > admin wrote: > > > Wrong: the implied "check-state" done by the "limit" lets the connection > > through (i.e. performs the action) iff there's state recorded for it > > (src-addr+src-port+dst-addr+dst-port). If however it's a SYN packet > > incoming and the number of current states is trying to cross the limit, > > the SYN packet is implicitly dropped and the search terminates. > > > > This is not to say that I completely understand the things going on when > > the connections start building up (different timeouts?) but the above > > conclusion is based on what simulation has shown. The whole ruleset fits > > on one screen, there's an "allow ip from any to any" in the end, so I'm > > pretty sure I'm not crazy :-) > > One thing to keep in mind is that a 'check-state' rule works by effectively > jumping to the rule that did the 'keep-state' and re-executing it.. > (and incrementing its stats). What if the action of the rule that does the 'keep-state' (here a limit src-addr) is a skipto, rather than an allow / fwd / divert etc rule that would terminate the search? Does 're-executing' here imply anything about whether the skipto's conditional branch is or is not taken? I bought into this because admin said that more connections were being allowed than the limit src-addr clause should allow, and I assumed that the skipto branch was not being taken on over-limit packets, and that the following fwd rule (allowing any type of packets including SYN) was being executed, which would account for what he'd said was happening. admin above asserts that my assumption was wrong, and that in a match beyond the limit number of connections for that src/dest address, the setup packet is 'implicitly dropped and the search terminates', and while I can't find that stated as such in ipfw(8), he may be right. Which still doesn't explain why connections from a particular IP beyond his specified limit are allowed to be established, as originally stated. [shrug] Over to the ipfw gurus. Cheers, Ian ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
