Re: VLAN trunking and fragmentation
On Fri, Mar 14, 2008 at 11:05:01AM +0100, Giulio Ferro wrote: > Pyun YongHyeon wrote: > > > The latter is if_rlreg.h, I guess... > > > >Oops, yes. > > > > > > Anyway they don't compile: > > > > > > >Maybe you don't copy if_rlreg.h to /usr/src/sys/pci directory? > > > > I didn't ;-) > > Ok, I compiled and installed it. > > The behavior didn't change: the simple ping works all right, but when I > send a ping > greater than 1472 byte and fragments, nothing passes through: > > # tcpdump -i re0 -n -vvv not stp > tcpdump: listening on re0, link-type EN10MB (Ethernet), capture size 96 > bytes > > 11:49:38.004179 IP (tos 0x0, ttl 64, id 51279, offset 0, flags [+], > proto ICMP (1), length 1500) 192.168.100.2 > 192.168.100.1: ICMP echo > request, id 5, seq 0, length 1480 > 11:49:38.004183 IP (tos 0x0, ttl 64, id 51279, offset 1480, flags > [none], proto ICMP (1), length 48) 192.168.100.2 > 192.168.100.1: icmp > > > No packet reached the other PC. Ok, then try disabling hardware VLAN tagging. (#ifconfig re0 -vlanhwtag) -- Regards, Pyun YongHyeon ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: VLAN trunking and fragmentation
Pyun YongHyeon wrote: > The latter is if_rlreg.h, I guess... Oops, yes. > > Anyway they don't compile: > Maybe you don't copy if_rlreg.h to /usr/src/sys/pci directory? I didn't ;-) Ok, I compiled and installed it. The behavior didn't change: the simple ping works all right, but when I send a ping greater than 1472 byte and fragments, nothing passes through: # tcpdump -i re0 -n -vvv not stp tcpdump: listening on re0, link-type EN10MB (Ethernet), capture size 96 bytes 11:49:38.004179 IP (tos 0x0, ttl 64, id 51279, offset 0, flags [+], proto ICMP (1), length 1500) 192.168.100.2 > 192.168.100.1: ICMP echo request, id 5, seq 0, length 1480 11:49:38.004183 IP (tos 0x0, ttl 64, id 51279, offset 1480, flags [none], proto ICMP (1), length 48) 192.168.100.2 > 192.168.100.1: icmp No packet reached the other PC. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: TCP options order changed in FreeBSD 7, incompatible with some routers
On Fri, 14 Mar 2008, Mike Silbersack wrote: On Thu, 13 Mar 2008, Bjoern A. Zeeb wrote: It should give you output like this: 19549200,sackOK,eol,0x01[bad padding]> I like the [bad padding]. :-) 19641135,sackOK,eol,0x00> But I think the "good" case should look like it did before, per POLA. Ok, I am only printing it in case bad padding happens or one gave -v. The new patch is here: http://sources.zabbadoz.net/freebsd/patchset/20080314-01-tcpdump-print-tcp-option-padding.diff -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT Software is harder than hardware so better get it right the first time. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kern/121693: [nat] [panic] in kernel alias_irc nat double panic
Old Synopsis: in kernel alias_irc nat double panic New Synopsis: [nat] [panic] in kernel alias_irc nat double panic Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Fri Mar 14 11:18:51 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=121693 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kern/121693: [nat] [panic] in kernel alias_irc nat double panic
Synopsis: [nat] [panic] in kernel alias_irc nat double panic Responsible-Changed-From-To: freebsd-net->[EMAIL PROTECTED] Responsible-Changed-By: piso Responsible-Changed-When: Fri Mar 14 11:40:28 UTC 2008 Responsible-Changed-Why: Assign it to me. http://www.freebsd.org/cgi/query-pr.cgi?pr=121693 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kern/118432: [ng_nat] [panic] kernel libalias: repeatable panic (double fault)
Hi! The issue seems to be reprodusable on 7.0 - see kern/121693. -- WBR, Vadim Goncharov ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: VLAN trunking and fragmentation
Pyun YongHyeon wrote: > No packet reached the other PC. Ok, then try disabling hardware VLAN tagging. (#ifconfig re0 -vlanhwtag) That's it! Now seems to work properly, the problem then is with hardware tagging. My question now is: can I use vlans without htag in a complex system with heavy traffic without a significant performance loss? If not, how much will it take to fix the issue with the driver? Thanks for your answer. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kern/121693: in kernel alias_irc nat double panic
The following reply was made to PR kern/121693; it has been noted by GNATS. From: Vadim Goncharov <[EMAIL PROTECTED]> To: Gael Roualland <[EMAIL PROTECTED]> Cc: [EMAIL PROTECTED] Subject: Re: kern/121693: in kernel alias_irc nat double panic Date: Fri, 14 Mar 2008 17:02:47 +0600 Hi Gael Roualland! On Fri, 14 Mar 2008 09:28:14 GMT; Gael Roualland <[EMAIL PROTECTED]> wrote: >>Number: 121693 >>Category: kern >>Synopsis: in kernel alias_irc nat double panic >>Confidential: no >>Severity: serious >>Priority: low >>Responsible:freebsd-bugs >>State: open >>Quarter: >>Keywords: >>Date-Required: >>Class: sw-bug >>Submitter-Id: current-users >>Arrival-Date: Fri Mar 14 09:40:00 UTC 2008 >>Closed-Date: >>Last-Modified: >>Originator: Gael Roualland >>Release:7.0-STABLE >>Organization: >>Environment: > FreeBSD jerry.priv 7.0-STABLE FreeBSD 7.0-STABLE #0: Thu Mar 13 21:12:57 CET > 2008 [EMAIL PROTECTED]:/home/cvsup/obj/home/cvsup/src/sys/JERRY i386 >>Description: > Loading alias_irc in a kernel with nat activated leads to a kernel crash > with a double panic a few seconds later when at least one irc connection is > active to the outside (locally originated). > Unfortunately I do not have a backtrace available, core dump was lost. I > will reproduce if needed to get it. This is looks much the same like kern/121693 on 6.3, which has backtrace included. -- WBR, Vadim Goncharov. ICQ#166852181 mailto:[EMAIL PROTECTED] [Moderator of RU.ANTI-ECOLOGY][FreeBSD][http://antigreen.org][LJ:/nuclight] ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kern/121693: in kernel alias_irc nat double panic
The following reply was made to PR kern/121693; it has been noted by GNATS. From: Vadim Goncharov <[EMAIL PROTECTED]> To: Gael Roualland <[EMAIL PROTECTED]> Cc: [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: kern/121693: in kernel alias_irc nat double panic Date: Fri, 14 Mar 2008 17:06:39 +0600 Hi Gael Roualland! On Fri, 14 Mar 2008 09:28:14 GMT; Gael Roualland <[EMAIL PROTECTED]> wrote: >>Number: 121693 >>Category: kern >>Synopsis: in kernel alias_irc nat double panic >>Confidential: no >>Severity: serious >>Priority: low >>Responsible:freebsd-bugs >>State: open >>Quarter: >>Keywords: >>Date-Required: >>Class: sw-bug >>Submitter-Id: current-users >>Arrival-Date: Fri Mar 14 09:40:00 UTC 2008 >>Closed-Date: >>Last-Modified: >>Originator: Gael Roualland >>Release:7.0-STABLE >>Organization: >>Environment: > FreeBSD jerry.priv 7.0-STABLE FreeBSD 7.0-STABLE #0: Thu Mar 13 21:12:57 CET > 2008 [EMAIL PROTECTED]:/home/cvsup/obj/home/cvsup/src/sys/JERRY i386 >>Description: > Loading alias_irc in a kernel with nat activated leads to a kernel crash > with a double panic a few seconds later when at least one irc connection is > active to the outside (locally originated). > Unfortunately I do not have a backtrace available, core dump was lost. I > will reproduce if needed to get it. Oops, sent letter with wrong PR number. This looks like the same bug as in kern/118432 on 6.3 - which has backtrace included. -- WBR, Vadim Goncharov. ICQ#166852181 mailto:[EMAIL PROTECTED] [Moderator of RU.ANTI-ECOLOGY][FreeBSD][http://antigreen.org][LJ:/nuclight] ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: VLAN trunking and fragmentation
Giulio Ferro wrote: That's it! Now seems to work properly, the problem then is with hardware tagging. My question now is: can I use vlans without htag in a complex system with heavy traffic without a significant performance loss? If not, how much will it take to fix the issue with the driver? There's seems to be another problem now. If I send flood pings to the other host with big packets (say 2000 bytes) it works, but one packet out of 4 or 5 takes a huge time to round-trip (about 1000ms), whereas the rest of the packets have a reasonable 0.2 ms average... I fear this may lead to unacceptable performance for real-time protocols (ie voip) in a production environment. Do you think the problem is localized in the "re" driver? If so I could just change the network interface and be done with that. (In production I can use bge cards). Thanks again. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: VLAN trunking and fragmentation
On Fri, Mar 14, 2008 at 12:57:34PM +0100, Giulio Ferro wrote: > Pyun YongHyeon wrote: > > > No packet reached the other PC. > > > >Ok, then try disabling hardware VLAN tagging. > >(#ifconfig re0 -vlanhwtag) > > > > > That's it! > Now seems to work properly, the problem then is with hardware tagging. > > My question now is: can I use vlans without htag in a complex system with > heavy traffic without a significant performance loss? If not, how much Using available hardware assitance is almost always better than software approach. Disabling VLAN hardware assistance also disables checksum offload on VLAN interface so it may hurt VLAN performance a lot. > will it > take to fix the issue with the driver? > This hardware really make me crazy. There had been many attempts to fix checksum offload related issues. But it seems that several users still suffer from bad checksum or VLAN issues. So I guess the root cause of hardware bug was not yet known. This means that previous patch to work around hardware bug is not complete. Hmm, I'm not sure but it could be related with padding. What makes me wonder is why the first packet of fragmented packet does not show up on destination host. I guess the second packet of fragmented packet may be composed of single mbuf. From these information I will experiment possible combination of work around in next week. I'll let you know when I have a code. > Thanks for your answer. > -- Regards, Pyun YongHyeon ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: VLAN trunking and fragmentation
On Fri, Mar 14, 2008 at 01:14:40PM +0100, Giulio Ferro wrote: > Giulio Ferro wrote: > >That's it! > >Now seems to work properly, the problem then is with hardware tagging. > > > >My question now is: can I use vlans without htag in a complex system with > >heavy traffic without a significant performance loss? If not, how much > >will it > >take to fix the issue with the driver? > > > > > There's seems to be another problem now. > > If I send flood pings to the other host with big packets (say 2000 > bytes) it works, but one > packet out of 4 or 5 takes a huge time to round-trip (about 1000ms), > whereas the rest > of the packets have a reasonable 0.2 ms average... > > > I fear this may lead to unacceptable performance for real-time protocols > (ie voip) in a > production environment. > > Do you think the problem is localized in the "re" driver? If so I could Yes. > just change the > network interface and be done with that. (In production I can use bge > cards). > > > Thanks again. -- Regards, Pyun YongHyeon ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [Wireless] Can't connect to wlan
Benjamin Close wrote: Sam Leffler wrote: Yousif Hassan wrote: On Wed, 2008-03-12 at 08:06 +1030, Benjamin Close wrote: The slightly wonky: - As reported by someone else: wpi0: timeout resetting Tx ring 1 wpi0: timeout resetting Tx ring 3 wpi0: timeout resetting Tx ring 4 appear on startup and occasionally on kldload - however they don't appear to adversely affect too much wpi doesn't yet support background scan so doing an explicit scan from the command line will disconnect you from any ap you care connected to. It shouldn't be hard to add bgscan--but that's easy for me to say :) It's certainly on my todo list! Thanks for reminding me about the bgscan thing. I had read that somewhere before and completely forgotten! Ben, are the wpi0: timeout resetting Tx ring 1 wpi0: timeout resetting Tx ring 3 wpi0: timeout resetting Tx ring 4 (and other variants thereof) messages anything to be concerned about? It doesn't seem to affect stuff but it does show up on initial startup and every other scan I do. Thanks to everyone who worked on wpi for a most excellent driver. --Y ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: VLAN trunking and fragmentation
Pyun YongHyeon wrote: This hardware really make me crazy. There had been many attempts to fix checksum offload related issues. But it seems that several users still suffer from bad checksum or VLAN issues. So I guess the root cause of hardware bug was not yet known. This means that previous patch to work around hardware bug is not complete. Hmm, I'm not sure but it could be related with padding. What makes me wonder is why the first packet of fragmented packet does not show up on destination host. I guess the second packet of fragmented packet may be composed of single mbuf. From these information I will experiment possible combination of work around in next week. I'll let you know when I have a code. Great! Thanks for the good job. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Behavior of `ipfw table n list' in 7.0
Hello, I've been debugging some scripts for the better part of the hour, and finally figured out what's going on. On 6.2, `ipfw table 3 list' outputs: 169.229.127.61/32 100127061 But on 7.0, `ipfw table 4 list' outputs: 10.9.156.254/32 11.237.178.84 They're different tables with different values, but what's shocking is the change to dotted-quad representation on 7.0. I notice in ipfw(8) on 7.0, tablearg is now a valid value to fwd. The thing is, according to the 'LOOKUP TABLES' section of the man page, "Associated with each entry is a 32-bit unsigned value". It's very explicitly *not* an IP address, because tablearg can be used for all sorts of other things, like indexing pipes, specifying tag values, or in my case, holding netgraph cookies. It's not a big deal -- I already had an ip_to_number function in my shell library, and now that I know what the issue is, I can deal with it. I wanted to bring it up, because printing something that's not an IP address in dotted-quad notation seems misleading and confusing. -- Chris Cowart Network Technical Lead Network & Infrastructure Services, RSSP-IT UC Berkeley pgpQMJGzIm0Yu.pgp Description: PGP signature
Re: kern/121706: "rtfree: 0xc4383870 has 1 refs" emitted repeatedly
The same change was made in net/route.c rev 1.120.2.3. I don't know if all calls to rtfree(rt) should be converted to RTFREE_LOCKED(rt), but those remaining are in: net/route.c:367 net/route.c:399 netinet/if_ether.c:808 netinet/if_ether.c:813 netinet/if_ether.c:831 netinet/if_ether.c:834 netinet6/in6_gif.c:373 netinet6/in6_gif.c:376 netinet6/in6_ifattach.c:768 netinet6/nd6_nbr.c:219 -- Bruce ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
SLIP slipping away
Hello, I am having difficulty setting up a SLIP connection between a Debian 4.0 box and FreeBSD 7.0-STABLE. I have enabled the sl driver in the kernel. I have tried using slattach on /dev/cuad0 (usually "slattach -s 115200 /dev/cuad0) only to watch slattach immediately die with no output as to why. If I give the -l option it creates the sl0 interface but will not accept traffic. Reading through the years old FAQs states that a 'netstat -i' with the sl driver installed should show sl interfaces but netstat does not list any sl interfaces. I have tried to load the kernel module if_sl but I have had no success. Has anyone on this list had any success with using SLIP? Thanks, Kai Lockwood ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: SLIP slipping away
Kai Lockwood wrote: Hello, I am having difficulty setting up a SLIP connection between a Debian 4.0 box and FreeBSD 7.0-STABLE. I have enabled the sl driver in the kernel. I have tried using slattach on /dev/cuad0 (usually "slattach -s 115200 /dev/cuad0) only to watch slattach immediately die with no output as to why. If I give the -l option it creates the sl0 interface but will not accept traffic. Reading through the years old FAQs states that a 'netstat -i' with the sl driver installed should show sl interfaces but netstat does not list any sl interfaces. I have tried to load the kernel module if_sl but I have had no success. Has anyone on this list had any success with using SLIP? I somehow doubt anyone has used slip for years and years.. it COULD have been broken years ago. :-/ Thanks, Kai Lockwood ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Behavior of `ipfw table n list' in 7.0
Christopher Cowart wrote: Hello, I've been debugging some scripts for the better part of the hour, and finally figured out what's going on. On 6.2, `ipfw table 3 list' outputs: 169.229.127.61/32 100127061 But on 7.0, `ipfw table 4 list' outputs: 10.9.156.254/32 11.237.178.84 They're different tables with different values, but what's shocking is the change to dotted-quad representation on 7.0. I notice in ipfw(8) on 7.0, tablearg is now a valid value to fwd. The thing is, according to the 'LOOKUP TABLES' section of the man page, "Associated with each entry is a 32-bit unsigned value". It's very explicitly *not* an IP address, because tablearg can be used for all sorts of other things, like indexing pipes, specifying tag values, or in my case, holding netgraph cookies. It's not a big deal -- I already had an ip_to_number function in my shell library, and now that I know what the issue is, I can deal with it. I wanted to bring it up, because printing something that's not an IP address in dotted-quad notation seems misleading and confusing. I think the dotted quad part is mentioned somewhere, but anyhow a patch was put in to add a specific option to ipfw(8) to request the quad notation If you get a new version of ipfw(8) it should have the fix.. Or pull the fix from the freebsd source cvs web page.. pull and apply the diff for revision 1.114 from the following page http://www.freebsd.org/cgi/cvsweb.cgi/src/sbin/ipfw/ipfw2.c and apply it and then reinstall it. that reminds me I need to merge this back to RELENG_7 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
