TCP_FASTOPEN is absent in GENERIC
Hi. Is there a strong reason for option TCP_FASTOPEN is absent in GENERIC kernel? It's off by default anyway (net.inet.tcp.fastopen.enabled=0). Latest dns/bind* versions want it very much. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Adding setfib support to rc.d/routing
20.01.2012 10:52, Attila Nagy wrote: Hi, Having multiple routing tables is a very nice and (was a) long awaited capability in FreeBSD. Having it since years is even more cool, because we can assume it's stable now. But not having infrastructure support for it sucks, this makes people hacking with rc.local or various scripts in various places. There is a(t least one) PR about it: conf/145440, which proposes a standard method for setting up different FIBs in a seems to be logical way, which is compatible with the current single routing table method of static_routes. Are there any objections about this PR? Is there something we can do to get it committed? JFYI conf/132476 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: ipfw reass brakes ipv6 operation
28.10.2011 19:09, Emil Muratov wrote: Hi all I've got into some strange behavior with ipv6. Somehow ipfw reassembly totally brakes it's operation. As soon as I add a rule ipfw add 100 reass all from any to any in all ipv6 operation is not available any more, I can only ping6 localhost. Outgoing ipv6 packets are OK, I can see them via tcpdump on an interface stf0 and after that leaving encapsulated in ip4 through another interface. But all incoming ipv6 packets are blackholed. I can see them arriving as an encapsulated payload in ip4 and after that they disappear. I don't know if this a bug or a feature, using ipfw add reass ip4 from any to any in works as a workaround. Shouldn't reass just pass ipv6 packets intact? Or if it is a feature than maybe there should be a note in IPFW(8) man page to not to use reass for anything except ip4? Yes, reass implemented only for ipv4 and breaks ipv6 packets. It should be fixed, not documented. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: panic: m_uiotombuf: progress != total
12.08.2011 20:55, Sergey Matveychuk wrote: Hi. Just after upgrade from 8.2 to 9.0 kernel panics: panic: m_uiotombuf: progress != total cpuid = 1 KDB: enter: panic [ thread pid 1194 tid 100132 ] Stopped at kdb_enter+0x3b: movq $0,0x913242(%rip) db bt Tracing pid 1194 tid 100132 td 0xfe0005c8f8c0 kdb_enter() at kdb_enter+0x3b panic() at panic+0x180 m_uiotombuf() at m_uiotombuf+0x142 sosend_generic() at sosend_generic+0x2c8 kern_sendit() at kern_sendit+0x191 sendit() at sendit+0xdc sendmsg() at sendmsg+0x87 syscallenter() at syscallenter+0x1aa syscall() at syscall+0x4c Xfast_syscall() at Xfast_syscall+0xdd --- syscall (28, FreeBSD ELF64, sendmsg), rip = 0x8019ad33c, rsp = 0x7fffd8f8, rbp = 0x7fffd930 --- On glebius request, here is kernel.debug and core file: http://semmy.ru/~sem/crash/ ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
panic: m_uiotombuf: progress != total
Hi. Just after upgrade from 8.2 to 9.0 kernel panics: panic: m_uiotombuf: progress != total cpuid = 1 KDB: enter: panic [ thread pid 1194 tid 100132 ] Stopped at kdb_enter+0x3b: movq$0,0x913242(%rip) db bt Tracing pid 1194 tid 100132 td 0xfe0005c8f8c0 kdb_enter() at kdb_enter+0x3b panic() at panic+0x180 m_uiotombuf() at m_uiotombuf+0x142 sosend_generic() at sosend_generic+0x2c8 kern_sendit() at kern_sendit+0x191 sendit() at sendit+0xdc sendmsg() at sendmsg+0x87 syscallenter() at syscallenter+0x1aa syscall() at syscall+0x4c Xfast_syscall() at Xfast_syscall+0xdd --- syscall (28, FreeBSD ELF64, sendmsg), rip = 0x8019ad33c, rsp = 0x7fffd8f8, rbp = 0x7fffd930 --- ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: RFC 6296 (NPT v6)
10.07.2011 7:13, Rémy Sanchez wrote: Hi, I was wondering if they were anyone currently implementing NPTv6 for FreeBSD ? If nobody is, since I need this feature and that the RFC is quite simple, I think I'll implement it (or run out of time trying to). However, it looks like you can't divert IPv6, and then I don't know what would be the best option to IPv6 patch for divert(4) was committed in HEAD a couple weeks ago by glebius@ (r223593). ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: ipv6, stateful config and non-default prefixlen
18.03.2011 18:27, Christian Kratzer wrote: Hi, On Fri, 18 Mar 2011, Eugene M. Zheganin wrote: Hi. I'm trying to get a working freebsd workstation with an ipv6 network where addresses are received from DHCP. ATM my IPv6 setup copies the IPv4 layout with vlans and /24 masks, so I'm using /120 prefixes. Is that even possible ? As the Handbook lacks any information about such setup, I decided to ask for help here. why not just use /64 prefixes ? You have 16 bits in your /48 to each ipv4 /24 network to an ipv6 /64 network. Don't fight the system. As for me, I've got /64 network and I must split it for tunneling, etc. So I have more wide prefixlen for my home network. I spend a lot of time to get auto configuration work, but gave up and set static config on all my home computers. The system is really strong :) -- Sem. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: route messages from NDP
09.02.2011 17:56, Sergey Matveychuk wrote:
[skipped]
DST is IPv6 address, IFP and IFA I don't care and GATEWAY section is empty.
Let's see why:
$1 = {sdl_len = 54 '6', sdl_family = 18 '\022', sdl_index = 8, sdl_type
= 135 '\207', sdl_nlen = 0 '\0',
sdl_alen = 0 '\0', sdl_slen = 0 '\0', sdl_data = '\0' repeats 45 times}
family is AF_LINK (18), it's a correct one. But sdl_alen, sdl_data are
zeros.
I forget to mention it's for 7.3-STABLE.
Looks like L2 (ARP/NDP) entries don't generate routing message at all
for 8.x+. It's seems a feature ARP-rewritting project. Am I right?
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
route messages from NDP
Hello.
In my routing table I see entries after Neighbor Discovery Protocol
processed:
...
2a02:6b8:0:401:51:4809:8158:1dcd 00:22:fb:3d:82:fe UHLWvlan438
...
I'd like to catch them via a routing socket when they appear.
First, try to add a static entry:
ndp -s 2a02:6b8:0:403::1:1 00:0e:0c:09:2e:7b
and look at route -n monitor output:
got message of size 240 on Wed Feb 9 17:26:50 2011
RTM_ADD: Add Route: len 240, pid: 82741, seq 2, errno 0,
flags:HOST,DONE,STATIC
locks: inits:
sockaddrs: DST,GATEWAY
2a02:6b8:0:403::1:1 0.e.c.9.2e.7b
We have two sections here - DST and GATEWAY. DST is a IPv6 address
(sa_family == AF_INET6) and GATEWAY is a MAC (sa_family == AF_LINK).
Just for info sockaddr_dl looks like this:
$1 = {sdl_len = 54 '6', sdl_family = 18 '\022', sdl_index = 24, sdl_type
= 135 '\207', sdl_nlen = 0 '\0',
sdl_alen = 6 '\006', sdl_slen = 0 '\0', sdl_data = \000\016\f\t.{,
'\0' repeats 39 times}
Looks good. Lets wait for NDP entry...
Here is it:
got message of size 328 on Wed Feb 9 17:27:11 2011
RTM_ADD: Add Route: len 328, pid: 0, seq 0, errno 0,
flags:UP,HOST,DONE,LLINFO,WASCLONED
locks: inits:
sockaddrs: DST,GATEWAY,IFP,IFA
2a02:6b8:0:40c:daa2:5eff:fe8c:139 vlan438:0.30.48.33.4.92
fe80::230:48ff:fe33:492%vlan438
We have four section here DST, GATEWAY, IFP, IFA.
DST is IPv6 address, IFP and IFA I don't care and GATEWAY section is empty.
Let's see why:
$1 = {sdl_len = 54 '6', sdl_family = 18 '\022', sdl_index = 8, sdl_type
= 135 '\207', sdl_nlen = 0 '\0',
sdl_alen = 0 '\0', sdl_slen = 0 '\0', sdl_data = '\0' repeats 45 times}
family is AF_LINK (18), it's a correct one. But sdl_alen, sdl_data are
zeros.
I see this for all routing messages from NDP. All created routing table
entries are good (no problems here).
Why sockaddr_dl in GATEWAY section has a zero address? Is it a bug?
--
Sem.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: divert rewrite
07.02.2011 18:36, Sergey Matveychuk wrote: 06.02.2011 4:42, Julian Elischer wrote: On 2/5/11 4:09 PM, Ivo Vachkov wrote: Hello, How can I help? if you have ipv6 connectivity and experience, I have no experience or connectivity, with it so I'll be coding blind and will need a tester. If you have an application for IPV6 testing that would be even better. Divert is often used for NAT but that doesn't seem very useful for IPv6 and natd doesn't support it anyhow. Object :) Divert is really useful way to get packets from firewall to userspace, analyse or process them some way and put them back. Really I see no other way for this for IPv6. I've tried ng_socket+ng_nat but there is no easy way to put a packet back in firewall. Oops, I meant ng_socket+ng_ipfw here. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: divert rewrite
08.02.2011 19:08, rozhuk...@gmail.com wrote: Did you try ng_ether + ng_ksocket? It can translate Ethernet frames incapsulated to udp to user space receiver. The idea is catch packets from firewall (ng_ipfw, ng_nat was mentioned by mistake) and pass them to user space module that do some processing and puts back the packets into firewall (for rules with `diverted' keyword). It works now for IPv4 with `divert' and doesn't with IPv6. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: divert rewrite
08.02.2011 21:47, rozhuk...@gmail.com пишет: -Original Message- From: Sergey Matveychuk [mailto:s...@freebsd.org] Sent: Wednesday, February 09, 2011 12:53 AM To: rozhuk...@gmail.com Cc: freebsd-net@freebsd.org Subject: Re: divert rewrite 08.02.2011 19:08, rozhuk...@gmail.com wrote: Did you try ng_ether + ng_ksocket? It can translate Ethernet frames incapsulated to udp to user space receiver. The idea is catch packets from firewall (ng_ipfw, ng_nat was mentioned by mistake) and pass them to user space module that do some processing and puts back the packets into firewall (for rules with `diverted' keyword). It works now for IPv4 with `divert' and doesn't with IPv6. I know how divert works, google: uTPControl ;) Its simple for developmet, stable, but uses many CPU. With ng_ether + ng_ksocket you can send custom Ethernet frames. There is some node that can filter traffic, for IPv6 you need allow 1 or 2 ethernet types to pass. I know. But I've written a module for conjunction with ipfw. It makes a decision by some criteria to pass a traffic or to block it. Administrators in our nets decide what kind traffic to pass to my module (mostly TCP SYN and few UDP) in their firewalls. So a conjection with ipfw is the goal. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: divert rewrite
06.02.2011 4:42, Julian Elischer wrote: On 2/5/11 4:09 PM, Ivo Vachkov wrote: Hello, How can I help? if you have ipv6 connectivity and experience, I have no experience or connectivity, with it so I'll be coding blind and will need a tester. If you have an application for IPV6 testing that would be even better. Divert is often used for NAT but that doesn't seem very useful for IPv6 and natd doesn't support it anyhow. Object :) Divert is really useful way to get packets from firewall to userspace, analyse or process them some way and put them back. Really I see no other way for this for IPv6. I've tried ng_socket+ng_nat but there is no easy way to put a packet back in firewall. I'm very interested in the process. And I'm ready to help in testing. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
kame NAT PT implementation
Hi. I wonder why kame NAT PT implementation has never been imported to the tree? I've tried to move my home box from dual stacked (private IPv4 and IPv6 addresses) to IPv6 only. (My router is dual stacket of course.) totd+faithd works but they can't completely satisfy me. I want to have complete protocol translation and I see no way to achive without NAT PT. -- Sem. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: Tunnel works on 10.10.1.0-10.10.2.0, and not works on 172.16.1.0-172.16.2.0
29.12.2010 13:00, Rashid N. Achilov пишет: FreeBSD 8.1-RELEASE. Occured a strange thing. Take two boxes with 8.1. Do these: On #1 ifconfig gif create ifconfig gif0 tunnel AAA.AAA.AAA.AAA BBB.BBB.BBB.BBB ifconfig gif0 inet 10.10.1.254 10.10.2.254 netmask 255.255.255.255 On #2 ifconfig gif create ifconfig gif0 tunnel BBB.BBB.BBB.BBB AAA.AAA.AAA.AAA ifconfig gif0 inet 10.10.2.254 10.10.1.254 netmask 255.255.255.255 Next, do ping 10.10.2.254 from box #1. Worked! Now do these: On #1 ifconfig gif create ifconfig gif0 tunnel AAA.AAA.AAA.AAA BBB.BBB.BBB.BBB ifconfig gif0 inet 172.16.1.254 172.16.2.254 netmask 255.255.255.255 On #2 ifconfig gif create ifconfig gif0 tunnel BBB.BBB.BBB.BBB AAA.AAA.AAA.AAA ifconfig gif0 inet 172.16.2.254 172.16.1.254 netmask 255.255.255.255 Next, do ping 172.16.2.254 from box #1. Not worked :-O Replace boxes onto 7.3-STABLE and re-do last sample (with 172.16). Worked! Why? Is there any problems in 8.1? Have you a firewall? I can't reproduce it with 8.2-PRERELEASE from Dec, 13. Both 10/8 and 172.16/12 work well. -- Sem. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
move setfib(1)
Hi! Does is possible to move setfib(1) to /sbin for smooth using it in rc.d scripts? -- Sem. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: move setfib(1)
26.05.2010 20:38, Julian Elischer wrote: On 5/26/10 9:32 AM, M. Warner Losh wrote: In message:4bfd158d.7020...@freebsd.org Sergey Matveychuks...@freebsd.org writes: : Does is possible to move setfib(1) to /sbin for smooth using it in : rc.d scripts? Can you tell us why you need it so early? We could do it, but eventually everything ends up moving to /sbin or /bin unless we need a good reason. I'm thinking about this after Doug's message: http://lists.freebsd.org/pipermail/freebsd-rc/2010-May/001954.html ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
tcp_input: Listen socket: Socket allocation failed due to limits or memory shortage
Hello. I was annoyed by the subject message and decided to dig it a little. The message appears sporadically and caused my application accept(2) error. I've quickly discovered it's not a listen queue overflow. I've increased kern.ipc.somaxconn to 1024 and listen(2) backlog argument too (netstat -Lan output: tcp4 0/0/1024 *.8542). But without a success. (My application serves only 3-5 connection simultaneously). Moreover, listen queue overflows counter (netstat -s) was not increased. I've decided it's a syncache or syncookie problem. First, I've set net.inet.tcp.syncookies_only=1. But it does not help. Second, I've set it back to 0 and set net.inet.tcp.syncookies=0. The messages gone. A message I've wrote before (syncache_expand: Segment failed SYNCOOKIE authentication, segment rejected (probably spoofed)) of course gone too. May be somebody who familiar with syncookies can comment it? -- Sem. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Segment failed SYNCOOKIE authentication
Hi. I have many messages on my box like this: tcpflags 0x10ACK; syncache_expand: Segment failed SYNCOOKIE authentication, segment rejected (probably spoofed) Some connections dropped. But it's legal connections. Looks like something wrong with syncache. An examples: 20:31:08.464499 IP XXX.YYY.240.5.50393 XXX.YYY.234.8.8542: Flags [S], seq 4197725771, win 65535, options [mss 1353,nop,wscale 3,sackOK,TS val 3072911437 ecr 0], length 0 20:31:08.464548 IP XXX.YYY.234.8.8542 XXX.YYY.240.5.50393: Flags [S.], seq 1425159360, ack 4197725772, win 65535, options [mss 1353,nop,wscale 3,sackOK,TS val 2395628971 ecr 3072911437], length 0 Looks good, but: May 7 20:31:09 cobalt kernel: TCP: [XXX.YYY.240.5]:50393 to [XXX.YYY.234.8]:8542 tcpflags 0x10ACK; syncache_expand: Segment failed SYNCOOKIE authentication, segment rejected (probably spoofed) For 1.5 hours: % grep SYNCOOKIE /var/log/messages | wc -l 1727 Any ideas please? -- Sem. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: HEADSUP: arp-v2 has been committed
Ian FREISLICH wrote: --- lib/sockopt.c.orig 2007-08-21 18:32:56.0 +0200 +++ lib/sockopt.c 2008-08-13 09:07:20.0 +0200 @@ -231,6 +231,7 @@ else mreqn.imr_address = if_addr; + mreqn.imr_address = if_addr; ret = setsockopt(sock, IPPROTO_IP, optname, (void *)mreqn, sizeof(mreqn)); if ((ret 0) (optname == IP_ADD_MEMBERSHIP) (errno == EADDRINUSE)) I don't catch your idea here. Can you explain it please? A result code looks ugly: if (ifindex) mreqn.imr_ifindex = ifindex; else mreqn.imr_address = if_addr; mreqn.imr_address = if_addr; ret = setsockopt(sock, IPPROTO_IP, optname, ... -- Dixi. Sem. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: ACE and FreeBSD
Randall Stewart wrote: Hi all: I am trying to get the latest ACE/TAO toolkit compiling with Head... (the port is marked broken in 7).. Could you take the port and upgrade/fix it? I did not use ace+tao for ages and can't support it anymore. -- Dixi. Sem. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: Update of Yandex' SMBable em driver
Ivan Voras пишет: Vladimir Ivanov wrote: Hi, We've published latest versions at http://people.yandex-team.ru/~wawa/em-6.7.3-yandex-1.40.tar.gz http://people.yandex-team.ru/~wawa/em-6.9.6-RELENG7-yandex-1.36.2.8.tar.gz These revisions use mtx_trylock instead of mtx_lock in em_start(). Thank you! Why the two versions? Is the first one for -CURRENT? (It looks like it would be interesting to try it on CURRENT with some ongoing SMP TCP work) Nope. The first one for RELENG_6. -- Dixi. Sem. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
bsnmpd 64bits counters problem
Hello. Some weird thing has happened with 64bit counters: % snmpwalk -v2c -cpublic localhost ifInOctets IF-MIB::ifInOctets.1 = Counter32: 4107815474 ... IF-MIB::ifInOctets.16 = Counter32: 2894713654 % snmpwalk -v2c -cpublic localhost ifHCInOctets IF-MIB::ifHCInOctets.1 = Counter64: 7911064279758 ... IF-MIB::ifHCInOctets.4 = Counter64: 13143091216588 There are all 16 32bits counters but only 4 64bits. That's less than physical interfaces on this router (em0-em5). 7.1-PRERELEASE -- Dixi. Sem. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: bsnmpd 64bits counters problem
Sergey Matveychuk wrote: Hello. Some weird thing has happened with 64bit counters: % snmpwalk -v2c -cpublic localhost ifInOctets IF-MIB::ifInOctets.1 = Counter32: 4107815474 ... IF-MIB::ifInOctets.16 = Counter32: 2894713654 % snmpwalk -v2c -cpublic localhost ifHCInOctets IF-MIB::ifHCInOctets.1 = Counter64: 7911064279758 ... IF-MIB::ifHCInOctets.4 = Counter64: 13143091216588 There are all 16 32bits counters but only 4 64bits. That's less than physical interfaces on this router (em0-em5). 7.1-PRERELEASE Looks like this is a reason: # ifconfig em4 em4: flags=8802BROADCAST,SIMPLEX,MULTICAST metric 0 mtu 1500 options=19bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4 ether 00:15:17:80:f5:ee media: Ethernet autoselect status: no carrier # ifconfig em5 em5: flags=8802BROADCAST,SIMPLEX,MULTICAST metric 0 mtu 1500 options=19bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4 ether 00:15:17:80:f5:ef media: Ethernet autoselect status: no carrier No 64bits counters returned for interfaces bellow them. -- Dixi. Sem. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: bsnmpd 64bits counters problem
Harti Brandt wrote: On Tue, 16 Dec 2008, Sergey Matveychuk wrote: SMHello. SM SMSome weird thing has happened with 64bit counters: SM SM% snmpwalk -v2c -cpublic localhost ifInOctets SMIF-MIB::ifInOctets.1 = Counter32: 4107815474 SM... SMIF-MIB::ifInOctets.16 = Counter32: 2894713654 SM SM% snmpwalk -v2c -cpublic localhost ifHCInOctets SMIF-MIB::ifHCInOctets.1 = Counter64: 7911064279758 SM... SMIF-MIB::ifHCInOctets.4 = Counter64: 13143091216588 SM SMThere are all 16 32bits counters but only 4 64bits. That's less than physical SMinterfaces on this router (em0-em5). SM SM7.1-PRERELEASE The highspeed counters are only there if this is a high-speed interface. High speed means that the baudrate in the interface MIB (the one in the kernel) must be larger than 20Mbaud. Well, these is lagg interfaces: lagg0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 9000 options=19bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4 ether 00:30:48:67:d4:68 media: Ethernet autoselect status: active laggproto lacp laggport: em2 flags=1cACTIVE,COLLECTING,DISTRIBUTING laggport: em0 flags=1cACTIVE,COLLECTING,DISTRIBUTING There is no baudrate on them. But they are really high-speed however. -- Dixi. Sem. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: altq on vlan
Max Laier wrote: Would you mind adding some words to that effect to your patch? I think I'll hide it from public access instead. Looks like some people prefer to patch kernel instead of learning how to make a queue on parent interface. -- Dixi. Sem. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ALTQ Vlan
Alexandre Biancalana wrote: Hi list, Is there any patches or plans to support altq on vlan interfaces ?? The patch is quite trivial: http://people.yandex-team.ru/~sem/FreeBSD/vlan+altq.patch But may be a better way to shape traffic on parent interface for you? I did the patch because I couldn't do shaping on a parent interface for some reason. -- Dixi. Sem. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ALTQ Vlan
Alexandre Biancalana wrote: The patch is quite trivial: http://people.yandex-team.ru/~sem/FreeBSD/vlan+altq.patch Is this working on 7 ? with pf ? I've test it only on 6.x with pf. But I think there should be no problem and with 7.0. -- Dixi. Sem. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: syncache_timer: Response timeout and other msgs, whats up?
Andre Oppermann wrote: Oskar Eyb wrote: Andre Oppermann schrieb am 03.02.2008 10:26: 85.214.42.62 is the other MTA, 172.16.0.2 is my jail. I use PF with rdr/nat on FreeBSD 7 RC4. We have not released 7RC4 yet. You probably run BETA4. An upgrade to 7RC1 or 7RC2 in the next few days fixes all known TCP bugs. Yeah of course, I mean BETA4. uname says: 7.0-PRERELEASE Which tag is the best? currently I use release=cvs tag=RELENG_7. Will I get with this 7RC..? Yes. Please cvsup and recompile your kernel. Really, if he wants to get -RC1, he should cvsup tag=RELENG_7_0. RELENG_7 still identified as -PRERELEASE. -- Dixi. Sem. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Deadlock in the routing code
Julian Elischer wrote: Would this also be a problem that could occur using quagga with zebra and ospfd? Sure, if they use routing sockets. Of course, they are do. -- Dixi. Sem. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [PATCH] ipfwpcap(8)
Vadim Goncharov wrote: Hi, I've recently found a patch (also available at http://antigreen.org/vadim/freebsd/ipfwpcap/) made by me and my friend in January to ipfwpcap(8) introduced in 7.0. Now it have more features, Unfortunately too old to apply. And using of pidfile_* functions from libutil is preferable IMHO. -- Dixi. Sem. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: net-mgmt/bsd-airtools broken not because of gcc4
Denis Barov wrote:
Hi all!
I found, that port net-mgmt/bsd-airtools marked as broken:
BROKEN= Does not compile with GCC 4.2
but, it's not really so.
It's broken after Wed Jul 11 21:25:48 2007 UTC commit by
[EMAIL PROTECTED], when some ioctls was deleted from kernel.
For example, after patching /usr/include/dev/wi/if_wavelan_ieee.h
bsd-airtools compiled well:
--- /usr/include/dev/wi/if_wavelan_ieee.h 2007-11-07
19:36:15.0 +0300
+++ /usr/src/sys/dev/wi/if_wavelan_ieee.h 2007-07-12
01:25:48.0 +0400
@@ -59,7 +59,7 @@
*/
#define WI_MAX_DATALEN 512
-#if 1
+#if 0
struct wi_req {
u_int16_t wi_len;
u_int16_t wi_type;
But, still missing some ioctls. dstumbler said
error: unable to ioctl device socket: Invalid argument
May be I can do something helpful?
I guess you should back not just these header definitions but ioctl
implementations too. Or ask thompsa if you could use something instead.
--
Dixi.
Sem.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to [EMAIL PROTECTED]
ipfw does not eat its own output
Hi.
I think quite many people met a situation when you want to save current
rules with 'ipfw list' command and use it as ipfw input afterwards?
(Yes, you should add a 'add' word before each line). But here we meet a
weird problem: 'ipfw list' outputs a wrong rule format sometime and you
can't use it without a modification.
The problem with 'to { ... or ... }' blocks. Let's see an example:
you add the rule:
ipfw add 100 allow tcp from { 10.10.10.1 or 10.10.10.2 } to { 10.10.10.3
or 10.10.10.4 or 10.10.10.5 }
adn it's showed as:
00100 allow tcp from { 10.10.10.1 or 10.10.10.2 } to { 10.10.10.3 or
dst-ip 10.10.10.4 or dst-ip 10.10.10.5 }
dst-ip words are wrong here. if you'll try to add the rule in this
format you get an error:
ipfw: missing )
I think it's a known and long standing problem.
(I've found it's introduced with the commit: Revision 1.11:
Mon Aug 19 04:52:15 2002 UTC (4 years, 11 months ago) by luigi )
After investigation I've found a strange assumption in
show_prerequisites() function. It looks wrong. So I think we can remove
it easily. It'll fix the problem. I've tried a lot of syntax variants
and I can't see something wrong in output after the modification.
Tell me if I wrong (with examples). The patch is bellow.
--
Dixi.
Sem.
--- sbin/ipfw/ipfw2.c.orig Thu Aug 2 13:44:45 2007
+++ sbin/ipfw/ipfw2.c Thu Aug 2 15:17:44 2007
@@ -1394,9 +1394,6 @@
{
if (comment_only)
return;
- if ( (*flags HAVE_IP) == HAVE_IP)
- *flags |= HAVE_OPTIONS;
-
if ( !(*flags HAVE_OPTIONS)) {
if ( !(*flags HAVE_PROTO) (want HAVE_PROTO))
if ( (*flags HAVE_PROTO4))
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to [EMAIL PROTECTED]
iwi loses ssid
Hi. After I upgraded to Jul 1 CURRENT my notebook's iwi adapter started work unstable. It loses carrier. When I take a look at ifconfig output I see a strange ssid. After I make ifconfig iwi0 ssid myssid, everything is recovered. Time between ssid losses is accidental. Sometimes minutes, sometimes hours. PS. While I wrote this message it resets ssid again to ZXDSL531BII-1A0EE6. It looks like the ssid is always the same. -- Dixi. Sem. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
iwi bricks my T43 on boot
I have IBM T43 notebook with this wireless internal card: iwi0: Intel(R) PRO/Wireless 2200BG mem 0xa8401000-0xa8401fff irq 11 at device 2.0 on pci4 The problem is FreeBSD bricks my notebook on boot sometime. After I've turned rc.d debugging on I see it hangs after ifconfig_up: iwi0 operation. It happens quite rarely when I use a power supply and very often when my notebook boots on battery. The problem has appeared when a new driver for ipw/iwi was introduced. A fresh CURRENT here. When the problem was firstly arised it was 6.0. Because my notebook bricked I can't get a core dump or a debugger. Any hints please how can I get more info on this? -- Dixi. Sem. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: iwi bricks my T43 on boot
Max Laier wrote: The problem has appeared when a new driver for ipw/iwi was introduced. A fresh CURRENT here. When the problem was firstly arised it was 6.0. The new driver has never been in 6.0. Well, I'm not quite sure here. May be it was CURRENT that time. Because my notebook bricked I can't get a core dump or a debugger. Any hints please how can I get more info on this? Can you make sure you have a complete debugging kernel with WITNESS enabled? Setting debug.iwi could also reveal what's going on. Unfortunately it's only a sysctl, not a tuneable, so you'd have to change the default in sys/dev/iwi/if_iwi.c line 88 by hand and recompile your kernel/module. By the way, are you using iwi built in or as a module? Do you load it via loader.conf or on demand from rc.d/*? I have WITNESS in my kernel. I'll try with debug.iwi. I have iwi-firmware-kmod-3.0_1 port installed. -- Dixi. Sem. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Sleeping in USB network drivers
Scott Ullrich wrote: On 6/7/06, Sergey Matveychuk [EMAIL PROTECTED] wrote: It was discussed in [EMAIL PROTECTED] Shortly, USB stack should be rewritten. The patch can be found at http://www.turbocat.net/~hselasky/usb4bsd/index.html Interesting. Do you have an updated patch set for RELENG_6_1? If not, I guess I could manually patch it by hand but I was planning on including this in pfSense if I can get it working correctly. Try to find the patch author in usb@ -- Dixi. Sem. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Sleeping in USB network drivers
Andrew Thompson wrote: Hi, I am looking into the reported panics with the if_aue driver and have come across a locking problem with usb adapters that is not obvious how to fix. The problem is that usbd_do_request() may sleep and most drivers are careful to call it without any locks held. in_addmulti() will grab in_multi_mtx before calling if_addmulti() to update the cards multicast hash, this effectively means that the driver can not sleep in *_setmulti but this is unavoidable with USB. Does anyone have any suggestions? (panic and bt below) It was discussed in [EMAIL PROTECTED] Shortly, USB stack should be rewritten. The patch can be found at http://www.turbocat.net/~hselasky/usb4bsd/index.html -- Dixi. Sem. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
iwi(4) problem on start
I have the configuration at home: notebook with iwi(4) - ZyXel AP - 100Mb switch - desktopPC(s) When I boot my notebook it's not available outside - from desktopPC. But when I do ping (or any network activity) from notebook, everything starts work. Any comments? PS. It's CURRENT a week ago age and the freshest iwi-firmware-kmod port. -- Sem. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: iwi(4) problem on start
Sergey Matveychuk wrote: I have the configuration at home: notebook with iwi(4) - ZyXel AP - 100Mb switch - desktopPC(s) When I boot my notebook it's not available outside - from desktopPC. But when I do ping (or any network activity) from notebook, everything starts work. Any comments? PS. It's CURRENT a week ago age and the freshest iwi-firmware-kmod port. Oh, forgot to say, AP is in BSS network-mode with 64-bit WEP encryption. -- Sem. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: iwi(4) problem on start
Darren Pilgrim wrote: Sergey Matveychuk wrote: Sergey Matveychuk wrote: I have the configuration at home: notebook with iwi(4) - ZyXel AP - 100Mb switch - desktopPC(s) When I boot my notebook it's not available outside - from desktopPC. But when I do ping (or any network activity) from notebook, everything starts work. Any comments? PS. It's CURRENT a week ago age and the freshest iwi-firmware-kmod port. Oh, forgot to say, AP is in BSS network-mode with 64-bit WEP encryption. Do you have the word up in your ifconfig line? No. But interface is up: iwi0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 If it not in UP state? And no magic happens when I try ifconfig iwi0 up now. Just outgoing traffic helps. -- Dixi. Sem. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: New version of iwi(4) - Call for testers [regression!]
Max Laier wrote: Latest version: http://people.freebsd.org/~mlaier/new_iwi/20060418.both_nofw.tgz Max, I don't understand, is it a full version? 20060315.both was much longer. -- Dixi. Sem. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: route entries after ICMP redirect
Uwe Doering wrote: This has been fixed in CVS in MAIN (rev. 1.52) and MFC'ed to RELENG_4 (rev. 1.37.2.5) and RELENG_5 (rev. 1.51.4.2) a couple of weeks ago: Oh, thank you! And thanks to [EMAIL PROTECTED] -- Sem. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
route entries after ICMP redirect
I've got some problem with route entries that was created after ICMP redirect messages. They are never expired. Our default gateway (it's a HP switch) send ICMP redirect messages if it see a short path to destination. It's makes it not so overloaded. But pathes sometime changed. There is no problem with Windows workstations, they are rebooted daily. But my FreeBSD boxes hold dinamic route entries forever. I've looked through RFCs and Stevens' books and found no answer on what TTL for this entries. Now I just add route flush as cron job. But may be there is another way? -- Sem. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: route entries after ICMP redirect
[EMAIL PROTECTED] wrote: If you want to handle this in a more clever way than a cron job you could write a small daemon which reads routing messages and does the right thing for whatever your situation is. I've explore a code and found I can do quite easy addition for dynamic routes - fill an expire field, check it periodicaly and remove expired entries (just like for arp entries). I think to do a sysctl variable for indication what time will set as expire values and set it to zero by default (no expires). -- Sem. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: still troubles with MPD and WinXP
In your /etc/ppp/ppp.conf you should set set timeout 0 in the appropriate section that refers to your PPTP connection. That might fix this problem if this is indeed a timeout issue as you said. Thank you. It's seams to be better. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-net in the body of the message
Re: Tips for MPD PPtP Re: still troubles with MPD and WinXP
Bill Moran wrote up these tips based on some testing he did when I was having problems last month, perhaps they will help you ? The main thing I found was to turn off Multilink on the Windows side. Do a search on google groups for: PPtP Client to MPD to boxes behind NATD are very slow?? (solved?) I'v tried all tips I found. Nothing help. I'v varied MTU size, set multilink on and off and so on. All tips I'v found in FreeBSD mail lists and google. Thinks was going better or worse but not good. All troubles I got when I moved from Win2k to WinXP. Here if my mpd.conf: default: load ciam-pptp ciam-pptp: new -i ng0 ciam-pptp ciam set iface disable on-demand set iface idle 1800 set iface enable proxy-arp set iface mtu 1400 set iface up-script /usr/local/etc/mpd/mpd-up.sh set iface down-script /usr/local/etc/mpd/mpd-down.sh set ipcp ranges 192.168.1.1/32 192.168.1.100/32 set ipcp dns 192.168.1.1 set bundle disable multilink # set link mtu 1460 set link disable pap set link enable chap #set link enable no-orig-auth set link keep-alive 10 60 # # enable Microsoft encryption # set bundle enable encryption #set bundle enable crypt-reqd set bundle enable compression set ccp yes mppc set ccp yes mpp-e40 set ccp yes mpp-e128 set ccp yes mpp-stateless All mpd.conf I'v seen was a similar but without up/down scripts. This scripts set ipfw rules only but may be something goes wrong with mpd when it run the scripts? I'v thought it's my WinXP fault but it works fine with poptop. But I don't satisfy of poptop stability though. Sem. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-net in the body of the message
SUMMARY: Win XP with mpd
After installing mpd-3.10 and using in mpd.conf: set iface mtu 1400 XP works fine and fast. There is no some tuning on the WinXP client I was make. It doesn't help for me :( Ping still lost packets. Network big operation still very slow. here is my cut off from my mpd.conf: new -i ng0 ciam-pptp ciam set iface disable on-demand set iface idle 1800 set iface enable proxy-arp set iface mtu 1400 set iface up-script /usr/local/etc/mpd/mpd-up.sh set iface down-script /usr/local/etc/mpd/mpd-down.sh set ipcp ranges 192.168.1.1/32 192.168.1.100/32 set ipcp dns 192.168.1.1 set bundle enable multilink # set link mtu 1400 set link disable pap set link enable chap #set link enable no-orig-auth set link keep-alive 10 60 set bundle enable encryption #set bundle enable crypt-reqd set bundle enable compression set ccp yes mppc set ccp yes mpp-e40 set ccp yes mpp-e128 set ccp yes mpp-stateless Can you help me? Sem. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-net in the body of the message
