libalias defect (PR 269770)
Folks, after suffering frequent network outages for quite some time, I finally hunted them down to a libalias issue. 'man 8 natd' suggests this for a port-forward: For example, the argument tcp inside1:telnet means that incoming TCP packets destined for port on this machine will be sent to the telnet port on the inside1 machine. While this may work for TCP, it does not work well for UDP (evidence is in the PR). With a static alias IP there are two ways to describe such a portforward: (1) ipfw nat 1 config log same_ports unreg_only ip 203.0.113.1 \ redirect_port udp 192.168.1.12:5006 5006 \ redirect_port tcp 192.168.1.12:5006 5006 (2) ipfw nat 1 config log same_ports unreg_only ip 203.0.113.1 \ redirect_port udp 192.168.1.12:5007 203.0.113.1:5006 \ redirect_port tcp 192.168.1.12:5007 203.0.113.1:5006 While there seems no obvious difference between both, there is a difference insofar as (2) appears to work, while (1) does not. The other difference is that (2) obviousely cannot be used with a dynamic alias (parameter 'if' instead of 'ip'), so there exists no working configuration in that case. Therefore I consider this not just a documentation flaw, but a defect. cheerio, PMc
Re: kern/162932: [ed][panic][patch] large traffic yields occasional panics
On Tue, Nov 29, 2011 at 11:03:00PM +, yong...@freebsd.org wrote: ! You can find the patch at the following URL. ! http://people.freebsd.org/~yongari/ed.pf.diff ! Let me know whether this patch works for you. Negative. It does not work. It seems You left away the pointer-arithmetics on src side, and copy the FIRST byte to the LAST position. Putting that right makes it working. *(mtod(m, uint8_t *)) should be *(mtod(m, uint8_t *) + m->m_len - 1) (Possibly there is a way to write this construct more beautiful - I didn't care.) ! since your patch may still invoke bus_space_write_1(9) if mbuf ! length is even bytes. Yes, it does. Deliberately. ;) The original idea seemed to be: "copy byte-pairs of AT LEAST mbuf-size" - on uneven buffers tjat led to copying one byte that doesnt belong. My idea was "copy byte-pairs of AT MOST mbuf-size" which leads to the last byte missing on uneven buffers - and therefore I did ALWAYS copy the LAST byte extra. (Shouldn't hurt copying it twice.) Please understand: it's 20 years ago that I coded C. I don't have all the niceties handy - but I'll find some way to get it do what I want. It looks not always beautiful. ;) Today I did reproduce the panic on 7.4-STABLE with the original code. Then I tried Your patch - and it did what was to be expected: no panic, but when setting "ifconfig ed0 mtu 1499", filetransfers would not proceed at all - the wrong byte obviousely breaks the packet checksum. rgds, PMc ___ 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"
ipfw not blocking inter jail ip traffic
iH, Have 2 jails and I don't want them to be able to reach other. gulag:#ifconfig em0 em0: flags=8843 metric 0 mtu 1500 options=9b ether 08:00:27:03:18:ea inet 172.20.6.50 netmask 0xff00 broadcast 172.20.6.255 inet 172.20.6.209 netmask 0xff00 broadcast 172.20.6.255 inet 172.20.6.211 netmask 0xff00 broadcast 172.20.6.255 gulag:#ipfw list 00100 allow ip from any to any via lo0 00200 deny ip from any to 127.0.0.0/8 00300 deny ip from 127.0.0.0/8 to any 1 deny ip from 172.20.6.209 to 172.20.6.211 10001 deny ip from 172.20.6.211 to 172.20.6.209 4 deny ip from 172.20.6.209 to any 65000 allow ip from any to any 65535 deny ip from any to any The two jails [.209 and .211] can still ping each other. Even with rule 4, the .209 jail can ping/ssh to the .211 jail, but of course cannot ping the gateway... If I remove rule '100' from the list, jails are no longer able to ping each other - Although the IPs are on em0, why is the rule with lo0 letting them pass? Does lo0 mean ALL ips assigned to server? or does it mean loopback interface: gulag:#ifconfig lo0 lo0: flags=8049 metric 0 mtu 16384 options=3 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 inet6 ::1 prefixlen 128 inet 127.0.0.1 netmask 0xff00 ]Peter[ ___ 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"
MAC address & rc.conf
Hi, My ISP have aauthorization by username, password AND mac address. I currently make PPPoE connection from my laptop(win XP) to them. However I want to put FreeBSD router in front of my laptop. That is why I will need to make MAC address of outgoing ethernet card same as my laptop. I plan to make bash script(ifconfig down, ifconfig up) for that purpose. However I prefer a little bit cleaner solution ... is there any way I can set MAC address for the network card in rc.conf ? Thanks :-))) Kind regards, Peter ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re:Solaris Assistance.... Please
There are two good mailling lists that I know you can find people to help you: www.sunmanagers.org and unix-wiz,@ -- [EMAIL PROTECTED] [forgot the website for this, but you can find it easily i'm guessing.] On 04/05/2001 12:45:18 PM, Ron 'The InSaNe One' Rosson is quoted as saying: . . . .|I can compile netsaint and its plugins and everything works fine.. But . . . .|when I go and try and compile apache 1.3.19 on my solaris 8 box with . . . .|mod_auth_db support It fails. . . . .| . . . .|I know this is kinda off topic but I was hoping to find a Solaris admin . . . .|that can help me. Here is a that shows what I have tried. . . . .| . . . .| . . . .|http://www.sunhelp.org/pipermail/rescue/2001-April/013751.html . . . .| . . . .|TIA . . . .|-- . . . .|-- . . . .|Ron Rosson... and a UNIX user said ... . . . .|The InSaNe Onerm -rf * . . . .|[EMAIL PROTECTED]and all was /dev/null and *void() . . . .|-- . . . .|Where do you think you're going today? . . . .| . . . .|To Unsubscribe: send mail to [EMAIL PROTECTED] . . . .|with "unsubscribe freebsd-net" in the body of the message www.nul.cjb.net www.FreeBSD.org _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
IPSEC, isakmpd, tunnel/transport encapsulation...
Good Evening, I apologise for what may end up being a stupid question, I'm getting towards my wits end. I've got a FreeBSD 6.2-PRERELEASE (cvsup of about 1300 GMT today) gateway which I'm attempting to run IPSEC/L2TP for wireless security. My client computers are Windows XP and Mac OS X, and the issue happens with both. No client has a fixed IP, so I want to permit any IP to establish a IPSEC session providing they know the preshared key. I'm using isakmpd for setup of the IPSEC side of things and hopefully SL2TPS for the L2TP side, although I'm not there yet. My issue is that none of my client can establish a L2TP session for what looks to be a mismatch of encapsulation types. For example, the first packet bellow is from my laptop to the gateway, the second is the reply. 18:18:56.540995 (authentic,confidential): SPI 0x1b79c065: IP 10.10.3.254.1701 > 10.10.2.1.1701: l2tp:[TLS](0/0)Ns=0,Nr=0 *MSGTYPE(SCCRQ) *PROTO_VER(1.0) *FRAMING_CAP(S) *BEARER_CAP() FIRM_VER(1280) |... 18:18:56.541039 (authentic,confidential): SPI 0x136223d4: IP 10.10.2.1 > 10.10.3.254: IP 10.10.2.1.1701 > 10.10.3.254.1701: l2tp:[TLS](20/0) Ns=1,Nr=1 ZLB (ipip-proto-4) This seems to be causing issues as the remote host isn't expecting the IPIP encapsulation there. I don't believe it has anything to do with SL2TPS because if I try and ICMP Ping 10.10.3.254 from 10.10.2.1, the ICMP request is IPSEC'd with the IPIP encapsulation. Has anyone seen this before? I'm using a fairly simplistic isakmpd.conf (which may be my issue)... [General] Listen-on = 10.10.2.1 [Phase 1] Default = local-peers [Phase 2] Passive-connections = authenticated-peers [local-peers] Phase = 1 Local-address = 10.10.2.1 Authentication = mypresharedkey Configuration = isakmp-main-mode [authenticated-peers] Phase = 2 ISAKMP-peer = local-peers Local-ID= local-network Remote-ID = remote-network #Configuration = ipsec-quick-mode [local-network] ID-type = IPV4_ADDR_SUBNET Network = 0.0.0.0 Netmask = 0.0.0.0 [remote-network] ID-type = IPV4_ADDR_SUBNET Network = 10.10.2.0 Netmask = 255.255.254.0 [isakmp-main-mode] EXCHANGE_TYPE = ID_PROT Transforms= 3DES-SHA [ipsec-quick-mode] EXCHANGE_TYPE = QUICK_MODE I have a isakmpd.policy of... KeyNote-Version: 2 Authorizer: "POLICY" Conditions: app_domain == "IPsec policy" && esp_present == "yes" -> "true"; I have tried specifying Tranforms/Suites on ipsec-quick-mode that should use transport encapsulation, I've even tried tunnel encapsulation to see if it'll solve it. I've added esp_encapsulation == "transport" to the policy file, and that hasn't helped either. Does anyone have a clue what I'm doing wrong? I sadly know very little about IPSEC, although I've learnt a lot today. If anyone had any sample configs of doing this kind of thing, that would be great. Google is some what lacking in info on this one. Many thanks for any help or suggestions! Cheers, Peter. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
iy(4) and 0x23 ex(4) panic
Hello. I am newbie to BSD, so please be patient of a stupid question& =) I have a good card intel etherexpress 10 isa utp. It is based on 82595 chip as well as ee10pro card. So I supposed I can use it with ex(4) driver. But, the kernel says: ex0: ifmedia_set: no match for 0x23/0x. I tried to find out answer with no success in Google including groups. The best match for me was that TPE connector is unplugged, but this is NOT the case. I surely turned off PNP in card's configurator, as well as changed base-address/IRQ and powering off/on after this. Some guy on IRC told FBSD works poorly on intel ISA cards. But w95 does pretty at the same machine (with PNP turned in card, though), and, I am somewhy sure, Linux will? I am even wondering what does this 0x23 should mean? Also it makes me wonder that Free has no ifmedia_set(4) man page like Open does? And! I saw even iy(4) driver in Open but see no one in Free? could I see the third-party provided iy(4) anywhere? As I said I am newbie, but I had no troubles to setup my 3Com card with xl(4). We have expensive traffic here, in the middle of Russia, so it's too hard to change Free on Open to try. PLEASE HELP! ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Notification of change of IP address/Routing etc
On 2022-Aug-31 10:18:44 +0200, Martin Stiemerling wrote: >I am looking for a mechanism to get a notification from the OS when, for >instance, an IP address on an interface or a routing entry is being changed. Assuming you are using the base OS version of dhclient, you could use /etc/dhclient-exit-hooks, which is a shellscript documented in dhclient-script(8). -- Peter Jeremy signature.asc Description: PGP signature
Re: sshd doesn't disconnect for 30+ minutes after the TCP connection is closed ungracefully
On 3/1/23 05:03, Mike Karels wrote: On 1 Mar 2023, at 5:36, Michael Gmelin wrote: On 1. Mar 2023, at 11:35, Yuri wrote: Windows system connects to FreeBSD through ssh and then this connection dies because of WiFi or VPN issues. FreeBSD still has the sshd process alive for this connection for 30+ minutes. TCP keepalive is enabled on the FreeBSD host: $ sysctl net.inet.tcp.always_keepalive net.inet.tcp.always_keepalive: 1 Shouldn't TCP keepalive kill this sshd process after 3-4 minutes because this connection isn't alive? Keepalives start after net.inet.tcp.keepidle milliseconds (2h by default). When this happens to me, I generally log into the server again and use write(1) to send a message to that tty (a newline will do). That probes the connection and causes a reset, and the session gets cleaned up. I use a longer keepidle value for other reasons. Mike Personaly, I set ClientAliveCountMax and ClientAliveCountInterval in sshd_config on my servers. ClientAliveInterval Sets a timeout interval in seconds after which if no data has been received from the client, sshd(8) will send a message through the encrypted channel to request a response from the client. I set mine fairly to start early (eg: Interval = 60). If the connection has dropped then even the first probe will cause tcp to do its retries and lead to a connection drop. When I was commuting on shuttles and rail, I did this on the client side (~/.ssh/config with ServerAlive* probes) for different reasons. The (overloaded) router would drop connections that seemed idle. Sending probes helped prevent that - or at least making the router drop somebody else's instead. -Peter
Re: sshd doesn't disconnect for 30+ minutes after the TCP connection is closed ungracefully
On 3/6/23 13:04, Mark Delany wrote: On 06Mar23, Peter Wemm allegedly wrote: (~/.ssh/config with ServerAlive* probes) for different reasons. The (overloaded) router would drop connections that seemed idle. Sending probes helped prevent that - or at least making the router drop somebody else's instead. Probably explains why I, quite likely on the same shuttle, ended up running this on the client side of my terminal sessions: while : do ssh snake.corp.youknowhoo.com tmux emacs echo Some dirty rat caused my connection to drop...again! sleep 2 done "mosh" turned out to be a better solution in the longer run for me. It would survive switching between shuttle and mobile data transparently. You needed a reliable jump host with udp access though. -Peter
A syzkaller regression test triggered a panic
Fatal trap 9: general protection fault while in kernel mode cpuid = 1; apic id = 01 instruction pointer = 0x20:0x80d21330 stack pointer = 0x28:0xfe01d39b9b20 frame pointer = 0x28:0xfe01d39b9b40 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 30447 (syzkaller24) rdi: deadc0dedeadc0de rsi: f80070830800 rdx: rcx: f807ecfcd660 r8: 00fe r9: fe0037804218 rax: f807ecfcd600 rbx: f8039ed87c40 rbp: fe01d39b9b40 r10: f80070830800 r11: f8082001a800 r12: f807ecfcd600 r13: f8015bf5f8c0 r14: r15: trap number = 9 panic: general protection fault cpuid = 1 time = 1694207336 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe01d39b9860 vpanic() at vpanic+0x132/frame 0xfe01d39b9990 panic() at panic+0x43/frame 0xfe01d39b99f0 trap_fatal() at trap_fatal+0x40c/frame 0xfe01d39b9a50 calltrap() at calltrap+0x8/frame 0xfe01d39b9a50 --- trap 0x9, rip = 0x80d21330, rsp = 0xfe01d39b9b20, rbp = 0xfe01d39b9b40 --- ip_mfilter_free() at ip_mfilter_free+0x1a0/frame 0xfe01d39b9b40 inp_freemoptions() at inp_freemoptions+0x85/frame 0xfe01d39b9b80 sorele_locked() at sorele_locked+0xf7/frame 0xfe01d39b9bb0 soclose() at soclose+0x17d/frame 0xfe01d39b9c10 _fdrop() at _fdrop+0x1b/frame 0xfe01d39b9c30 closef() at closef+0x1e3/frame 0xfe01d39b9cc0 fdescfree() at fdescfree+0x41a/frame 0xfe01d39b9d80 exit1() at exit1+0x4a1/frame 0xfe01d39b9df0 sys_exit() at sys_exit+0xd/frame 0xfe01d39b9e00 amd64_syscall() at amd64_syscall+0x14f/frame 0xfe01d39b9f30 fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfe01d39b9f30 --- syscall (1, FreeBSD ELF64, exit), rip = 0x822150e6a, rsp = 0x820d6b1f8, rbp = 0x820d6b210 --- KDB: enter: panic [ thread pid 30447 tid 131724 ] Stopped at kdb_enter+0x32: movq$0,0xe275d3(%rip) db> Details @ https://people.freebsd.org/~pho/stress/log/log0487.txt -Peter
Re: Question: Why ain't I getting gigabit speed?
On 2013-Feb-07 15:13:27 -0800, "Ronald F. Guilmette" wrote: >I just aquired a brand new chepie gigabit PCI ethernet card off eBay. >The main chip on it appears to be an RTL8110S-32. ... >I've tried two different CAT6 cables, two different LAN ports on my E2000, >and I've even tried the card in two different PCI slost on my motherboard, >but the results are always the same. Based on the testing you've done, I'd suspect a broken card. I'll echo the comments that Realtek is the cheapest end of the market and you'd be better off with a Broadcom or Intel NIC. >P.S. dmesg has this to say about the card: > >re0: port >0xbe00-0xbeff mem 0xdf9ff000-0xdf9ff0ff irq 18 at device 5.0 on pci4 >re0: Chip rev. 0x0400 >re0: MAC rev. 0x >re0: Ethernet address: 00:13:3b:02:03:bd >re0: link state changed to UP >re0: link state changed to DOWN >re0: link state changed to UP The critical information you've left out is the phy details. This should look something like: miibus0: on re0 rgephy0: PHY 1 on miibus0 rgephy0: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow On 2013-Feb-08 12:48:32 -0800, "Ronald F. Guilmette" wrote: >I did some more experiments. Fortunately, I had a CAT6 crossover cable >lying around. For future reference, you can join GigE interfaces with either straight through or crossover cables. >In the case of connecting to the laptop, all seemed to work correctly, >however ifconfig showed that my re0 device in this case believed itself >to be "master". (I suspect that this may make a difference, and that >the current FreeBSD re driver may perhaps behave better when it is >acting as master.) The "master" term seems to only define which end is the clock source. >in the output from "ifconfig re0", *however* a moment or two later, >suddenly the connection was entirely dropped, and now the ifconfig >output said "no carrier". What status was reported on the lights at each end? -- Peter Jeremy pgpAs2VtFUApg.pgp Description: PGP signature
Re: point-to-point network with unknown peer ip address
On 2013-Feb-20 02:56:55 -0800, "M. V." wrote: >I have 2 FreeBSD8.2 systems. I have a point-to-point interface >(myif0) on each side connected together, but on each side I don't >know IP address of the other side. to make the connection work, On >each side I set IP address (2.2.2.32/24 and 2.2.2.33/24) and added a >route which sends all traffic to the network to interface: > >#route add 2.2.2.0/24 -interface myif0 > >#ifconfig myif0 >myif0: flags=89d1 >metric 0 mtu 1500 I'm not certain what you are trying to achieve but point-to-point links would normally be /32, not /24. >now, from one side if I ping the other side (say 2.2.2.33/24) >everything seems ok. but if I ping any other IP in the network (say >2.2.2.100/24) the other endpoint sends back packet + an ICMP REDIRECT >packet. 2.2.2.100 is not a valid address in the network you have described. Where did you expect you expect the packet to be sent? >my sysctl output: >... > >net.inet.ip.redirect: 1 >net.inet.icmp.drop_redirect: 0 >... You don't say what you are trying to achieve but my crystal ball says that you want net.inet.ip.forwarding=1 on the remote system. -- Peter Jeremy pgp4c2p5tAMBd.pgp Description: PGP signature
Re: panic in tcp_do_segment()
ONN / syncache check?
>
> --
> Andre
>
> Index: netinet/tcp_input.c
> ===
> --- netinet/tcp_input.c (revision 249253)
> +++ netinet/tcp_input.c (working copy)
> @@ -1351,6 +1351,16 @@
>*/
> INP_INFO_UNLOCK_ASSERT(&V_tcbinfo);
> return;
> + } else if (tp->t_state == TCPS_LISTEN) {
> + /*
> + * When a listen socket is torn down the SO_ACCEPTCONN
> + * flag is removed first while connections are drained
> + * from the accept queue in a unlock/lock cycle of the
> + * ACCEPT_LOCK, opening a race condition allowing a SYN
> + * attempt go through unhandled.
> + */
> + TCPSTAT_INC(tcps_rcvdwhileclosing);
> + goto drop;
> }
>
> #ifdef TCP_SIGNATURE
I was able to reproduce the original "panic: tcp_do_segment:
TCPS_LISTEN" with ease; see
http://people.freebsd.org/~pho/stress/log/tcp.txt.
With your patch (minus the TCPSTAT_INC) I got this "panic: Lock (rw)
tcp locked @ netinet/tcp_input.c:1432."
http://people.freebsd.org/~pho/stress/log/tcp2.txt
- Peter
___
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 in tcp_do_segment()
On Tue, Apr 09, 2013 at 10:35:30AM +0200, Andre Oppermann wrote:
> On 09.04.2013 10:16, Peter Holm wrote:
> > On Mon, Apr 08, 2013 at 02:13:40PM +0200, Andre Oppermann wrote:
> >> On 05.04.2013 13:09, Matt Miller wrote:
> >>> Hey Rick,
> >>>
> >>> I believe Juan and I have root caused this crash recently. The t_state =
> >>> 0x1, TCPS_LISTEN, in the link provided at the time of the assertion.
> >>>
> >>> In tcp_input(), if we're in TCPS_LISTEN, SO_ACCEPTCONN should be set on
> >>> the
> >>> socket and we should never enter tcp_do_segment() for this state. I think
> >>> if you look in your corefile, you'll see the socket *doesn't* have this
> >>> flag set in your case.
> >>>
> >>> 1043 /*
> >>> 1044 * When the socket is accepting connections (the INPCB is in
> >>> LISTEN
> >>> 1045 * state) we look into the SYN cache if this is a new
> >>> connection
> >>> 1046 * attempt or the completion of a previous one. Because
> >>> listen
> >>> 1047 * sockets are never in TCPS_ESTABLISHED, the V_tcbinfo lock
> >>> will be
> >>> 1048 * held in this case.
> >>> 1049 */
> >>> 1050 if (so->so_options & SO_ACCEPTCONN) {
> >>> 1051 struct in_conninfo inc;
> >>> 1052
> >>> 1053 KASSERT(tp->t_state == TCPS_LISTEN, ("%s: so
> >>> accepting
> >>> but "
> >>> 1054 "tp not listening", __func__));
> >>> ...
> >>> 1356 syncache_add(&inc, &to, th, inp, &so, m, NULL, NULL);
> >>> 1357 /*
> >>> 1358 * Entry added to syncache and mbuf consumed.
> >>> 1359 * Everything already unlocked by syncache_add().
> >>> 1360 */
> >>> 1361 INP_INFO_UNLOCK_ASSERT(&V_tcbinfo);
> >>> 1362 return;
> >>> 1363 }
> >>> ...
> >>> 1384 /*
> >>> 1385 * Segment belongs to a connection in SYN_SENT, ESTABLISHED
> >>> or
> >>> later
> >>> 1386 * state. tcp_do_segment() always consumes the mbuf chain,
> >>> unlocks
> >>> 1387 * the inpcb, and unlocks pcbinfo.
> >>> 1388 */
> >>> 1389 tcp_do_segment(m, th, so, tp, drop_hdrlen, tlen, iptos,
> >>> ti_locked);
> >>>
> >>> I think this has to do with this patch in soclose() where SO_ACCEPTCONN is
> >>> being turned off in soclose(). I suspect if you look at the other threads
> >>> in your corefile, you'll see one at this point in soclose() operating on
> >>> the same socket as the one in the tcp_do_segment() thread.
> >>>
> >>> http://svnweb.freebsd.org/base?view=revision&revision=243627
> >>>
> >>>817 /*
> >>>818 * Prevent new additions to the accept queues due
> >>>819 * to ACCEPT_LOCK races while we are draining them.
> >>>820 */
> >>>821 so->so_options &= ~SO_ACCEPTCONN;
> >>>822 while ((sp = TAILQ_FIRST(&so->so_incomp)) != NULL)
> >>> {
> >>>823 TAILQ_REMOVE(&so->so_incomp, sp, so_list);
> >>>824 so->so_incqlen--;
> >>>825 sp->so_qstate &= ~SQ_INCOMP;
> >>>826 sp->so_head = NULL;
> >>>827 ACCEPT_UNLOCK();
> >>>828 soabort(sp);
> >>>829 ACCEPT_LOCK();
> >>>830 }
> >>>
> >>> Juan had evaluated this code path and it seemed safe to just drop the
> >>> packet in this case:
> >>>
> >>> + /*
> >>> + * In closing down the socket, the SO_ACCEPTCONN flag is removed to
> >>> + * prevent new connections from being established. This means that
> >>> + * any frames in that were in the midst of being processed could
> >>> + * make it here. Nee
Re: panic in tcp_do_segment()
On Fri, Apr 12, 2013 at 10:14:40AM -0400, Juan Mojica wrote:
Glad I could help.
- Peter
>I'm a little late to get back to the email thread, but this is great to
>hear. Changes look good (assuming the goto drop is changed
>dropunlock). Thanks guys.
>
>On Tue, Apr 9, 2013 at 2:44 PM, Peter Holm <[1]pe...@holm.cc> wrote:
>
>On Tue, Apr 09, 2013 at 10:35:30AM +0200, Andre Oppermann wrote:
>> On 09.04.2013 10:16, Peter Holm wrote:
>> > On Mon, Apr 08, 2013 at 02:13:40PM +0200, Andre Oppermann wrote:
>> >> On 05.04.2013 13:09, Matt Miller wrote:
>> >>> Hey Rick,
>> >>>
>> >>> I believe Juan and I have root caused this crash recently. The
>t_state =
>> >>> 0x1, TCPS_LISTEN, in the link provided at the time of the
>assertion.
>> >>>
>> >>> In tcp_input(), if we're in TCPS_LISTEN, SO_ACCEPTCONN should be
>set on the
>> >>> socket and we should never enter tcp_do_segment() for this state.
> I think
>> >>> if you look in your corefile, you'll see the socket *doesn't*
>have this
>> >>> flag set in your case.
>> >>>
>> >>> 1043 /*
>> >>> 1044 * When the socket is accepting connections (the
>INPCB is in
>> >>> LISTEN
>> >>> 1045 * state) we look into the SYN cache if this is a
>new
>> >>> connection
>> >>> 1046 * attempt or the completion of a previous one.
>Because listen
>> >>> 1047 * sockets are never in TCPS_ESTABLISHED, the
>V_tcbinfo lock
>> >>> will be
>> >>> 1048 * held in this case.
>> >>> 1049 */
>> >>> 1050 if (so->so_options & SO_ACCEPTCONN) {
>> >>> 1051 struct in_conninfo inc;
>> >>> 1052
>> >>> 1053 KASSERT(tp->t_state == TCPS_LISTEN, ("%s: so
>accepting
>> >>> but "
>> >>> 1054 "tp not listening", __func__));
>> >>> ...
>> >>> 1356 syncache_add(&inc, &to, th, inp, &so, m,
>NULL, NULL);
>> >>> 1357 /*
>> >>> 1358 * Entry added to syncache and mbuf
>consumed.
>> >>> 1359 * Everything already unlocked by
>syncache_add().
>> >>> 1360 */
>> >>> 1361 INP_INFO_UNLOCK_ASSERT(&V_tcbinfo);
>> >>> 1362 return;
>> >>> 1363 }
>> >>> ...
>> >>> 1384 /*
>> >>> 1385 * Segment belongs to a connection in SYN_SENT,
>ESTABLISHED or
>> >>> later
>> >>> 1386 * state. tcp_do_segment() always consumes the mbuf
>chain,
>> >>> unlocks
>> >>> 1387 * the inpcb, and unlocks pcbinfo.
>> >>> 1388 */
>> >>> 1389 tcp_do_segment(m, th, so, tp, drop_hdrlen, tlen,
>iptos,
>> >>> ti_locked);
>> >>>
>> >>> I think this has to do with this patch in soclose() where
>SO_ACCEPTCONN is
>> >>> being turned off in soclose(). I suspect if you look at the
>other threads
>> >>> in your corefile, you'll see one at this point in soclose()
>operating on
>> >>> the same socket as the one in the tcp_do_segment() thread.
>> >>>
>> >>> [2]http://svnweb.freebsd.org/base?view=revision&revision=243627
>> >>>
>> >>>817 /*
>> >>>818 * Prevent new additions to the accept
>queues due
>> >>>819 * to ACCEPT_LOCK races while we are
>draining them.
>> >>>820 */
>> >>>821 so->so_options &= ~SO_ACCEPTCONN;
>> >>>822 while ((sp = TAILQ_FIRST(&so->so_incomp))
>!= NULL) {
>> >>>823 TAILQ_REMOVE(&so->so_incomp, sp,
>so_list);
>> >>&
Re: bce(4) on the Dell PE 2950
On Fri, Apr 12, 2013 at 1:56 PM, Sean Bruno wrote: > A note from cluster...@freebsd.org > > It looks like there is some amount of instability or bugginess in some > of the Broadcom firmware(management) on the bce(4) chipeset shipped on > later generations of the Poweredge 2950 from Dell: > > bce0: > > Specifically, we've seen that newer (9 and higher) have issues with the > doing initial setup and negotiation and that Dell did indeed release > newer firmware to fix the issues. This requires a full reboot into > Linux (probably centos6) to get the update to execute. > > Sean More specifically.. this is the problematic revision: bce0: ASIC (0x57081020); Rev (B2); Bus (PCI-X, 64-bit, 133MHz); B/C (2.9.1); Bufs (RX:2;TX:2;PG:8); Flags (SPLT|MSI|MFW); MFW (NOT RUNNING!) and the upgrade takes you to bce0: ASIC (0x57081020); Rev (B2); Bus (PCI-X, 64-bit, 133MHz); B/C (5.0.4); Bufs (RX:2;TX:2;PG:8); Flags (SPLT|MSI|MFW); MFW (ipms 1.6.0) If you're seeing things like: bce0: ../../../dev/bce/if_bce.c(7906): Watchdog timeout occurred, resetting! over and over, then this would be a good thing to update. -- Peter Wemm - pe...@wemm.org; pe...@freebsd.org; pe...@yahoo-inc.com; KI6FJV ___ 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: Basic NAT server setup
On 2013-May-30 17:54:53 -0500, Joe Moog wrote:
>I'm building a server to handle outbound NAT to the internet using
>FreeBSD 9.1 and its built-in distribution of pf. What I want to be
>able to do is NAT three unique internal (private) VLANs to three
>unique public IPs.
>ext_if = "vlan11"
>ext_addr1 = "a.b.c.3"
>ext_addr2 = "a.b.c.4"
>ext_addr3 = "a.b.c.5"
>int_network1 = "10.0.1.0/24"
>int_network2 = "172.16.1.0/24"
>int_network3 = "192.168.1.0/24"
>nat on $ext_if from $int_network1 to any -> $ext_addr1
>nat on $ext_if from $int_network2 to any -> $ext_addr2
>nat on $ext_if from $int_network3 to any -> $ext_addr3
I don't see anything obviously wrong with what you've done. My initial
checks would be:
- Do you have the correct routes on the NAT box.
- Do you have a.b.c.{3,4,5} setup as aliases on vlan11 (or faked using
proxy ARP).
(My suspicion is the second point - packets are going out successfully
but the response is undeliverable because nothing is responding to the
switch's ARP requests for a.b.c.{3,4,5}).
Next would be to use tcpdump to do some snooping:
- Firstly, make sure the packets are are arriving on the NAT box with
appropriate src & dst IPs by tcpdump'ing the internal interface(s).
- Secondly, tcpdump the external interface and see what is going out
and returning (tcpdump will see the external addresses)
Finally, add some 'log' keywords and tcpdump pflog0. Unfortunately,
the stock FreeBSD tcpdump can't handle pflog packets. There are some
patches in bin/124825 but you will need to do some work to get them
to apply to the tcpdump in 9.1.
That will hopefully give you some pointers as to where to investigate.
--
Peter Jeremy
pgpKOuIGsvWtO.pgp
Description: PGP signature
Looking for a bgp listener that works with RADIX_MPATH / EQMP that's in HEAD
I'm looking for pointers to something that can listen to bgp default route announcements from two outbound gateways and set a RADIX_MPATH compatible default route based on whether one or both are alive. openbgpd from ports is extremely incompatible with RADIX_MPATH on 10. You *have* to turn off fib (kernel routing table) updates or it will destroy your machine when it runs out of physical memory for duplicate routes. I know I can do an evil hack and poll the 'bgp show ...' output and manually update the default route but that means updates are delayed to the poll interval. I'm hoping there is a more elegant solution that already works and is immediately responsive to a change in bgp state. The caveat is it *must* run on 10.x, with RADIX_MPATH enabled. I'd gladly run openbgpd if it actually worked. openbgpd has some awareness of mpath so it might be fixable but openbsd's multipath is different to ours. Ideas? -- Peter Wemm - pe...@wemm.org; pe...@freebsd.org; pe...@yahoo-inc.com; KI6FJV ___ 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: Looking for a bgp listener that works with RADIX_MPATH / EQMP that's in HEAD
On Sat, Jun 29, 2013 at 1:28 PM, Scott Long wrote:
> We run bird for this task. Can't say if it works on 10 since he haven't
> moved to 10 yet, but there have been some experiments with running
> a 10 kernel in the 9 userland and bird seems to behave fine with that.
>
> Scott
You run your kernels with RADIX_MPATH on 9.x?
Got an example config? In openbgpd speak, I'm doing this:
AS 65xxx
router-id 8.8.178.xx
neighbor 8.8.178.yy {
local-address 8.8.178.xx
remote-as 65xxx
announce none
}
neighbor 8.8.178.zz {
local-address 8.8.178.xx
remote-as 65xxx
announce none
}
match from 8.8.178.yy set { localpref 80 }
match from 8.8.178.zz set { localpref 80 }
The upstream nodes are doing, in part:
neighbor 8.8.178.ww {
local-address 8.8.178.yy
remote-as 65xxx
announce default-route
}
neighbor 8.8.178.xx {
local-address 8.8.178.yy
remote-as 65xxx
announce default-route
}
match to 8.8.178.ww set { metric 20 }
match to 8.8.178.xx set { metric 20 }
They're doing other things too, but thats the part that's relevant here.
> On Jun 29, 2013, at 1:50 PM, Peter Wemm wrote:
>
>> I'm looking for pointers to something that can listen to bgp default
>> route announcements from two outbound gateways and set a RADIX_MPATH
>> compatible default route based on whether one or both are alive.
>>
>> openbgpd from ports is extremely incompatible with RADIX_MPATH on 10.
>> You *have* to turn off fib (kernel routing table) updates or it will
>> destroy your machine when it runs out of physical memory for duplicate
>> routes.
>>
>> I know I can do an evil hack and poll the 'bgp show ...' output and
>> manually update the default route but that means updates are delayed
>> to the poll interval. I'm hoping there is a more elegant solution
>> that already works and is immediately responsive to a change in bgp
>> state.
>>
>> The caveat is it *must* run on 10.x, with RADIX_MPATH enabled. I'd
>> gladly run openbgpd if it actually worked. openbgpd has some
>> awareness of mpath so it might be fixable but openbsd's multipath is
>> different to ours.
>>
>> Ideas?
>> --
>> Peter Wemm - pe...@wemm.org; pe...@freebsd.org; pe...@yahoo-inc.com; KI6FJV
>> ___
>> 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"
>
--
Peter Wemm - pe...@wemm.org; pe...@freebsd.org; pe...@yahoo-inc.com; KI6FJV
On IRC, talking about C++:
I think that it is a good thing I will never meet Bjarne on a street
cause really, I don't want to end up in prison or anything
___
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: Looking for a bgp listener that works with RADIX_MPATH / EQMP that's in HEAD
On Sat, Jun 29, 2013 at 1:42 PM, Hiroki Sato wrote:
> Peter Wemm wrote
> in :
>
> pe> I'm looking for pointers to something that can listen to bgp default
> pe> route announcements from two outbound gateways and set a RADIX_MPATH
> pe> compatible default route based on whether one or both are alive.
> pe>
> pe> openbgpd from ports is extremely incompatible with RADIX_MPATH on 10.
> pe> You *have* to turn off fib (kernel routing table) updates or it will
> pe> destroy your machine when it runs out of physical memory for duplicate
> pe> routes.
> pe>
> pe> I know I can do an evil hack and poll the 'bgp show ...' output and
> pe> manually update the default route but that means updates are delayed
> pe> to the poll interval. I'm hoping there is a more elegant solution
> pe> that already works and is immediately responsive to a change in bgp
> pe> state.
> pe>
> pe> The caveat is it *must* run on 10.x, with RADIX_MPATH enabled. I'd
> pe> gladly run openbgpd if it actually worked. openbgpd has some
> pe> awareness of mpath so it might be fixable but openbsd's multipath is
> pe> different to ours.
> pe>
> pe> Ideas?
>
> Unfortunately openbgpd does not work well with RADIX_MPATH yet. As
> you pointed out, it is due to difference of multiple routes support
> between FreeBSD and OpenBSD. I think FIB handling can be improved,
> but needs some more investigation for that.
Yes, the port is extremely dangerous if RADIX_MPATH is enabled. It
does this sort of thing:
cmd = RTM_ADD
retry:
error = routectl(cmdl, data);
if (error && cmd == RTM_ADD) {
cmd = RTM_CHANGE;
goto retry;
}
In short, it creates duplicates every single time there's a fib change
if you enable RADIX_MPATH. This does not end well.
It appears that openbsd allows multiple overlapping routes to coexist
if they have a MPATH flag on them. Our radix structure is quite
different from what I understand, but the routing socket interface
causes openbgpd to accidently work and spam the rables.
> I think Quagga and BIRD can work with injecting ECMP routes into
> RADIX_MPATH-enabled FIB.
>
> -- Hiroki
I'm looking for some examples. See the bgpd.conf fragments I sent Scott.
--
Peter Wemm - pe...@wemm.org; pe...@freebsd.org; pe...@yahoo-inc.com; KI6FJV
On IRC, talking about C++:
I think that it is a good thing I will never meet Bjarne on a street
cause really, I don't want to end up in prison or anything
___
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: Terrible ix performance
On Wed, Jul 3, 2013 at 8:41 PM, Lawrence Stewart wrote: > - I recall some advice that zpool's should not have more than about 8 or > 10 disks in them, and you should instead create multiple zpools if you > have more disks. Perhaps investigate the source of that rumour and if > it's true, try create 2 x 8 disk zpools in Box A and 3 x 8 disk zpools > in box B and see if that changes things at all. http://nex7.blogspot.com/2013/03/readme1st.html Item #1: "1. Virtual Devices Determine IOPS IOPS (I/O per second) are mostly a factor of the number of virtual devices (vdevs) in a zpool. They are not a factor of the raw number of disks in the zpool. This is probably the single most important thing to realize and understand, and is commonly not. ZFS stripes writes across vdevs (not individual disks). A vdev is typically IOPS bound to the speed of the slowest disk within it. So if you have one vdev of 100 disks, your zpool's raw IOPS potential is effectively only a single disk, not 100. " -- end quote I made this mistake myself a number of times before I found out. -- Peter Wemm - pe...@wemm.org; pe...@freebsd.org; pe...@yahoo-inc.com; KI6FJV UTF-8: So you can \342\200\231 .. for when a ' just won't do ___ 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: how calculate the number of ip addresses in a range?
On Thu, Aug 8, 2013 at 12:04 AM, s m wrote:
> hello guys,
>
> i have a question about ip addresses. i know my question is not related to
> freebsd but i googled a lot and found nothing useful and don't know where i
> should ask my question.
>
> i want to know how can i calculate the number of ip addresses in a range?
> for example if i have 192.0.0.1 192.100.255.254 with mask 8, how many ip
> addresses are available in this range? is there any formula to calculate
> the number of ip addresses for any range?
>
> i'm confusing about it. please help me to clear my mind.
> thanks in advance,
My immediate reaction is.. is this a homework / classwork / assignment?
Anyway, you can think of it by converting your start and end addresses
to an integer. Over simplified:
$ cat homework.c
main()
{
int start = (192 << 24) | (0 << 16) | (0 << 8) | 1;
int end = (192 << 24) | (100 << 16) | (255 << 8) | 254;
printf("start %d end %d range %d\n", start, end, (end - start) + 1);
}
$ ./homework
start -1073741823 end -1067122690 range 6619134
The +1 is correcting for base zero. 192.0.0.1 - 192.0.0.2 is two
usable addresses.
I'm not sure what you want to do with the mask of 8.
You can also do it with ntohl(inet_addr("address")) as well and a
multitude of other ways.
--
Peter Wemm - pe...@wemm.org; pe...@freebsd.org; pe...@yahoo-inc.com; KI6FJV
UTF-8: for when a ' just won\342\200\231t do.
ZFS must be the bacon of file systems. "everything's better with ZFS"
___
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: how calculate the number of ip addresses in a range?
On Thu, Aug 8, 2013 at 2:46 PM, Matthew D. Fuller wrote: > On Thu, Aug 08, 2013 at 08:55:38AM -0700 I heard the voice of > Michael Sierchio, and lo! it spake thus: >> >> pkg_add -r ipsc > > For another, there's a "cidrcalc" program installed by devel/libcidr > (full disclosure: of which I'm the author) that does similar things I still suspect he was asking for somebody to do his homework for him. A third party tool doesn't work for that. He needs the math for it. -- Peter Wemm - pe...@wemm.org; pe...@freebsd.org; pe...@yahoo-inc.com; KI6FJV UTF-8: for when a ' just won\342\200\231t do. ZFS must be the bacon of file systems. "everything's better with ZFS" ___ 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: how calculate the number of ip addresses in a range?
On Fri, Aug 9, 2013 at 9:34 AM, Fleuriot Damien wrote:
>
> On Aug 8, 2013, at 10:27 AM, Peter Wemm wrote:
>
>> On Thu, Aug 8, 2013 at 12:04 AM, s m wrote:
>>> hello guys,
>>>
>>> i have a question about ip addresses. i know my question is not related to
>>> freebsd but i googled a lot and found nothing useful and don't know where i
>>> should ask my question.
>>>
>>> i want to know how can i calculate the number of ip addresses in a range?
>>> for example if i have 192.0.0.1 192.100.255.254 with mask 8, how many ip
>>> addresses are available in this range? is there any formula to calculate
>>> the number of ip addresses for any range?
>>>
>>> i'm confusing about it. please help me to clear my mind.
>>> thanks in advance,
>>
>> My immediate reaction is.. is this a homework / classwork / assignment?
>>
>> Anyway, you can think of it by converting your start and end addresses
>> to an integer. Over simplified:
>>
>> $ cat homework.c
>> main()
>> {
>> int start = (192 << 24) | (0 << 16) | (0 << 8) | 1;
>> int end = (192 << 24) | (100 << 16) | (255 << 8) | 254;
>> printf("start %d end %d range %d\n", start, end, (end - start) + 1);
>> }
>> $ ./homework
>> start -1073741823 end -1067122690 range 6619134
>>
>> The +1 is correcting for base zero. 192.0.0.1 - 192.0.0.2 is two
>> usable addresses.
>>
>> I'm not sure what you want to do with the mask of 8.
>>
>> You can also do it with ntohl(inet_addr("address")) as well and a
>> multitude of other ways.
>
>
> Hold on a second, why would you correct the base zero ?
> It can be a valid IP address.
There is one usable address in a range of 10.0.0.1 - 10.0.0.1.
Converting to an integer and subtracting would be zero. Hence +1.
--
Peter Wemm - pe...@wemm.org; pe...@freebsd.org; pe...@yahoo-inc.com; KI6FJV
UTF-8: for when a ' just won\342\200\231t do.
ZFS must be the bacon of file systems. "everything's better with ZFS"
___
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: how calculate the number of ip addresses in a range?
On Fri, Aug 9, 2013 at 4:07 PM, Kimmo Paasiala wrote:
> On Sat, Aug 10, 2013 at 1:44 AM, Peter Wemm wrote:
>> On Fri, Aug 9, 2013 at 9:34 AM, Fleuriot Damien wrote:
>>>
>>> On Aug 8, 2013, at 10:27 AM, Peter Wemm wrote:
>>>
>>>> On Thu, Aug 8, 2013 at 12:04 AM, s m wrote:
>>>>> hello guys,
>>>>>
>>>>> i have a question about ip addresses. i know my question is not related to
>>>>> freebsd but i googled a lot and found nothing useful and don't know where
>>>>> i
>>>>> should ask my question.
>>>>>
>>>>> i want to know how can i calculate the number of ip addresses in a range?
>>>>> for example if i have 192.0.0.1 192.100.255.254 with mask 8, how many ip
>>>>> addresses are available in this range? is there any formula to calculate
>>>>> the number of ip addresses for any range?
>>>>>
>>>>> i'm confusing about it. please help me to clear my mind.
>>>>> thanks in advance,
>>>>
>>>> My immediate reaction is.. is this a homework / classwork / assignment?
>>>>
>>>> Anyway, you can think of it by converting your start and end addresses
>>>> to an integer. Over simplified:
>>>>
>>>> $ cat homework.c
>>>> main()
>>>> {
>>>> int start = (192 << 24) | (0 << 16) | (0 << 8) | 1;
>>>> int end = (192 << 24) | (100 << 16) | (255 << 8) | 254;
>>>> printf("start %d end %d range %d\n", start, end, (end - start) + 1);
>>>> }
>>>> $ ./homework
>>>> start -1073741823 end -1067122690 range 6619134
>>>>
>>>> The +1 is correcting for base zero. 192.0.0.1 - 192.0.0.2 is two
>>>> usable addresses.
>>>>
>>>> I'm not sure what you want to do with the mask of 8.
>>>>
>>>> You can also do it with ntohl(inet_addr("address")) as well and a
>>>> multitude of other ways.
>>>
>>>
>>> Hold on a second, why would you correct the base zero ?
>>> It can be a valid IP address.
>>
>> There is one usable address in a range of 10.0.0.1 - 10.0.0.1.
>> Converting to an integer and subtracting would be zero. Hence +1.
>>
>> --
>
> To elaborate on this, for every subnet regardless of the address/mask
> combination there are two unusable addresses: The first address aka
> the "network address" and the last address aka the "broadcast
> address". There may be usable address in between the two that end in
> one of more zeros but those addresses are still valid. Some operating
> systems got this horribly wrong and marked any address ending with a
> single zero as invalid, windows 2000 was one of them.
>
> -Kimmo
If we go back to the orignal question: "if i have 192.0.0.1
192.100.255.254 how many ip addresses are available in this range?"
They're all in the same 192.0.0.0/8. Broadcast or sink addresses
don't factor into it.
--
Peter Wemm - pe...@wemm.org; pe...@freebsd.org; pe...@yahoo-inc.com; KI6FJV
UTF-8: for when a ' just won\342\200\231t do.
ZFS must be the bacon of file systems. "everything's better with ZFS"
___
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: it's the output, not ack coalescing (Re: TSO and FreeBSD vs Linux)
On Wed, Aug 14, 2013 at 11:11 AM, Adrian Chadd wrote: > On 14 August 2013 04:47, Lev Serebryakov wrote: > > >> And we should invalidate this info on ARP/route changes, or connection >> will be lost in such cases, am I right?.. So, on each such event code >> should look into all sockets and check, if routing/ARP information is >> still >> valid for them. Or we should store lists of sockets in routing and ARP >> tables... I don't know, what is worse. >> > > .. or per-CPU copies of the ARP table.. ? Local cache at each consumer and check a generation number to see if it needs to be re-validated before using. The obvious problem with this though is that big networks tend to kill your caches. -- Peter Wemm - pe...@wemm.org; pe...@freebsd.org; pe...@yahoo-inc.com; KI6FJV UTF-8: for when a ' just won\342\200\231t do. ZFS must be the bacon of file systems. "everything's better with ZFS" ___ 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"
M_NOFREE removal (was Re: svn commit: r254520 - in head/sys: kern sys)
Hi Andre, (moving to the more appropriate freebsd-net) I'm sorry for ambushing but this stuff has to be done. I have provided an alternative way of handling it and I'm happy to help you with your use case to make it good for you and to prevent the mbuf system from getting bloated and hackish again. Sure. I'm not really upset since my code wasn't too far along, but with any API, you never know who consumers might be so it's always worth being proactive about announcing it's removal. Can you please describe your intended use of M_NOFREE to better understand the shortcomings of the current mbuf systems and the additional advantages of the M_NOFREE case? I was looking at something similar to Linux's vhost-net, where a guest's virtio ring would be processed in-kernel. An mbuf chain with external buffers would be used to pass guest tx buffer/len segments directly into FreeBSD drivers. The intent of M_NOFREE was to avoid small mbuf allocations/frees in what is a hot path. This code was intended to run at 10/40G. Note this code isn't really generic - it would require interfaces to be 'owned' by the guest, except that direct PCI-level pass-through wouldn't be needed. If there's an alternative to M_NOFREE, I'd be more than happy to use that. later, Peter. ___ 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: M_NOFREE removal (was Re: svn commit: r254520 - in head/sys: kern sys)
If there's an alternative to M_NOFREE, I'd be more than happy to use that. Set up your own (*ext_free) function and omit freeing of the mbuf itself. Make sure to properly track your mbufs to avoid leaking them. Doesn't work: there's an unconditional free of the small mbuf. That's why I used M_NOFREE. later, Peter. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: kern/182665: [wlan] Kernel panic when creating second wlandev.
The following reply was made to PR kern/182665; it has been noted by GNATS. From: =?iso-8859-1?Q?Peter_Ankerst=E5l?= To: bug-follo...@freebsd.org, pe...@pean.org Cc: Subject: Re: kern/182665: [wlan] Kernel panic when creating second wlandev. Date: Wed, 9 Oct 2013 20:08:09 +0200 pciconf -lv ath0@pci0:7:0:0: class=3D0x028000 card=3D0x3114168c = chip=3D0x0030168c rev=3D0x01 hdr=3D0x00 vendor =3D 'Atheros Communications Inc.' device =3D 'AR9300 Wireless LAN adaptor' class =3D network ath1@pci0:13:0:0: class=3D0x028000 card=3D0x30a1168c = chip=3D0x002b168c rev=3D0x01 hdr=3D0x00 vendor =3D 'Atheros Communications Inc.' device =3D 'AR9285 Wireless Network Adapter (PCI-Express)' class =3D network= ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: kern/182665: [wlan] Kernel panic when creating second wlandev.
Sorry, had to rebuild kernel with debug symbols.
Heres the output:
(kgdb) list *0xc0800110
0xc0800110 is in jenkins_hash32 (/usr/src/sys/libkern/jenkins_hash.c:177).
172 switch(length) /* all the case statements fall
through */
173 {
174 case 3 : c+=k[2];
175 case 2 : b+=k[1];
176 case 1 : a+=k[0];
177 final(a,b,c);
178 case 0: /* case 0: nothing left to add */
179 break;
180 }
181 /*-- report the
result */
On Oct 9, 2013, at 11:18 PM, Adrian Chadd wrote:
> Hi,
>
> Is there a backtrace for this? Iv'e not seen this before.
>
>
> -adrian
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: kern/182665: [wlan] Kernel panic when creating second wlandev.
Hi!
Here is a new crash.
I have wlan0 set up with ath0 as wlandev and then when I run:
# ifconfig wlan1 create wlanmode hostap wlandev ath1
the machine crashes with this message:
Oct 11 09:25:00 gw syslogd: kernel boot file is /boot/kernel/kernel
Oct 11 09:25:00 gw kernel:
Oct 11 09:25:00 gw kernel:
Oct 11 09:25:00 gw kernel: Fatal trap 12: page fault while in kernel mode
Oct 11 09:25:00 gw kernel: cpuid = 1; apic id = 01
Oct 11 09:25:00 gw kernel: fault virtual address= 0x0
Oct 11 09:25:00 gw kernel: fault code = supervisor read, page
not present
Oct 11 09:25:00 gw kernel: instruction pointer = 0x20:0xc0800600
Oct 11 09:25:00 gw kernel: stack pointer= 0x28:0xe8d879e0
Oct 11 09:25:00 gw kernel: frame pointer= 0x28:0xe8d879e8
Oct 11 09:25:00 gw kernel: wlan1: Ethernet address: b0:48:7a:d5:fe:a2
Oct 11 09:25:00 gw kernel: code segment = base 0x0, limit
0xf, type 0x1b
Oct 11 09:25:00 gw kernel: = DPL 0, pres 1, def32 1, gran 1
Oct 11 09:25:00 gw kernel: processor eflags = interrupt enabled,
resume, IOPL = 0
Oct 11 09:25:00 gw kernel: current process = 2968 (bsnmpd)
Oct 11 09:25:00 gw kernel: trap number = 12
Oct 11 09:25:00 gw kernel: panic: page fault
Oct 11 09:25:00 gw kernel: cpuid = 1
Oct 11 09:25:00 gw kernel: KDB: stack backtrace:
Oct 11 09:25:00 gw kernel: #0 0xc078bfc2 at kdb_backtrace+0x52
Oct 11 09:25:00 gw kernel: #1 0xc07567f1 at panic+0x121
Oct 11 09:25:00 gw kernel: #2 0xc0a4ffb9 at trap_fatal+0x339
Oct 11 09:25:00 gw kernel: #3 0xc0a5024a at trap_pfault+0x27a
Oct 11 09:25:00 gw kernel: #4 0xc0a4fa46 at trap+0x5a6
Oct 11 09:25:00 gw kernel: #5 0xc0a3a20c at calltrap+0x6
Oct 11 09:25:00 gw kernel: #6 0xc083f635 at ieee80211_ioctl_getstainfo+0x55
Oct 11 09:25:00 gw kernel: #7 0xc083b244 at ieee80211_ioctl_get80211+0x434
Oct 11 09:25:00 gw kernel: #8 0xc08650b8 at in_control+0x228
Oct 11 09:25:00 gw kernel: #9 0xc080df53 at ifioctl+0x1943
Oct 11 09:25:00 gw kernel: #10 0xc07a7d5c at soo_ioctl+0x30c
Oct 11 09:25:00 gw kernel: #11 0xc07a0b4b at kern_ioctl+0x19b
Oct 11 09:25:00 gw kernel: #12 0xc07a0969 at sys_ioctl+0xe9
Oct 11 09:25:00 gw kernel: #13 0xc0a50823 at syscall+0x363
Oct 11 09:25:00 gw kernel: #14 0xc0a3a271 at Xint0x80_syscall+0x21
On 10/11/2013 12:31 AM, Adrian Chadd wrote:
what's the backtrace from the kernel crash?
That's a bit odd.. :-)
-adiran
On 10 October 2013 11:38, Peter Ankerstål mailto:pe...@pean.org>> wrote:
Sorry, had to rebuild kernel with debug symbols.
Heres the output:
(kgdb) list *0xc0800110
0xc0800110 is in jenkins_hash32
(/usr/src/sys/libkern/jenkins_hash.c:177).
172 switch(length) /* all the case
statements fall through */
173 {
174 case 3 : c+=k[2];
175 case 2 : b+=k[1];
176 case 1 : a+=k[0];
177 final(a,b,c);
178 case 0: /* case 0: nothing left to add */
179 break;
180 }
181 /*--
report the result */
On Oct 9, 2013, at 11:18 PM, Adrian Chadd mailto:adr...@freebsd.org>> wrote:
> Hi,
>
> Is there a backtrace for this? Iv'e not seen this before.
>
>
> -adrian
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: kern/182665: [wlan] Kernel panic when creating second wlandev.
Its a hostap. (What im trying to do is to set up a legacy 2.4GHz network on the
other interface)
> On 11 okt 2013, at 17:20, Adrian Chadd wrote:
>
> what's wlan0 setup as?
>
>
>
> -a
>
>
>> On 11 October 2013 00:28, Peter Ankerstål wrote:
>> Hi!
>>
>> Here is a new crash.
>>
>> I have wlan0 set up with ath0 as wlandev and then when I run:
>>
>> # ifconfig wlan1 create wlanmode hostap wlandev ath1
>>
>>
>> the machine crashes with this message:
>>
>> Oct 11 09:25:00 gw syslogd: kernel boot file is /boot/kernel/kernel
>> Oct 11 09:25:00 gw kernel:
>> Oct 11 09:25:00 gw kernel:
>> Oct 11 09:25:00 gw kernel: Fatal trap 12: page fault while in kernel mode
>> Oct 11 09:25:00 gw kernel: cpuid = 1; apic id = 01
>> Oct 11 09:25:00 gw kernel: fault virtual address= 0x0
>> Oct 11 09:25:00 gw kernel: fault code = supervisor read, page not
>> present
>> Oct 11 09:25:00 gw kernel: instruction pointer = 0x20:0xc0800600
>> Oct 11 09:25:00 gw kernel: stack pointer= 0x28:0xe8d879e0
>> Oct 11 09:25:00 gw kernel: frame pointer= 0x28:0xe8d879e8
>> Oct 11 09:25:00 gw kernel: wlan1: Ethernet address: b0:48:7a:d5:fe:a2
>> Oct 11 09:25:00 gw kernel: code segment = base 0x0, limit 0xf,
>> type 0x1b
>> Oct 11 09:25:00 gw kernel: = DPL 0, pres 1, def32 1, gran 1
>> Oct 11 09:25:00 gw kernel: processor eflags = interrupt enabled, resume,
>> IOPL = 0
>> Oct 11 09:25:00 gw kernel: current process = 2968 (bsnmpd)
>> Oct 11 09:25:00 gw kernel: trap number = 12
>> Oct 11 09:25:00 gw kernel: panic: page fault
>> Oct 11 09:25:00 gw kernel: cpuid = 1
>> Oct 11 09:25:00 gw kernel: KDB: stack backtrace:
>> Oct 11 09:25:00 gw kernel: #0 0xc078bfc2 at kdb_backtrace+0x52
>> Oct 11 09:25:00 gw kernel: #1 0xc07567f1 at panic+0x121
>> Oct 11 09:25:00 gw kernel: #2 0xc0a4ffb9 at trap_fatal+0x339
>> Oct 11 09:25:00 gw kernel: #3 0xc0a5024a at trap_pfault+0x27a
>> Oct 11 09:25:00 gw kernel: #4 0xc0a4fa46 at trap+0x5a6
>> Oct 11 09:25:00 gw kernel: #5 0xc0a3a20c at calltrap+0x6
>> Oct 11 09:25:00 gw kernel: #6 0xc083f635 at ieee80211_ioctl_getstainfo+0x55
>> Oct 11 09:25:00 gw kernel: #7 0xc083b244 at ieee80211_ioctl_get80211+0x434
>> Oct 11 09:25:00 gw kernel: #8 0xc08650b8 at in_control+0x228
>> Oct 11 09:25:00 gw kernel: #9 0xc080df53 at ifioctl+0x1943
>> Oct 11 09:25:00 gw kernel: #10 0xc07a7d5c at soo_ioctl+0x30c
>> Oct 11 09:25:00 gw kernel: #11 0xc07a0b4b at kern_ioctl+0x19b
>> Oct 11 09:25:00 gw kernel: #12 0xc07a0969 at sys_ioctl+0xe9
>> Oct 11 09:25:00 gw kernel: #13 0xc0a50823 at syscall+0x363
>> Oct 11 09:25:00 gw kernel: #14 0xc0a3a271 at Xint0x80_syscall+0x21
>>
>>
>>
>>> On 10/11/2013 12:31 AM, Adrian Chadd wrote:
>>> what's the backtrace from the kernel crash?
>>>
>>> That's a bit odd.. :-)
>>>
>>>
>>>
>>> -adiran
>>>
>>>
>>>
>>> On 10 October 2013 11:38, Peter Ankerstål >> <mailto:pe...@pean.org>> wrote:
>>>
>>> Sorry, had to rebuild kernel with debug symbols.
>>>
>>> Heres the output:
>>>
>>> (kgdb) list *0xc0800110
>>> 0xc0800110 is in jenkins_hash32
>>> (/usr/src/sys/libkern/jenkins_hash.c:177).
>>> 172 switch(length) /* all the case
>>> statements fall through */
>>> 173 {
>>> 174 case 3 : c+=k[2];
>>> 175 case 2 : b+=k[1];
>>> 176 case 1 : a+=k[0];
>>> 177 final(a,b,c);
>>> 178 case 0: /* case 0: nothing left to add */
>>> 179 break;
>>> 180 }
>>> 181 /*--
>>> report the result */
>>>
>>>
>>> On Oct 9, 2013, at 11:18 PM, Adrian Chadd >> <mailto:adr...@freebsd.org>> wrote:
>>>
>>> > Hi,
>>> >
>>> > Is there a backtrace for this? Iv'e not seen this before.
>>> >
>>> >
>>> > -adrian
>
___
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"
Unable to use pf(4) NAT with jail on 9.2-RELEASE
I am trying to configure a new firewall and want to run squid in a jail but have been unsuccessful in getting outgoing NAT to work. I have previously used jails on 8.x and 10.x with traffic going both into and out of jails but I admit this is the first time I've tried to use NAT on the outgoing traffic. I've tried attaching the jail to each of lo0, lo1 using a 127/8 address; lo1, the internal and the external interface using a dummy (RFC1918) address and the internal interface using a valid-for-my-internal-network RFC1918 address, using a NAT rule like: nat on $ext_if from $jail_subnet to any -> $ext_addr Monitoring the external interface on another host, either no packets are transmitted (for the 127/8 addresses) or the source address is the unchanged RFC1918 address unchanged. As a specific example: In rc.conf: jail_squid_ip="198.168.120.4" # Dummy address jail_squid_interface="em0" # Internal interface jail_squid_exec_start="/usr/bin/fetch -o /tmp/zzz https://223.223.223.1/"; Complete pf.conf: nat log on re0 from 192.168.120.4/32 to any -> 223.223.223.2 pass quick all (changing the /32 to /24 makes no difference). ifconfig whilst the jail is trying to start: em0: flags=8843 metric 0 mtu 1500 options=4019b inet 192.168.123.124 netmask 0xff00 broadcast 192.168.123.255 inet 198.168.120.4 netmask 0x broadcast 198.168.120.4 re0: flags=8843 metric 0 mtu 1500 options=8209b inet 223.223.223.2 netmask 0xfffc broadcast 223.223.223.3 And tcpdump on a system connected to re0 shows: 21:25:44.030983 IP 198.168.120.4.36205 > 223.223.223.1.443: Flags [S], seq 1462646452, win 65535, options [mss 1460,nop,wscale 6,sackOK,TS val 712899226 ecr 0], length 0 (the source address should be 223.223.223.2). OTOH, if I use a more complete pf.conf and initiate the connection either on the host or on an "internal" box set to route through the firewall, everything works as expected. What am I doing wrong? -- Peter Jeremy pgpHe3KFE2Zph.pgp Description: PGP signature
Re: mbuf_cluster (FAIL SLEEP)
On 5/23/14, 6:18 AM, Peter B. Pokryshev wrote: Hi. Is it normal after 16 days of uptime: # vmstat -z ITEM SIZE LIMIT USED FREE REQ FAIL SLEEP ... 16 Bucket: 152, 0, 24, 101, 193, 0, 0 32 Bucket: 280, 0, 38, 102, 329, 2, 0 64 Bucket: 536, 0, 30, 33, 487, 142, 0 128 Bucket:1048, 0, 997, 11, 6717030,17345735, 0 ... mbuf_packet:256, 12896820,1449,1646,9062649837,118865, 0 mbuf: 256, 12896820,2193,1762,17686258507, 0, 0 mbuf_cluster: 2048, 2015128,3095,1793,26759484,241537,1100807 mbuf_jumbo_page: 4096, 1007563,2160, 864,2326876443, 0, 0 mbuf_jumbo_9k: 9216, 298537, 0, 0, 0, 0, 0 mbuf_jumbo_16k: 16384, 167927, 0, 0, 0, 0, 0 mbuf_ext_refcnt: 4, 0, 0, 0, 0, 0, 0 I mean 128 Bucket (FAIL) and mbuf_cluster (FAIL SLEEP) Yes, this is normal and it doesn't mean what you might expect. It's a generic failure counter, not an allocation failure counter. eg: if an object that was just freed fails to fit in a per-cpu free items cache it counts as a "FAIL". -Peter ___ 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: pow function in kernel space
On 2014-Jun-19 20:40:48 +0800, 张晗 wrote: >how can I implement, in an efficient, way the pow() function in kernel space ? > Is there any function I can use o r how I can evaluate pow function in kernel >model? Since the kernel only offers integer arithmetic, one approach would be square and multiply. What are you trying to do? Maybe we can offer an alternative to pow(3). -- Peter Jeremy pgp6AHdKYOfNS.pgp Description: PGP signature
Re: problem with vlan interfaces tagging/untagging in a simulated switch box
On 2012-Mar-04 10:01:07 +0330, h bagade wrote: >I have problems with vlan interfaces on freebsd. I want to make my >system like a switch with vlan ports and also a trunk port in >conjuction with other switches. I thought that vlan interfaces would >help me tagging traffic when traffic is going out the trunk port(or >when it receives on vlan ports). >The problem, I've encountered is that vlan interafaces on freebsd do >tagging/untagging when the traffic is sourced/destined from/to them >which in this case they should be assigned IP addresses. In other >words they won't tag the traffic passing through their parent >interface which I need to. I am doing this with no problems so I suspect you are doing something wrong. As an example, the following creates a IEEE802.1Q trunk on em0 with 192.168.1.0/24 untagged and the remaining subnett tagged: ifconfig em0 inet 192.168.1.123/24 ifconfig vlan10 inet 192.168.10.123/24 vlandev em0 vlan 10 ifconfig vlan11 inet 192.168.11.123/24 vlandev em0 vlan 11 ifconfig vlan12 inet 192.168.12.123/24 vlandev em0 vlan 12 ifconfig vlan13 inet 192.168.13.123/24 vlandev em0 vlan 13 Can you post the rc.conf etc entries that you are using and a description of what you are trying to achieve. -- Peter Jeremy pgppcO8hHBl6F.pgp Description: PGP signature
Re: problem with vlan interfaces tagging/untagging in a simulated switch box
Please don't top-post. On 2012-Mar-05 13:30:36 +0330, h bagade wrote: >on layer 2 switch, ports doesn't have ip addresses and traffic comming >from a vlan port is tagged and pass through trunk port. this means >that in our freebsd box which plays the role of switch, no interfaces >should have ip addresses. OK. Sorry, I misunderstood what you were trying to achieve. I am using FreeBSD as a router rather than a switch. That said, I suspect your problem is that you are misunderstanding how VLAN tagging is applied. If a packet flows through a vlan(4) device, the appropriate tag is removed from incoming (from the network) packets and added to outgoing (to the network) packets. Packets flowing through normal ethernet devies (your ethX) without also flowing through a vlan(4) are not tagged (and so will appear in the default vlan as far as an external switch is concerned). Internally (ie as seen by bridge(4) instances), packets are not tagged. The following example diagram shows 3 distinct packet flows: - packets tagged 5 in trunk1 and 6 in trunk0 - packets tagged 7 in trunk1 and 9 in trunk0 - packets tagged 8 in trunk0 and 10 in trunk2 +-- vlan5 --- bridge1 --- vlan6 --+ | | trunk1 --- eth1 -+- vlan7 --- bridge2 --- vlan9 --+-- eth0 --- trunk0 | bridge3 --- vlan8 --+ | trunk2 -- eth2 --- vlan10 This would be configured as: ifconfig vlan5 vlan 5 vlandev eth1 ifconfig vlan6 vlan 6 vlandev eth0 ifconfig vlan7 vlan 7 vlandev eth1 ifconfig vlan8 vlan 8 vlandev eth0 ifconfig vlan9 vlan 9 vlandev eth0 ifconfig vlan10 vlan 10 vlandev eth2 ifconfig bridge1 addm vlan5 addm vlan6 ifconfig bridge2 addm vlan7 addm vlan9 ifconfig bridge3 addm vlan8 addm vlan10 -- Peter Jeremy pgp7griifAX2e.pgp Description: PGP signature
Re: problem with vlan interfaces tagging/untagging in a simulated switch box
On 2012-Mar-06 09:15:57 +0330, h bagade wrote: >On 3/6/12, Peter Jeremy wrote: >> The following example diagram shows 3 distinct packet flows: >> - packets tagged 5 in trunk1 and 6 in trunk0 >> - packets tagged 7 in trunk1 and 9 in trunk0 >> - packets tagged 8 in trunk0 and 10 in trunk2 >> >> +-- vlan5 --- bridge1 --- vlan6 --+ >> | | >> trunk1 --- eth1 -+- vlan7 --- bridge2 --- vlan9 --+-- eth0 --- trunk0 >>| >>bridge3 --- vlan8 --+ >> | >> trunk2 -- eth2 --- vlan10 >> >I've described the function of Cisco switches in vlan >tagging/untagging. Real switches typically have everything tagged internally, with the native VLAN tags added/removed at the ingress/egress ports. This simplifies the internal switch logic (at the expense of meaning that tags have to be consistent across all trunks). FreeBSD works differently. Packets are _untagged_ internally and you need a separate bridge(4) device for each broadcast domain (vlan). > In your topology, packets should be tagged when >recieved on real interfaces to be send out to vlan interfaces. Packets are never tagged by real interfaces and always have tags added/removed by vlan devices. > It >would be fine when two trunks are communicating because on both side >packets are tagged. But as I mentioned before, Cisco switches receive >packets on an interface untagged and then sending packets tagged out >of trunk port, based on which interface it receives, You can connect a physical interface (ethX) directly to a bridge device to access untagged packets. Note that I'm not sure whether it is safe to access the native VLAN in a trunk in this way. To continue the above example, ifconfig bridge1 addm eth3 would result in packets arriving on eth3 leaving tagged as vlan 5 in trunk1, vlan 6 in trunk0 and vice versa. -- Peter Jeremy pgphisjpKbXaP.pgp Description: PGP signature
Re: lagg problems on diskless client
On 2012-Mar-28 13:16:06 +0300, "Raif S. Berent" wrote: >I have some problems implementing lagg(4) on dual NIC's on the diskless >client side. It may be because my switch is a cheap, un-managed Gbit switch >or hopefully some other reason. I would like to either get lagg working >properly or find an alternative method of solving the problem. Whilst I haven't specifically done this, I have done diskless booting on a wired NIC and then switched to a wired/wifi lagg. Have a look at http://www.bugs.au.freebsd.org/dokuwiki/doku.php/laggdiskless >I concede that under this structure lagg's loadbalance or LACP are probably >not going to work. FEC & LACP require support at both ends and so won't work. loadbalance & roundrobin should work but aren't really appropriate unless your interfaces are identical. >In general, as soon as lagg is brought up, NIC pool no longer responds to >pings and gives an "I'm busy now" message. Yes. Once you create the lagg, the interfaces comprising it will no longer work standalone and you can't atomically migrate the IP address from re0 to lagg0 - hence the script linked from the above page. -- Peter Jeremy pgpCaYsWbFQTE.pgp Description: PGP signature
Re: lagg problems on diskless client
Please don't top post. On 2012-Apr-02 12:25:06 +0300, Beeblebrox wrote: >I had looked into failover with wireless and tried it before posting, but >got nowhere. Wired/wireless on a diskfull system should be trivial. >1. With below setup in diskless client's rc.conf, the client is able to >boot and gets to login screen: >ifconfig_re1="up ether 00:30:67:91:6c:c2" >cloned_interfaces="lagg0" >ifconfig_lagg0="up laggproto failover laggport re1 192.168.2.2 netmask >255.255.255.0" Assuming you're netbooting off re0, that looks correct. >2. ifconfig at that point shows all good: same mac addr and lagg0 active. >re0: flags=8843 metric 0 mtu 1500 >options=8209b >ether 00:30:67:91:6c:c2 >inet 192.168.2.2 netmask 0xff00 broadcast 192.168.2.255 This is wrong - there should't be an IP address on re0 at this point. >media: Ethernet autoselect (100baseTX ) >status: active >re1: flags=8843 metric 0 mtu 1500 >options=8209b >ether 00:30:67:91:6c:c2 >media: Ethernet autoselect (1000baseT ) >status: active >lagg0: flags=8843 metric 0 mtu 1500 >options=8209b >ether 00:30:67:91:6c:c2 >media: Ethernet autoselect >status: active >laggproto failover >laggport: re1 flags=5 > >Now if I go and unplug NIC10/100 on diskless client and "list folder", the >client will freeze - so failover does not switch. After some time passes, >client informs that NFS server 192.168.2.1 is not responding. lagg0 shows only one laggport so there's no failover. Are you sure you installed /etc/rc.d/lagg or an equivalent script? >PS- I mistakenly double-posted: >http://docs.freebsd.org/cgi/getmsg.cgi?fetch=39210+0+current/freebsd-net I replied to this one because it had a meaningful subject. -- Peter Jeremy pgpInbilVoAg2.pgp Description: PGP signature
Re: lagg problems on diskless client
On 2012-Apr-03 14:51:57 +0300, Beeblebrox wrote: >Slightly different point of view: Under this scenario of dikless clients >having dual NICs would CRAP be a choice to consider? From what I have read >it can offer loadbalancing but as I understand it's not really applicable >to diskless node situations? (Two amusing typos in one sentence). Based on what you've said so far, no. carp provides load-balancing or failover between two (or more) hosts. lagg provides load-balancing or failover between two (or more) NICs on one host. -- Peter Jeremy pgpQkf5nduxKw.pgp Description: PGP signature
Re: lagg problems on diskless client
On 2012-Apr-03 13:17:50 +0300, Beeblebrox wrote: >> Please don't top post. >Wasn't aware I was doing that. This is better I hope? Yes but there's no need to quote the entire mail you're replying to. >> Are you sure you installed /etc/rc.d/lagg or an equivalent script? >I had not noticed the link to the script at the bottom - I placed script in >DC's private conf//etc/rc.d then booted the DC. I got system freeze and >1 message: >ifconfig: interface re0 cannot change link address! >looking through the script I found the problem: lagg_tmp:=/mnt. My DC /root >is *ro* so I'll have to change it to another tmp. Actually, it doesn't matter that the root is RO, just that /mnt exists so it can be used as a mountpoint. And, BTW, I've just noticed that, whilst $lagg_tmp is parameterised. /mnt is also hard-coded in several places in the script. Sorry about that. > Considering that my /var >and /etc are md-mounted, using either seems out of the question. I also >have /tmp mounted as tmpfs. Can I mkdir -p /tmp/lagg and mount lagg_tmp >there or does it have to be an NFS shared location - what do you suggest? AFAIR, I use a separate ramdisk because /etc/rc.d/lagg runs very early and other mountpoints cannot be relied on. -- Peter Jeremy pgprrfdNpGEnW.pgp Description: PGP signature
dhclient behaviour on link status changes
/etc/devd.conf includes a rule to start dhclient when an Ethernet or 802.11 interface reports "link up", with a comment: "No link down rule exists because dhclient automatically exits when the link goes down." IMHO, this is the desired behaviour, unfortunately it's not the way dhclient actually behaves. In my experience, dhclient will exit when the interface goes down but ignores link status changes. Looking at the source, it seems to exit only when there's no usable route (by monitoring RTF_UP). dhclient does monitor the link status using SIOCGIFMEDIA but only at startup (it will exit if the link doesn't come up within 10s of dhclient starting) and during DHCP exchanges (if the link goes down when it's expecting a DHCP response then it exits). Can anyone explain the rationale behind the current behaviour? -- Peter Jeremy pgpBpISxeP8qg.pgp Description: PGP signature
Re: dhclient behaviour on link status changes
On 2012-Apr-05 07:17:49 +1000, Peter Jeremy wrote: >/etc/devd.conf includes a rule to start dhclient when an Ethernet or >802.11 interface reports "link up", with a comment: "No link down rule >exists because dhclient automatically exits when the link goes down." >IMHO, this is the desired behaviour, unfortunately it's not the way >dhclient actually behaves. In my experience, dhclient will exit when >the interface goes down but ignores link status changes. I found an easy way to correct the behaviour & submitted bin/166656 -- Peter Jeremy pgpiKcpO4qBUI.pgp Description: PGP signature
Re: dhclient behaviour on link status changes
On 2012-Apr-05 13:22:37 -0700, YongHyeon PYUN wrote: >On Thu, Apr 05, 2012 at 12:39:46PM +1000, Peter Jeremy wrote: >> On 2012-Apr-05 07:17:49 +1000, Peter Jeremy wrote: >> >/etc/devd.conf includes a rule to start dhclient when an Ethernet or >> >802.11 interface reports "link up", with a comment: "No link down rule >> >exists because dhclient automatically exits when the link goes down." >> >IMHO, this is the desired behaviour, unfortunately it's not the way >> >dhclient actually behaves. In my experience, dhclient will exit when >> >the interface goes down but ignores link status changes. >> >> I found an easy way to correct the behaviour & submitted bin/166656 >Hmm, wouldn't this make dhclient die when speed/duplex/flow control >of established connection is changed by admin or remote link partner? >For instance, >#ifconfig foo0 media mdiaopt flow If the speed/duplex/flow control change triggered a "LINK DOWN" "LINK UP" kernel message then, yes, that would cause dhclient to restart. I think that depends on the NIC. I guess a potential work-around would be to have dhclient ignore outages shorter than a configurable value. I hadn't considered that because it's not something that I ever do on a running system. (This investigation was prompted by my ISP's approach to address grooming - they just remotely reboot the cablemodem and expect clients to re-DHCP. Existing valid leases are just ignored. Since the FreeBSD dhclient ignores the link outage, I just lose Internet connectivity until I manually restart DHCP). -- Peter Jeremy pgpb45UOdBj73.pgp Description: PGP signature
Re: System doesn't detect unplugged network cable and doesn't set interface up properly with DHCP
On 2012-Jul-12 13:41:39 -0700, Yuri wrote: >I have the simplest possible DHCP setup: ifconfig_re0="DHCP" in >/etc/rc.conf. > >When the system boots, it gets connected fine. > >Now, I disconnect my laptop and connect it to another network. >When cable is disconnected, IP address of this interface stays the same, >old one is not removed. >When I plug it into another network, the same IP address stays. New IP >doesn't get set. This is bad. >So I have to manually do 'ifconfig re0 down && remove && >ifconfig re0 up'. This is a bug in dhclient - see PR bin/166656, which includes a fix. -- Peter Jeremy pgpo1p1TtzlQz.pgp Description: PGP signature
Re: System doesn't detect unplugged network cable and doesn't set interface up properly with DHCP
On 2012-Jul-31 09:43:00 -0400, John Baldwin wrote: >On Saturday, July 14, 2012 3:51:25 am Jason Hellenthal wrote: >> >> On Fri, Jul 13, 2012 at 11:20:36AM -0700, Yuri wrote: >> > But even if it exits, it leaves the IP address that it has set, which is >> > wrong. This IP address survives through the next DHCP setup process and >ends up being the second IP address. >> > Should be very easy to on exit remove any IP address that was set during >> > dhclient process lifetime. >> >> I couldnt agree more. Interface tear down is definately needed here. > >Hmmm, this does seem true. Do you either of you have any patches for this, >or Peter, can you extend your patch to do this? It's not a case that I initially considered and I don't currently have a patch for this. I'll have a look into it. -- Peter Jeremy pgpVPl5hJPMBM.pgp Description: PGP signature
Re: System doesn't detect unplugged network cable and doesn't set interface up properly with DHCP
On 2012-Jul-13 11:20:36 -0700, Yuri wrote: >On 07/13/2012 02:48, Peter Jeremy wrote: >> This is a bug in dhclient - see PR bin/166656, which includes a fix. > >I think this PR addresses part of the problem: dhclient doesn't exit when the >link goes down. >But even if it exits, it leaves the IP address that it has set, which is >wrong. This IP address survives through the next DHCP setup process and ends >up being the second IP address. >Should be very easy to on exit remove any IP address that was set during >dhclient process lifetime. I agree that it _should_ be easy to remove the existing address and the existing patch in that PR should already do that. Unfortunately, there seems to be another issue in dhclient that means that it isn't. -- Peter Jeremy pgp2wKcx4d2CT.pgp Description: PGP signature
Re: System doesn't detect unplugged network cable and doesn't set interface up properly with DHCP
On 2012-Aug-17 11:48:17 -0400, John Baldwin wrote: >Hmm, I think I see the issue. It doesn't export the existing lease info to >the script when running the FAIL action. I just tested this change and it >removed the old IP on my laptop when I tested it just now. I did some investigating during the week and came to pretty much the same patch. But the existing "don't remove an existing address" behaviour looked like a design decision and I went digging to find exactly what ip->client->active represented - and, in particular, whether in could represent an address that dhclient hadn't added to the interface. I did find that it could be read from the leases file but didn't have time to fully work through the code. If you're happy that this patch can't incorrectly remove a pre-existing IP address (I'm now reasonably confident that it can't), then I'm happy that it otherwise works. -- Peter Jeremy pgprjxR90uyyW.pgp Description: PGP signature
Incorrect ARP table entries
I've run into a problem where the ARP table on several of my hosts is
apparently spontaneously replacing correct entries with incorrect MAC
addresses. I've done some digging with tcpdump and can't identify the
cause. I've tried to look in the code but lost my way since ARP and
IP routing seem to be closely intermingled. I'm hoping someone might
be able to shed some light on why it is behaving the way it is.
A rough diagram of the relevant part of the network is:
+-++-+
| | [1]| |
| local || |
| || |[3] +-+
+++| || |
H [2] | switch || remot |
+++| || |
| || |[4] +-+
| peer || |
| || |
+-++-+
The hosts seeing the problem are running 8.2p2/amd64 ("local") and
8.3p3/i386 ("peer") using pf/carp for failover. The remote host
("remot") is a HP DL380 running FreeBSD (various between 7 and 10).
My problem is that the entry for the DL380 iLO ([3], in vlan 157) is
randomly having the correct MAC address replaced with the MAC address
of the main interface ([4]). Note that the iLO is a physically
separate NIC.
'=' are all dual GigE links bonded using lagg/lacp with about 73 vlans
inside them.
[1] MAC "local-nic", IP addresses "local-157" in the iLO vlan (157) and
"local-ip" in vlan 91.
[2] cross-over cables joining dual FastE NICs bonded using lagg/lacp
carrying pfsync traffic only.
[3] DL380 iLO connected to a non-trunked switch port in vlan 157.
MAC "remot-ilo", IP "remo-mgmt".
[4] DL380 bge interfaces. MAC "remot-nic" and "remot-ip" in vlan 91.
vlan 157 in configured at the switch end but not used at the host
end (no interface in vlan 157 is created).
Wheen I run:
tcpdump -e -i lagg0 'ether host remot-nic or arp or (vlan and arp)'
on "local", the only references to remot-nic or remot-ilo are
(starting following an "arp -d remo-mgmt"):
12:15:41.481523 local-nic > broadcast, vlan 157, ARP, Request who-has remo-mgmt
tell local-157
12:15:41.481853 remot-ilo > local-nic, vlan 157, ARP, Reply remo-mgmt is-at
remot-ilo
12:15:43.337303 remot-nic > local-nic, vlan 91, IPv4, remot-ip.123 >
local-ip.123: NTPv4
12:15:43.337854 local-nic > remot-nic, vlan 91, IPv4, local-ip.123 >
remot-ip.123: NTPv4
12:16:46.338434 remot-nic > local-nic, vlan 91, IPv4, remot-ip.123 >
local-ip.123: NTPv4
12:16:46.338968 local-nic > remot-nic, vlan 91, IPv4, local-ip.123 >
remot-ip.123: NTPv4
12:17:50.338196 remot-nic > local-nic, vlan 91, IPv4, remot-ip.123 >
local-ip.123: NTPv4
12:17:50.339027 local-nic > broadcast, vlan 91, ARP, Request who-has remot-ip
tell local-ip
12:17:50.339253 remot-nic > local-nic, vlan 91, ARP, Reply remot-ip is-at
remot-nic
12:17:50.339272 local-nic > remot-nic, vlan 91, IPv4, local-ip.123 >
remot-ip.123: NTPv4
12:17:52.338532 remot-nic > broadcast, vlan 91, ARP, Request who-has other1
tell remot-ip
12:18:01.338517 remot-nic > broadcast, vlan 91, ARP, Request who-has other2
tell remot-ip
12:18:53.337620 remot-nic > local-nic, vlan 91, IPv4, remot-ip.123 >
local-ip.123: NTPv4
12:18:53.338145 local-nic > remot-nic, vlan 91, IPv4, local-ip.123 >
remot-ip.123: NTPv4
12:19:12.499330 remot-ilo > broadcast, vlan 157, ARP, Request who-has local-157
(local-nic) tell remo-mgmt
12:19:12.499353 local-nic > remot-nic, vlan 157, ARP, Reply local-157 is-at
local-nic
And I find in /var/log/messages:
Aug 22 12:19:12 local kernel: arp: remo-mgmt moved from remot-ilo to remot-nic
on vlan157
The ARP mapping for remo-mgmt to remot-ilo was correct following the
ARP exchange at 12:15:41 but at 12:19:12, "local" responds to the
wrong MAC address when replying to an ARP request. In the intervening
period, there are no references to "remot-nic" in vlan 157 or any ARP
requests mentioning remo-mgmt.
--
Peter Jeremy
pgpF24vJB31sZ.pgp
Description: PGP signature
Re: Incorrect ARP table entries
On 2012-Aug-22 14:02:01 +1000, Peter Jeremy wrote: >I've run into a problem where the ARP table on several of my hosts is >apparently spontaneously replacing correct entries with incorrect MAC >addresses. I've done some digging with tcpdump and can't identify the >cause. I've tried to look in the code but lost my way since ARP and >IP routing seem to be closely intermingled. I'm hoping someone might >be able to shed some light on why it is behaving the way it is. I've done some more detailed trawling through tcpdump captures and found that this is another entry in the "never buy HP" collection. It turns out the iLO is sending ARP requests with the correct link- layer source MAC address in the Ethernet frame but the "sender hardware address" in the ARP request is wrong - and (as required by RFC826) FreeBSD is using the latter MAC address to update its ARP table. Note that this iLO has a physically separate NIC and doesn't have provision for shared NIC so there's no excuse for it's behaviour. RFC826 is fairly clear that FreeBSD is behaving correctly in using the "sender hardware address" in the ARP request (though it doesn't specifically address the case where that is different to the link-layer source address). My work-around is to use arp(8) to permanently wire the correct MAC address into the local ARP table. -- Peter Jeremy pgp6S4zfEJu8G.pgp Description: PGP signature
Re: bridging VLAN interfaces and STP
On 2012-Aug-26 08:12:51 -0400, "Dustin J. Mitchell" wrote: >On Sat, Aug 25, 2012 at 7:04 PM, Dustin J. Mitchell wrote: >> Hey folks. I'm trying to set up a system with one 802.1q-tagged >> upstream, and a few untagged interfaces. So I'd like to bridge the >> vlan(4) interfaces on vr1 to specific other interfaces. Can you provide ifconfig output covering all the relevant interfaces. >And I can verify that STP's *not* working on those interfaces because >I just inadvertently created a forwarding loop. I'm not sure if this is intentional. >Incidentally, it makes sense in retrospect, but the if_bridge(4) >manpage doesn't mention that gateway_enable is required for bridging >to actually forward packets. If this is true, it's definitely wrong and a regression. gateway_enable relates to routing not bridging. -- Peter Jeremy pgp0tKR7gtvaX.pgp Description: PGP signature
Re: Problem with link aggregation + sshd
On 2012-Aug-21 23:18:15 +0200, Giulio Ferro wrote: >Scenario : freebsd 9 stable (yesterday) amd64 on HP server with 4 nic (igb) I have used lagg/lacp on 7.x, 8.x, 9.x and 10.x and haven't seen this problem. Can you please provide ifconfig output for all interfaces. -- Peter Jeremy pgpLMiR9Ws9DE.pgp Description: PGP signature
Re: Problem adding more than 8 network adapters
On 2012-Aug-28 11:44:44 +0200, Gustau Pérez i Querol wrote: > I'm running FreeBSD 9.1 RC1/AMD64 with VirtualBox. The problem I'm >facing is that I can't use more than 8 network adapters plugged to the >virtual machine. ... >I don't know if it's a net@ problem or maybe it is a problem with >the emulated PCI-bridge and then stable@ should be contacted. Also, I'm >not sure if a real machine would support more than 8 network adapters or >not. Any hints would be appreciated. I don't think I've ever used more than 6 physical NICs in a host but don't know of any reason for >8 to not work. Can you please post a "pciconf -lv" from FreeBSD and the equivalent "lspci" from Linux. A FreeBSD verbose boot log might also help. -- Peter Jeremy pgpXqtGGMbTJs.pgp Description: PGP signature
Re: bridging VLAN interfaces and STP
Sorry for the delay, Real Life™ intervened. On 2012-Aug-27 07:45:41 -0400, "Dustin J. Mitchell" wrote: >On Mon, Aug 27, 2012 at 5:49 AM, Peter Jeremy wrote: >> On 2012-Aug-26 08:12:51 -0400, "Dustin J. Mitchell" >> wrote: >>>On Sat, Aug 25, 2012 at 7:04 PM, Dustin J. Mitchell >>>wrote: >>>> Hey folks. I'm trying to set up a system with one 802.1q-tagged >>>> upstream, and a few untagged interfaces. So I'd like to bridge the >>>> vlan(4) interfaces on vr1 to specific other interfaces. ... >bridge10: flags=8843 metric 0 mtu 1500 >ether 02:f4:a1:63:5a:0a >nd6 options=21 >id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15 >maxage 20 holdcnt 6 proto rstp maxaddr 100 timeout 1200 >root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0 >member: vr3 flags=143 >ifmaxaddr 0 port 4 priority 128 path cost 55 >member: vr2 flags=143 >ifmaxaddr 0 port 3 priority 128 path cost 55 >member: vr1.10 flags=143 >ifmaxaddr 0 port 9 priority 128 path cost 20 >bridge20: flags=8843 metric 0 mtu 1500 >ether 02:f4:a1:63:5a:14 >nd6 options=21 >id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15 >maxage 20 holdcnt 6 proto rstp maxaddr 100 timeout 1200 >root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0 >member: vr0 flags=143 >ifmaxaddr 0 port 1 priority 128 path cost 55 >member: vr1.20 flags=143 >ifmaxaddr 0 port 10 priority 128 path cost 20 That looks like RSTP is enabled on both bridge10 and bridge20 but is not seeing incoming [R]STP packets. Are you sure the switch connected to vr1 is configured with per-VLAN STP (this is probably not the switch default). Have you tried running tcpdump on vr1 and checked that you are seeing STP packets within the VLANs. >gateway_enable="YES" >firewall_enable="YES" >firewall_type="OPEN" gateway_enable="YES" will let the system route packets between bridge10 and bridge20 but shouldn't have any effect on bridging packets between (eg) vr1.10, vr2 & vr3. -- Peter Jeremy pgpDlRhZ6DTnz.pgp Description: PGP signature
Re: Bad routing performance on 500Mhz Geode LX with CURRENT, ipfw and mpd5 (was: ipfw, "ip|all" proto and PPPoE -- does PPPoE packets passed to ipfw?)
On 2012-Aug-31 00:17:11 +0400, Lev Serebryakov wrote: > Is it possible to use gprof with kernel? As here is no userland >processes involved: PPPoE is porcessed by netgrpah, routing & ipfw is >kernel stuff too... Since no-one else has mentioned it, see the '-p' option to config(8) and kgmon(8). There's also dtrace. -- Peter Jeremy pgp4Ejrvxyflt.pgp Description: PGP signature
Re: lagg failover issue
Adrian, On 2012-Aug-31 04:29:53 -0700, Adrian Chadd wrote: >You can't override set the outbound MAC address of a wireless station. >It associates with the MAC address of the card/vap/device. The AP >_will_ store that MAC address in its node table. Are you saying I can't portably do the following: # ifconfig ath0 ether 00:11:22:33:44:55 # ifconfig create wlan0 wlandev ath0 ssid my_net up My understanding was that the first line changes the MAC associated with ath0. The second line then creates a wlan device and allows ath0 to associate with an AP with ssid "my_net" - and this association will be performed using the updated MAC address. Which part of this doesn't work? >What you really want is for the same IP to exist but only both >interfaces and have the source interface/MAC seamlessly change. Actually, lagg(4) requires all associated interfaces to have the same MAC address - it doesn't change them during operation. Normally, it updates the MAC address when it does the "addm" but this doesn't work for "addm wlan0" (presumably for the reasons you describe) but manually changing the MAC address of the WiFi NIC before creating the wlan device avoids this. -- Peter Jeremy pgpSyXX5VtidH.pgp Description: PGP signature
Re: auto tuning tcp
On Mon, Nov 12, 2012 at 10:11 PM, Alfred Perlstein wrote: > On 11/12/12 10:04 PM, Alfred Perlstein wrote: >> >> On 11/12/12 10:48 AM, Alfred Perlstein wrote: >>> >>> On 11/12/12 10:01 AM, Andre Oppermann wrote: >>>> >>>> >>>> I've already added the tunable "kern.maxmbufmem" which is in pages. >>>> That's probably not very convenient to work with. I can change it >>>> to a percentage of phymem/kva. Would that make you happy? >>>> >>> >>> It really makes sense to have the hash table be some relation to sockets >>> rather than buffers. >>> >>> If you are hashing "foo-objects" you want the hash to be some relation to >>> the max amount of "foo-objects" you'll see, not backwards derived from the >>> number of "bar-objects" that "foo-objects" contain, right? >>> >>> Because we are hashing the sockets, right? not clusters. >>> >>> Maybe I'm wrong? I'm open to ideas. >> >> >> Hey Andre, the following patch is what I was thinking >> (uncompiled/untested), it basically rounds up the maxsockets to a power of 2 >> and replaces the default 512 tcb hashsize. >> >> It might make sense to make the auto-tuning default to a minimum of 512. >> >> There are a number of other hashes with static sizes that could make use >> of this logic provided it's not upside-down. >> >> Any thoughts on this? >> >> Tune the tcp pcb hash based on maxsockets. >> Be more forgiving of poorly chosen tunables by finding a closer power >> of two rather than clamping down to 512. >> Index: tcp_subr.c >> === > > > Sorry, GUI mangled the patch... attaching a plain text version. > > Wait, you want to replace a hash with a flat array? Why even bother to call it a hash at that point? -- Peter Wemm - pe...@wemm.org; pe...@freebsd.org; pe...@yahoo-inc.com; KI6FJV "All of this is for nothing if we don't go to the stars" - JMS/B5 "If Java had true garbage collection, most programs would delete themselves upon execution." -- Robert Sewell ___ 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: To SMP or not to SMP
On 2013-Jan-07 18:25:58 -0800, Barney Cordoba wrote: >I have a situation where I have to run 9.1 on an old single core >box. Does anyone have a handle on whether it's better to build a non >SMP kernel or to just use a standard SMP build with just the one >core? Another input for this decision is kern/173322. Currently on x86, atomic operations within kernel modules are implemented using calls to code in the kernel, which do or don't use lock prefixes depending on whethur the kernel was built as SMP. My proposed change changes kernel modules to inline atomic operations but always include lock prefixes (effectively reverting r4). I'm appreciate anyone who feels like testing the impact of this change. -- Peter Jeremy pgpA2uS_hItrK.pgp Description: PGP signature
Re: [JNPR] Proposal for changes to network device drivers and network stack (RFC)
On 2013-Jan-17 14:38:06 -0500, "Stephen J. Kiernan" wrote: >The patch also includes moving zlib.[ch] and zlibutil.h out of net and >into sys/libkern (for the .c) and sys/sys (for the .h). Good. >It really doesn't make much sense for that code to live in net, >especially when so many things which are not the network stack utilize >it. One thing that currently doesn't is ZFS - which has its own copy. It would be nice if ZFS could use the common copy. >Is that going to be a problem? Should simple stubs be added in the >original locations in net/ to include the one in sys/ now? IMHO, no. zlib wasn't an advertised API so nothing outside the base OS should be using it. If you've moved all the kernel code to use the new location, that should be enough. -- Peter Jeremy pgpPlJ_hyRXBS.pgp Description: PGP signature
Request for Price Quote & Credit Application
Dear Sales Dept, We are currently looking for quote and availability on the listed items below to be used for our internal needs. Safway Services, LLC would like to establish an account for Net 30 Terms with your company. 1. InFocus Systems IN5122 Lumen Projector XGA Resolution - WXGA 2. Seagate ST31000524AS Barracuda Hard Drive - 1TB, SATA 6Gbps, 7200 RPM, 32MB 3. Hewlett-Packard 22 O.E.M Tri-colour Inkjet Print Cartridge (C9352AN) Thank you and have a great day! -- Peter Nutall Purchasing Manager Safway Services, LLC N19 W24200 Riverwood Dr. Waukesha, WI 53188 T: 262.347.3723 Ext 2 F: 262.468.3027 DISCLAIMER: This e-mail is intended for the use of the addressee(s) only and may contain privileged, confidential, or proprietary information that is exempt from disclosure under law. If you are not the intended recipient, please do not read, copy, use or disclose the contents of this communication to others. Please notify the sender that you have received this e-mail in error by replying to the e-mail. Please then delete the e-mail and destroy any copies of it. Thank you. ___ 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"
bge wedging 8.2-RC1
Hello I've got a new Dell Precision workstation here with a BCM5761 on intel mobo for westmere xeons that is wedging with interrupt storm and will lockup the system randomly. I have turned HTT and auto powermanagement off in bios (system cannot sleep), lowest cpu acpi state is C1. Here is dmesg: bge0: mem 0xf3be-0xf3be,0xf3bf-0xf3bf irq 17 at device 0.0 on pci6 bge0: CHIP ID 0x05761100; ASIC REV 0x5761; CHIP REV 0x57611; PCI-E miibus0: on bge0 brgphy0: PHY 1 on miibus0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow Here is pciconf -lv: bge0@pci0:6:0:0:class=0x02 card=0x026d1028 chip=0x168114e4 rev=0x10 hdr=0x00 vendor = 'Broadcom Corporation' device = 'Broadcom 57XX Gigabit Integrated Controller (BCM5761)' class = network subclass = ethernet here is the setup in rc.conf: ifconfig_bge0="polling -tso -vlanhwtso -vlanhwtag -vlanmtu inet 192.168.123.124 netmask 255.255.255.0" I have the card plugged into a dlink DSS8 100mbps switch with one other 100mbps device on it (rich man's crossover cable). Before turning off TSO4 and VLAN tagging (because I don't use them), the card would do several things: 1. 1 out of 3 reboots: Fail to bring interface up. ifconfig would hang and systat/vmstat showed 800+ interrupts per second on IRQ256 2. After a few hours lock up the system, requiring hard reboot After disabling TSO4 and VLAN stuff: bge0: flags=8802 metric 0 mtu 1500 options=80083 media: Ethernet autoselect (100baseTX ) Everything seemed fine for about two weeks and then suddenly started acting up again, locked up, after hard reboot, soft reboot, link will not come up and I see interrupt storm again I am close to buying an intel card to replace the bcm, but then I noticed that the main intel desktop PCI-E card is 82574L-based and people are having em driver wedging on that too. So now I have broken ethernet on this box; my primary link is atheros 5212 pci card and I may be out of pci slots (or else I might try a pci intel card). ___ 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: bge wedging 8.2-RC1
On Feb 7, 2011 7:38 PM, "Pyun YongHyeon" wrote: > > On Mon, Feb 07, 2011 at 06:09:16PM -0600, Peter Lai wrote: > > Hello > > > > I've got a new Dell Precision workstation here with a BCM5761 on intel > > mobo for westmere xeons that is wedging with interrupt storm and will > > lockup the system randomly. I have turned HTT and auto powermanagement > > off in bios (system cannot sleep), lowest cpu acpi state is C1. > > > > Here is dmesg: > > bge0: > 0x5761100> mem 0xf3be-0xf3be,0xf3bf-0xf3bf irq 17 at > > device 0.0 on pci6 > > bge0: CHIP ID 0x05761100; ASIC REV 0x5761; CHIP REV 0x57611; PCI-E > > miibus0: on bge0 > > brgphy0: PHY 1 on miibus0 > > brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, > > 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow > > > > Here is pciconf -lv: > > bge0@pci0:6:0:0: class=0x02 card=0x026d1028 chip=0x168114e4 > > rev=0x10 hdr=0x00 > > vendor = 'Broadcom Corporation' > > device = 'Broadcom 57XX Gigabit Integrated Controller (BCM5761)' > > class = network > > subclass = ethernet > > > > here is the setup in rc.conf: > > > > ifconfig_bge0="polling -tso -vlanhwtso -vlanhwtag -vlanmtu inet > > 192.168.123.124 netmask 255.255.255.0" > > > > I have the card plugged into a dlink DSS8 100mbps switch with one > > other 100mbps device on it (rich man's crossover cable). > > > > Before turning off TSO4 and VLAN tagging (because I don't use them), > > the card would do several things: > > 1. 1 out of 3 reboots: Fail to bring interface up. ifconfig would hang > > and systat/vmstat showed 800+ interrupts per second on IRQ256 > > This is strange. bge(4) does not use MSI if you build bge(4) with > DEVICE_POLLING so seeing IRQ256 interrupts looks odd to me. > Are you sure bge(4) is using IRQ256? This is with GENERIC. I will rebuild with POLLING and try... > > > 2. After a few hours lock up the system, requiring hard reboot > > > > After disabling TSO4 and VLAN stuff: > > bge0: flags=8802 metric 0 mtu 1500 > > options=80083 > > media: Ethernet autoselect (100baseTX > > ) > > > > Everything seemed fine for about two weeks and then suddenly started > > acting up again, locked up, after hard reboot, soft reboot, link will > > not come up and I see interrupt storm again > > > > If you don't use DEVICE_POLLING, rebuild bge(4) with > DEVICE_POLLING. For most cases, you don't need to enable polling on > intelligent controllers like bge(4). > > I also have BCM5761 PCIe controller which shows no such issues. I > know there is an edge case(send BD corruption) for BCM5761/BCM5784/ > BCM57780 which needs to be investigated. I'm not sure you're seeing > that edge case though. > > > I am close to buying an intel card to replace the bcm, but then I > > noticed that the main intel desktop PCI-E card is 82574L-based and > > people are having em driver wedging on that too. So now I have broken > > ethernet on this box; my primary link is atheros 5212 pci card and I > > may be out of pci slots (or else I might try a pci intel card). ___ 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: bge wedging 8.2-RC1
> > Let me know attached patch makes any difference on your box. > The patch contains some other changes but that wouldn't affect your > BCM5761 controller. If you see "CLKREQ enabled" message after > applying the patch also let me know that too. > Can I apply this to 8.2-RC1 or should I update it to -RC3? ___ 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: Reliable PCI wifi cards, and layer 7 filtering
2011/2/10 Jeremy Chadwick [skip...] > I plan on using pf for the NAT and firewall layer. ipfw will not be > used (I have long since moved away from it). I've got solutions for > everything except two items: > > 1) Wireless hardware support > - What consumer PCI cards are known to be reliable and have good > support on FreeBSD? > [skip..] I' suggest to use PCI-mPCI adaptor and Wistron Neweb Atheros based cards. It is good for an AP. Use together with FreeBSD 8.1 or later. 2) Layer 7 filtering > > [skip...] I suppose you can use pf+squid as transparent filtering proxy ? I believe not much changed since that post: http://lists.freebsd.org/pipermail/freebsd-pf/2005-August/001450.html Item #2 above seems to be the kicker. Is there anything in the works > regarding such a capability? I'd be more than happy to test out code or > whatever. > > //batcilla ___ 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] Dummynet/IPFW related recurring crash.
On 2011-Feb-20 01:39:00 +0100, Pawel Tyll wrote: >Since nobody came up with any interest in having this properly >investigated, then I suppose I'm the only one that uses dummynet for >some larger-scale traffic shaping - maybe that's my mistake? I'm using dummpnet+pf (not ipfw) on (roughly) FreeBSD 7.2 quite extensively for traffic shaping. I have about 20 pipes varying from 600kbps to 100Mbps all with ~9msec delay. There's a background load of at least 10Mbps with peaks to several times that (and several 2Mbps pipes are virtually permanently saturated). The system has nearly 80 VLANs and uses CARP and lagg/LACP (1 bge and 1 em NIC) for redundancy. The system has an uptime of several months. I haven't responded before because I can't offer any solutions. All I can say is that I've been successfully using dummynet with ipfw or pf for about a decade without any stability issues. -- Peter Jeremy pgpPOChNt5SGB.pgp Description: PGP signature
Re: question about freebsd sctp sctp_asconf_iterator_stcb function.
Hi,
No, the original code looks correct. The address management code needs
to run regardless of whether SCTP_PCB_FLAGS_DO_ASCONF is enabled (or
whether the peer supports ASCONF or not). The newly added address is
put onto the restricted list to prevent the stack from using the new
address as a source address for any existing associations. Similarly,
any addresses that have been locally removed should no longer be used.
The endpoint's SCTP_PCB_FLAGS_DO_ASCONF flag and the association's
peer_supports_asconf flag are then checked to determine whether to
send an ASCONF(ADD/DELETE) chunk to the peers. If an ASCONF is sent
for an address addition, upon getting an ASCONF-ACK indicating success,
the address will be moved off the restricted list and onto the local
address list as a usable as a source address.
If ASCONF is disabled or the peer doesn't support ASCONF, or the peer
rejects the addition, then that address would stay on the restricted
list, and not be used by the local stack as a possible source address.
Hope that clarifies...
--peter
On 2/23/11 8:09 PM, 黄登辉 wrote:
> Hi
>
> I have a little about the following code section of
> sctp_asconf_iterator_stcb function.
>
> if (type == SCTP_ADD_IP_ADDRESS) {
> /* prevent this address from being used as a source */
> sctp_add_local_addr_restricted(stcb, ifa);
> } else if (type == SCTP_DEL_IP_ADDRESS) {
> struct sctp_nets *net;
>
> TAILQ_FOREACH(net, &stcb->asoc.nets, sctp_next) {
> sctp_rtentry_t *rt;
>
> /* delete this address if cached */
> if (net->ro._s_addr == ifa) {
> sctp_free_ifa(net->ro._s_addr);
> net->ro._s_addr = NULL;
> net->src_addr_selected = 0;
> rt = net->ro.ro_rt;
> if (rt) {
> RTFREE(rt);
> net->ro.ro_rt = NULL;
> }
> /*
> * Now we deleted our src address,
> * should we not also now reset the
> * cwnd/rto to start as if its a new
> * address?
> */
> stcb->asoc.cc_functions.sctp_set_initial_cc_param(stcb,
> net);
> net->RTO = 0;
>
> }
> }
> } else if (type == SCTP_SET_PRIM_ADDR) {
> if ((stcb->sctp_ep->sctp_flags & SCTP_PCB_FLAGS_BOUNDALL) == 0)
> {
> /* must validate the ifa is in the ep */
> if (sctp_is_addr_in_ep(stcb->sctp_ep, ifa) == 0) {
> continue;
> }
> } else {
> /* Need to check scopes for this guy */
> if (sctp_is_address_in_scope(ifa,
> stcb->asoc.ipv4_addr_legal,
> stcb->asoc.ipv6_addr_legal,
> stcb->asoc.loopback_scope,
> stcb->asoc.ipv4_local_scope,
> stcb->asoc.local_scope,
> stcb->asoc.site_scope, 0) == 0) {
> continue;
> }
> }
> }
> /* queue an asconf for this address add/delete */
> if (sctp_is_feature_on(inp, SCTP_PCB_FLAGS_DO_ASCONF) &&
> stcb->asoc.peer_supports_asconf) {
> /* queue an asconf for this addr */
> status = sctp_asconf_queue_add(stcb, ifa, type);
> /*
> * if queued ok, and in the open state, update the
> * count of queued params. If in the non-open
> * state, these get sent when the assoc goes open.
> */
> if (SCTP_GET_STATE(&stcb->asoc) == SCTP_STATE_OPEN) {
> if (status >= 0) {
> num_queued++;
> }
> }
> }
>
>
> should change like this:
>
> if (sctp_is_feature_on(inp, SCTP_PCB_FLAGS_DO_ASCONF) &&
> stcb->asoc.peer_supports_asconf) {
> if (type == SCTP_ADD_IP_ADDRESS) {
> /* prevent this address from being used as a source */
> sctp_add_local_addr_restricted(stcb, ifa);
> } else if (type == SCTP_DEL_IP_ADDRESS) {
> struct sctp_nets *net;
>
> TAILQ_FOREACH(net, &stcb->asoc.nets, sctp_next) {
> sctp_rtentry_t *rt;
>
> /* delete this address if cached */
>
Diskless booting issues
For various reasons, I occasionally boot my netbook as a diskless client of my main server (this is a quick/easy way to test upgrades without needing to install them). Since I still like to use it as a netbook in this mode (ie, wander around the house), I've run into a couple of issues that I haven't been able to resolve myself and would like some assistance with. I'm running FreeBSD-8.2 i386 from the beginning of March on an original Acer Aspire One. First problem: If it loses network connectivity (ie, I unplug the network cable) for more than a minute or so, it seems to lockup and need a hard reboot, even if the network is restored. I'm a bit vague on this because it's been running X on the occasions I've seen this and I just get a blank screen with no responsiveness from the keyboard and it isn't pingable, though the ethernet link light is on. Second problem: When running on the local SSD, I have lagg setup so it seamlessly switches between wired and wifi (this is really nice). Partially to resolve the above and partially to improve portability, I'd like to do the same when running diskless but can't work out how to make it work. The relevant bits of my native rc.conf look like: ifconfig_re0="up" ifconfig_ath0="ether XX:XX:XX:XX:XX:XX" wlans_ath0="wlan0" ifconfig_wlan0="WPA" cloned_interfaces="lagg0" ifconfig_lagg0="SYNCDHCP laggproto failover laggport re0 laggport wlan0" Gluing this in the diskless rc.conf gives me a hang during startup, as does changing 'SYNCDHCP' to 'inet MYHOST' and adding 'up'. Adding a 'set -x' to the startup shows that it executes: ifconfig lagg0 inet MYHOST laggproto failover laggport re0 laggport wlan0 up ifconfig lagg0 up and hangs at this point (though the kernel reports lagg0 up). ^T shows it in "connect" state. I've tried working through the commands manually and basically, any "disk" access after the first ifconfig above will hang. In diskless mode, re0 is "up" with the correct IP address when init(8) starts and I presume the kernel is getting upset at the IP address migrating from re0 to lagg0. I have considered trying to use lagg0 (made up only of re0) as the boot device but I can't work out how to achieve this (in particular, how to "up" re0 when that's not part of the diskless boot sequence). Does anyone have any suggestions? -- Peter Jeremy pgpssVxm4ejLN.pgp Description: PGP signature
Re: Diskless booting issues
I've managed to resolve one of the problems I raised.
On 2011-Apr-11 07:10:12 +1000, Peter Jeremy wrote:
>For various reasons, I occasionally boot my netbook as a diskless
>client of my main server (this is a quick/easy way to test upgrades
>without needing to install them).
Since I got a query about this, this is "diskless" in the old Sun
diskless workstation sense - the filesystem is mounted RW so the
netbook behaves normally except that the filesystem is remote rather
than the local SSD. This is different to the approach assumed by
/etc/rc.initdiskless where the remote filesystem is RO with some
magic directory trees that are copied to a local RW ramdisk.
>First problem: If it loses network connectivity (ie, I unplug the
>network cable) for more than a minute or so, it seems to lockup and
>need a hard reboot, even if the network is restored.
I haven't gotten anywhere with this.
>Second problem: When running on the local SSD, I have lagg setup so
>it seamlessly switches between wired and wifi (this is really nice).
>Partially to resolve the above and partially to improve portability,
>I'd like to do the same when running diskless but can't work out how
>to make it work.
>
>The relevant bits of my native rc.conf look like:
> ifconfig_re0="up"
> ifconfig_ath0="ether XX:XX:XX:XX:XX:XX"
> wlans_ath0="wlan0"
> ifconfig_wlan0="WPA"
> cloned_interfaces="lagg0"
> ifconfig_lagg0="SYNCDHCP laggproto failover laggport re0 laggport wlan0"
>
>Gluing this in the diskless rc.conf gives me a hang during startup, as
>does changing 'SYNCDHCP' to 'inet MYHOST' and adding 'up'.
Turns out that
> ifconfig lagg0 inet MYHOST laggproto failover laggport re0 laggport wlan0 up
results in MYHOST existing on both re0 and lagg0 and this causes the
network to completely stop - even if you later remove one of the IP
addresses. You need to remove the IP address from re0 before adding
it to lagg0. This presents a bit of a catch-22 since once I remove the
IP address from re0, I no longer have access to a filesystem to run
an ifconfig to add the IP adddress to lagg0.
My solution was to use a temporary ramdisk to hold a statically-linked
copy of ifconfig in a new rc.d script (see attached) to handle moving
the IP address from re0 to lagg0 and then let the existing netif handle
the wifi side with te following rc.conf entries (cf above):
ifconfig_ath0="ether XX:XX:XX:XX:XX:XX"
wlans_ath0="wlan0"
ifconfig_wlan0="WPA"
ifconfig_lagg0="laggport wlan0"
--
Peter Jeremy
#!/bin/sh
#
# Create lagg0 if necessary and flip current IP address from re0 to lagg0
# PROVIDE: lagg
# REQUIRE: FILESYSTEMS
# BEFORE: netif
# KEYWORD: nojail
. /etc/rc.subr
. /etc/network.subr
name="lagg"
start_cmd="lagg_start"
stop_cmd=":"
cmdifn=
: ${lagg_phys:=re0}
: ${lagg_dev:=lagg0}
: ${lagg_tmp:=/mnt}
lagg_start()
{
# Ensure that the lagg device exists
ifexists "$lagg_dev" || ifconfig "$lagg_dev" create
# Create a ramdisk to temporarily hold a copy of ifconfig
md_dev=$(/sbin/mdconfig -a -t swap -s 8m)
mdmfs -S -s 8m -o async $md_dev "$lagg_tmp"
# Copy /rescue (because it's statically linked)
tar -cf - -C /rescue . | tar -xf - -C "$lagg_tmp"
### Actually flip the interface
# Wanted IP address
addr=$(/mnt/ifconfig "$lagg_phys" | grep 'inet ')
# Delete address from existing interface
/mnt/ifconfig "$lagg_phys" delete
# Setup new interface
/mnt/ifconfig "$lagg_dev" $addr laggport "$lagg_phys" up
# Unwind ramdisk
umount /mnt
mdconfig -d -u ${md_dev#md}
}
load_rc_config $name
run_rc_command "$@"
pgpOJsz3z6W6w.pgp
Description: PGP signature
Statistics collection broken in "new" dummynet
I have been using dummynet(4) to do traffic shaping for simulated WANs for over a decade now and it has been very effective - thanks Luigi. I am currently looking at migrating the network simulator from 7.1 to 8.2 and have noticed that the statistics reported are now meaningless. Instead of reporting cumulative statistics, it now appears to reset them regularly - apparently whenever the pipe is empty. Sample results from 7.1 (currently inactive): 00224: 2.000 Mbit/s9 ms 64 KB 1 queues (1 buckets) droptail mask: 0x00 0x/0x -> 0x/0x BKT Prot ___Source IP/port Dest. IP/port Tot_pkt/bytes Pkt/Byte Drp 0 udp 192.168.224.183/0 192.168.216.179/0 5404902 598099622 00 0 Sample results from 8.2 (currently active simulator): 00224: 2.000 Mbit/s 18 ms burst 0 q131296 64 KB 0 flows (1 buckets) sched 65760 weight 0 lmax 0 pri 0 droptail sched 65760 type FIFO flags 0x0 0 buckets 1 active 0 ip 0.0.0.0/0 0.0.0.0/02 1785 00 0 (and most of the time, the last line doesn't appear). I have checked a recent 9.0-BETA1 and it is still broken. Looking at the dummynet.txt file, I cannot see this mentioned. I have looked through the source and it does appear that scheduler instances are marked inactive in serve_sched() once they have no packets queued and are then garbage-collected via drain_scheduler_cb(). Is this the intent? If so, how can statistics be collected? -- Peter Jeremy pgpzud9JhB4U3.pgp Description: PGP signature
Re: Statistics collection broken in "new" dummynet
On 2011-Aug-23 04:20:43 +0200, Luigi Rizzo wrote: >Deleting entries saves memory and speeds up lookups in the data >structures, but is extremely annoying if you want to collect per-flow >statistics. Which I do. >If i remember well there is a knob to enable/disable removal of >useless pipes/queues but i am not sure if there is a sysctl or >timer or other mechanism to control it. Thanks - that was enough of a pointer to find net.inet.ip.dummynet.expire -- Peter Jeremy pgpyI8uFcdMZc.pgp Description: PGP signature
Re: Patch to enable our tcpdump to handle CARP
On 2011-Oct-19 16:20:27 -0400, George Neville-Neil wrote: >I've been trying to debug CARP problems of late. I noticed that our >tcpdump didn't have CARP support. bin/124825 includes patches to cover both pfsync & CARP. I have patched 8.x but can't recall if the patches still apply to 9.x/10.x. -- Peter Jeremy pgp9nu4ltpF4S.pgp Description: PGP signature
Re: Re[2]: Call for testers: ng_netflow with v9 and IPv6 support
On 2009-Sep-07 11:54:55 +0400, Dennis Yusupoff wrote: >By the way, what's about this one: >--- > The ng_netflow node type does not fill in AS numbers. This is due to the ... >--- > >Is any chance to see it in, for example, 8.0? New feature cutoff for 8.0 was several months ago. Once the code exists, it may be a candidate for inclusion in a future 8.x release. -- Peter Jeremy pgp97m7g6QHHU.pgp Description: PGP signature
New tcpdump in 8.x
[Please excuse long lines] Who has used tcpdump on FreeBSD 8.x and likes it? Is it just me or is it now far harder to investigate network problems using it? Prior to 8.x, the default output includes SEQ number ranges for any TCP packets with data, so a 'tcpdump -n' looks like the following and it's immediately obvious that there's 2920 bytes of data missing: 08:48:32.137596 IP 134.159.99.234.60834 > 122.106.250.30.2202: . 221537:222997(1460) ack 2609 win 65535 08:48:32.138492 IP 134.159.99.234.60834 > 122.106.250.30.2202: . 222997:224457(1460) ack 2609 win 65535 08:48:32.139601 IP 122.106.250.30.2202 > 134.159.99.234.60834: . ack 224457 win 64240 08:48:32.145623 IP 134.159.99.234.60834 > 122.106.250.30.2202: . 227377:228837(1460) ack 2609 win 65535 08:48:32.146703 IP 122.106.250.30.2202 > 134.159.99.234.60834: . ack 224457 win 65535 The same output on 8.x looks like the following. Whilst the last ACK packet looks anomolous, there's no useful information to analyse further. 08:48:32.137596 IP 134.159.99.234.60834 > 122.106.250.30.2202: Flags [.], ack 2609, win 65535, length 1460 08:48:32.138492 IP 134.159.99.234.60834 > 122.106.250.30.2202: Flags [.], ack 2609, win 65535, length 1460 08:48:32.139601 IP 122.106.250.30.2202 > 134.159.99.234.60834: Flags [.], ack 224457, win 64240, length 0 08:48:32.145623 IP 134.159.99.234.60834 > 122.106.250.30.2202: Flags [.], ack 2609, win 65535, length 1460 08:48:32.146703 IP 122.106.250.30.2202 > 134.159.99.234.60834: Flags [.], ack 224457, win 65535, length 0 In order to see the SEQ numbers (which are essential to make sense of the capture), you need to add '-vv' - which turns the output into: 08:48:32.137596 IP (tos 0x0, ttl 52, id 32485, offset 0, flags [DF], proto TCP (6), length 1500) 134.159.99.234.60834 > 122.106.250.30.2202: Flags [.], seq 221537:222997, ack 2609, win 65535, length 1460 08:48:32.138492 IP (tos 0x0, ttl 52, id 32486, offset 0, flags [DF], proto TCP (6), length 1500) 134.159.99.234.60834 > 122.106.250.30.2202: Flags [.], seq 222997:224457, ack 2609, win 65535, length 1460 08:48:32.139601 IP (tos 0x8, ttl 63, id 46554, offset 0, flags [DF], proto TCP (6), length 40) 122.106.250.30.2202 > 134.159.99.234.60834: Flags [.], cksum 0xe759 (correct), seq 2609, ack 224457, win 64240, length 0 08:48:32.145623 IP (tos 0x0, ttl 52, id 32489, offset 0, flags [DF], proto TCP (6), length 1500) 134.159.99.234.60834 > 122.106.250.30.2202: Flags [.], seq 227377:228837, ack 2609, win 65535, length 1460 08:48:32.146703 IP (tos 0x8, ttl 63, id 46555, offset 0, flags [DF], proto TCP (6), length 40) 122.106.250.30.2202 > 134.159.99.234.60834: Flags [.], cksum 0xe24a (correct), seq 2609, ack 224457, win 65535, length 0 Whilst it's now possible to work out that there's 2920 bytes of data missing, this information is mixed up in so much other extraneous information that the dump is almost useless. In particular, it's no longer possible to scan a tcpdump output and easily see packet loss or out-of-order delivery. -- Peter Jeremy pgpnKFDXzBzl1.pgp Description: PGP signature
Can lagg0 failback be prevented?
We're using the lag driver to provide automatic failover in case of a network outage. The default configuration looks like this: lagg0: flags=8843 metric 0 mtu 1500 options=19b ether 00:a0:d1:e3:58:26 inet 192.168.17.40 netmask 0xf000 broadcast 192.168.31.255 inet 192.168.22.11 netmask 0xff00 broadcast 192.168.22.255 media: Ethernet autoselect status: active laggproto failover laggport: nfe1 flags=0<> laggport: nfe0 flags=5 If nfe0 was to fail, we get an (almost) automatic failover to nfe1: lagg0: flags=8843 metric 0 mtu 1500 options=19b ether 00:a0:d1:e3:58:26 inet 192.168.17.40 netmask 0xf000 broadcast 192.168.31.255 inet 192.168.22.11 netmask 0xff00 broadcast 192.168.22.255 media: Ethernet autoselect status: active laggproto failover laggport: nfe1 flags=4 laggport: nfe0 flags=1 The problem we're having is when nfe0 comes online again, a failback occurs making nfe0 active again. This causes a momentary network outage that we want to prevent. Is there a way to configure the lagg device to stay with the currently active interface, even if the MASTER interface comes back online? ___ 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: dummynet dropping too many packets
On 2009-Oct-04 18:47:23 +0500, rihad wrote: >Hi, we have around 500-600 mbit/s traffic flowing through a 7.1R Dell >PowerEdge w/ 2 GigE bce cards. There are currently around 4 thousand ISP >users online limited by dummynet pipes of various speeds. According to >netstat -s output around 500-1000 packets are being dropped every second >(this accounts for wasting around 7-12 mbit/s worth of traffic according >to systat -ifstat): This has been a most interesting thread. A couple of comments: Traffic shaping only works cleanly on TCP flows - UDP has no feedback mechanism and so will not automatically throttle to fit into the available bandwidth, potentially leading to high packet drops within dummynet. Is it possible that some of your customers are heavily using UDP? Have you tried allowing just UDP traffic to bypass the pipes to see if this has any effect on drop rate? The pipe lists you posted showed that virtually all the packet drops are associated with one or two IP addresses. If this is really true, rather than a measurement artifact, you might find it useful to tcpdump those addresses and see if there's anything unusual in the data being passed. Also, if you monitor the pipe lists following a cold start, do those addresses appear early and just not show any packet loss until the total number of users builds up or do they not appear until later and immediately show packet loss? Looking at how 'output packets dropped due to no bufs, etc.' is counted (ipstat.ips_odropped), if you run 'netstat -id', do you see a large number of drops on bce1 (consistent with the "output packets dropped" counts) or not? This will help narrow down the codepath being followed by dropped packets. Since the problem only appears to manifest when table(0) exceeds 2000 entries, have you considered splitting (at least temporarily) that table (and possibly table(2)) into two (eg table(0) and table(4))? This would help rule out an (unlikely) problem with table sizes. Doin so would require the application to split the users across both tables (eg round-robin or based on one of the bits in the IP address) and then duplicating the relevant ipfw rules - eg: 01060 pipe tablearg ip from any to table(0) out recv bce0 xmit bce1 01061 pipe tablearg ip from any to table(4) out recv bce0 xmit bce1 01070 allow ip from any to table(0) out recv bce0 xmit bce1 01071 allow ip from any to table(4) out recv bce0 xmit bce1 (And I agree that re-arranging rules to reduce the number of repeated tests should improve ipfw efficiency). The symptoms keep making me think "lock contention" - but I'm not sure how to measure that cheaply (AFAIK, LOCK_PROFILING is comparatively expensive). Finally, are you running i386 or amd64? -- Peter Jeremy pgpGJqTOzuPXQ.pgp Description: PGP signature
What's the proper way to traverse a getifaddrs() interface list?
I have an application where I want to collect information on the network
interfaces. I've researched this and the function getifaddrs(struct ifaddrs
*ifap) appears to be the way to go, but I'm having some trouble understanding
exactly how to process the information returned by this call. It's basically a
linked list, but there are two entries for each interface. I initially thought
I could just skip one of the entries but that doesn't appear to be the case,
not entirely anyway. What I want to do is write a function that returns a list
of dynamically allocated structures, one for each interface. My structure looks
like this:
typedef struct
{
string *ifcId;
string *ipAddr;
bytearray *hwAddr;
string *subnetMask;
string *bcastAddr;
} net_attributes;
and the function I am implementing has the following prototype:
int getAllNetAttributes(net_attributes **result, int **count)
where count is the number of elements in the net_attributes result array. This
means I need to first count the number of interfaces and allocate my result
array, and then collect the information for each interface. This means two
traversals of the linked list, once just to count the entries (the length of
the list divided by 2) and then traversing it again to collect the data. I've
got this mostly working but I'm having trouble with how to deal with the
duplicate entries in the linked list of ifaddrs structures returned by
getifaddrs. I've looked at ifconfig.c and I can't tell exactly what the code is
doing as far as how it handles these duplicate entries. Can someone explain the
proper way to traverse this linked list?
___
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"
Reproducible crash w/ IPv6 on FreeBSD 7.1 amd64 under VMware ESXi 3.5
Hello,
My FreeBSD 7.1 guest is crashing when I use IPv6 and ping6 an address
that doesn't respond to ICMP or isn't on the network. Am I the only
person that has run into this issue? I can reproduce it on a fresh
virtual machine, 100% of the time .. Does NOT occur (I've had machines
up for 200+ days) if I am not using IPv6.
HOWTO Reproduce:
1. FreeBSD 7.1 amd64 Guest
2. IPv6 networking enabled and configured
3. ping6 against an IPv6 address that isn't active on your network and
leave it running
4. Virtual machine will crash after a number of minutes (from 1~15 minutes)
What configuration:
* Generic FreeBSD 7.1 kernel (No custom configuration)
* No VMware tools or kernel modules installed
* e1000 virtual Ethernet adapter
* LSI Logic virtual SCSI controller
* kern.hz set at 100 in /boot/loader.conf
Kernel revision:
FreeBSD freebsd71.pfak.org 7.1-RELEASE-p11 FreeBSD 7.1-RELEASE-p11 #0:
Tue May 4 10:28:31 PDT 2010
r...@freebsd71.pfak.org:/usr/obj/usr/src/sys/GENERIC amd64
Kernel dump W/ Backtrace:
Fatal trap 12: page fault while in kernel mode
cpuid = 1; apic id = 01
fault virtual address = 0x18
fault code = supervisor read data, page not present
instruction pointer = 0x8:0x80505a66
stack pointer = 0x10:0xac258a60
frame pointer = 0x10:0x0
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 13 (swi1: net)
trap number = 12
panic: page fault
cpuid = 1
Uptime: 13m54s
Physical memory: 3827 MB
Dumping 323 MB: 308 292 276 260 244 228 212 196 180 164 148 132 116 100
84 68 52 36 20 4
#0 doadump () at pcpu.h:195
195 __asm __volatile("movq %%gs:0,%0" : "=r" (td));
(kgdb) backtrace
#0 doadump () at pcpu.h:195
#1 0x0004 in ?? ()
#2 0x804b4d29 in boot (howto=260) at
/usr/src/sys/kern/kern_shutdown.c:418
#3 0x804b5132 in panic (fmt=0x104 bounds>) at /usr/src/sys/kern/kern_shutdown.c:574
#4 0x8078a1f3 in trap_fatal (frame=0xff00010ff000,
eva=Variable "eva" is not available.
) at /usr/src/sys/amd64/amd64/trap.c:764
#5 0x8078a5c5 in trap_pfault (frame=0xac2589b0,
usermode=0) at /usr/src/sys/amd64/amd64/trap.c:680
#6 0x8078af08 in trap (frame=0xac2589b0) at
/usr/src/sys/amd64/amd64/trap.c:449
#7 0x807706fe in calltrap () at
/usr/src/sys/amd64/amd64/exception.S:209
#8 0x80505a66 in m_copydata (m=0x0, off=0, len=56,
cp=0xff00013b9980 "") at /usr/src/sys/kern/uipc_mbuf.c:813
#9 0x8061277f in ip6_input (m=0xff0001611a00) at
/usr/src/sys/netinet6/ip6_input.c:299
#10 0x8055ae59 in netisr_processqueue (ni=0x80acbb08) at
/usr/src/sys/net/netisr.c:143
#11 0x8055b0eb in swi_net (dummy=Variable "dummy" is not available.
) at /usr/src/sys/net/netisr.c:250
#12 0x804957c0 in ithread_loop (arg=0xff00010fac00) at
/usr/src/sys/kern/kern_intr.c:1088
#13 0x80492663 in fork_exit (callout=0x80495650
, arg=0xff00010fac00, frame=0xac258c80)
at /usr/src/sys/kern/kern_fork.c:804
#14 0x80770ace in fork_trampoline () at
/usr/src/sys/amd64/amd64/exception.S:455
#15 0x in ?? ()
#16 0x in ?? ()
#17 0x0001 in ?? ()
#18 0x in ?? ()
#19 0x in ?? ()
#20 0x in ?? ()
#21 0x in ?? ()
#22 0x in ?? ()
#23 0x in ?? ()
#24 0x in ?? ()
#25 0x in ?? ()
#26 0x in ?? ()
#27 0x in ?? ()
#28 0x in ?? ()
#29 0x in ?? ()
#30 0x in ?? ()
#31 0x in ?? ()
#32 0x in ?? ()
#33 0x in ?? ()
#34 0x in ?? ()
#35 0x in ?? ()
#36 0x in ?? ()
#37 0x in ?? ()
#38 0x in ?? ()
#39 0x00d43000 in ?? ()
#40 0x80ab8440 in tdq_cpu ()
#41 0x in ?? ()
#42 0x80ac3fc0 in tdq_cpu ()
#43 0x in ?? ()
#44 0xff00010ff000 in ?? ()
#45 0xac258628 in ?? ()
#46 0x80ab77c0 in tdg_maxid ()
#47 0x804d5954 in sched_switch (td=0x0, newtd=0x8005c7450,
flags=0) at /usr/src/sys/kern/sched_ule.c:1944
#48 0x in ?? ()
#49 0x in ?? ()
#50 0x in ?? ()
#51 0x in ?? ()
...
Cannot access memory at address 0xac259000
(kgdb)
-Peter
___
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: Reproducible crash w/ IPv6 on FreeBSD 7.1 amd64 under VMware ESXi 3.5
On further note: I belive that 'm' should not be NULL ...
#9 0x8061277f in ip6_input (m=0xff0001611a00) at
/usr/src/sys/netinet6/ip6_input.c:299
-Peter
On 5/4/2010 11:06 AM, Peter Kieser wrote:
Hello,
My FreeBSD 7.1 guest is crashing when I use IPv6 and ping6 an address
that doesn't respond to ICMP or isn't on the network. Am I the only
person that has run into this issue? I can reproduce it on a fresh
virtual machine, 100% of the time .. Does NOT occur (I've had machines
up for 200+ days) if I am not using IPv6.
HOWTO Reproduce:
1. FreeBSD 7.1 amd64 Guest
2. IPv6 networking enabled and configured
3. ping6 against an IPv6 address that isn't active on your network and
leave it running
4. Virtual machine will crash after a number of minutes (from 1~15
minutes)
What configuration:
* Generic FreeBSD 7.1 kernel (No custom configuration)
* No VMware tools or kernel modules installed
* e1000 virtual Ethernet adapter
* LSI Logic virtual SCSI controller
* kern.hz set at 100 in /boot/loader.conf
Kernel revision:
FreeBSD freebsd71.pfak.org 7.1-RELEASE-p11 FreeBSD 7.1-RELEASE-p11 #0:
Tue May 4 10:28:31 PDT 2010
r...@freebsd71.pfak.org:/usr/obj/usr/src/sys/GENERIC amd64
Kernel dump W/ Backtrace:
Fatal trap 12: page fault while in kernel mode
cpuid = 1; apic id = 01
fault virtual address = 0x18
fault code = supervisor read data, page not present
instruction pointer = 0x8:0x80505a66
stack pointer = 0x10:0xac258a60
frame pointer = 0x10:0x0
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 13 (swi1: net)
trap number = 12
panic: page fault
cpuid = 1
Uptime: 13m54s
Physical memory: 3827 MB
Dumping 323 MB: 308 292 276 260 244 228 212 196 180 164 148 132 116
100 84 68 52 36 20 4
#0 doadump () at pcpu.h:195
195 __asm __volatile("movq %%gs:0,%0" : "=r" (td));
(kgdb) backtrace
#0 doadump () at pcpu.h:195
#1 0x0004 in ?? ()
#2 0x804b4d29 in boot (howto=260) at
/usr/src/sys/kern/kern_shutdown.c:418
#3 0x804b5132 in panic (fmt=0x104 bounds>) at /usr/src/sys/kern/kern_shutdown.c:574
#4 0x8078a1f3 in trap_fatal (frame=0xff00010ff000,
eva=Variable "eva" is not available.
) at /usr/src/sys/amd64/amd64/trap.c:764
#5 0x8078a5c5 in trap_pfault (frame=0xac2589b0,
usermode=0) at /usr/src/sys/amd64/amd64/trap.c:680
#6 0x8078af08 in trap (frame=0xac2589b0) at
/usr/src/sys/amd64/amd64/trap.c:449
#7 0x807706fe in calltrap () at
/usr/src/sys/amd64/amd64/exception.S:209
#8 0x80505a66 in m_copydata (m=0x0, off=0, len=56,
cp=0xff00013b9980 "") at /usr/src/sys/kern/uipc_mbuf.c:813
#9 0x8061277f in ip6_input (m=0xff0001611a00) at
/usr/src/sys/netinet6/ip6_input.c:299
#10 0x8055ae59 in netisr_processqueue (ni=0x80acbb08)
at /usr/src/sys/net/netisr.c:143
#11 0x8055b0eb in swi_net (dummy=Variable "dummy" is not
available.
) at /usr/src/sys/net/netisr.c:250
#12 0x804957c0 in ithread_loop (arg=0xff00010fac00) at
/usr/src/sys/kern/kern_intr.c:1088
#13 0x80492663 in fork_exit (callout=0x80495650
, arg=0xff00010fac00, frame=0xac258c80)
at /usr/src/sys/kern/kern_fork.c:804
#14 0x80770ace in fork_trampoline () at
/usr/src/sys/amd64/amd64/exception.S:455
#15 0x in ?? ()
#16 0x in ?? ()
#17 0x0001 in ?? ()
#18 0x in ?? ()
#19 0x in ?? ()
#20 0x in ?? ()
#21 0x in ?? ()
#22 0x in ?? ()
#23 0x in ?? ()
#24 0x in ?? ()
#25 0x in ?? ()
#26 0x in ?? ()
#27 0x in ?? ()
#28 0x in ?? ()
#29 0x in ?? ()
#30 0x in ?? ()
#31 0x in ?? ()
#32 0x in ?? ()
#33 0x in ?? ()
#34 0x in ?? ()
#35 0x in ?? ()
#36 0x in ?? ()
#37 0x in ?? ()
#38 0x in ?? ()
#39 0x00d43000 in ?? ()
#40 0x80ab8440 in tdq_cpu ()
#41 0x in ?? ()
#42 0x80ac3fc0 in tdq_cpu ()
#43 0x in ?? ()
#44 0xff00010ff000 in ?? ()
#45 0xac258628 in ?? ()
#46 0x80ab77c0 in tdg_maxid ()
#47 0x804d5954 in sched_switch (td=0x0, newtd=0x8005c7450,
flags=0) at /usr/src/sys/kern/sched_ule.c:1944
#48 0x in ?? ()
#49 0x in ?? ()
#50 0x in ?? ()
#51 0x0000 in ?? ()
...
Cannot access memory at address 0xac259000
(kgdb)
-Peter
__
Bringing VLANs created with rc.conf vlans_ 'up' on boot?
Hello, I am experimenting with FreeBSD vlan's using the vlans option in rc.conf, my configuration is as follows: ifconfig_em1="up" vlans_em1="100 101 102 103 104 105 106 107 108 109 110" autobridge_interfaces="bridge0" autobridge_bridge0="em0 em1.*" ifconfig_bridge0="up" rc script create em1.100 - em1.110 but doesn't bring the interfaces up on boot, I have to issue 'ifconfig em1.100 up', etc. to bring them online. I also cannot use 'ifconfig_em1.100="up"' because the rc scripts don't support periods in the variable names. Is there a way to accomplish this? In the mean time, I have had to resort to the following which is very messy (and error prone): ifconfig_em1="up" cloned_interfaces="bridge0 vlan100 vlan101 vlan102 vlan103 vlan104 vlan105 vlan106 vlan107 vlan108 vlan109 vlan110" ifconfig_vlan100="up vlan 100 vlandev em1" ifconfig_vlan101="up vlan 101 vlandev em1" ifconfig_vlan102="up vlan 102 vlandev em1" ifconfig_vlan103="up vlan 103 vlandev em1" ifconfig_vlan104="up vlan 104 vlandev em1" ifconfig_vlan105="up vlan 105 vlandev em1" ifconfig_vlan106="up vlan 106 vlandev em1" ifconfig_vlan107="up vlan 107 vlandev em1" ifconfig_vlan108="up vlan 108 vlandev em1" ifconfig_vlan109="up vlan 109 vlandev em1" ifconfig_vlan110="up vlan 110 vlandev em1" ifconfig_bridge0="up addm em0 addm vlan100 addm vlan101 addm vlan102 addm vlan103 addm vlan104 addm vlan105 addm vlan106 addm vlan107 addm vlan108 addm vlan109 addm vlan110" Any hints? Suggestions? I was trying to avoid using the method listed directly above as it is very messy and error prone. Thanks, -Peter ___ 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: Bringing VLANs created with rc.conf vlans_ 'up' on boot?
On 5/17/2010 11:35 AM, Andrew Thompson wrote: Use an underscore where the period should be, the rc.d scripts support this. ifconfig_em1.100="up" --> ifconfig_em1_100="up" cheers, Andrew Thanks to some offlist postings (from Mykola Dzham and the one above), I came up with the following: ifconfig_DEFAULT="up" vlans_em1="100 101 102 103 104 105 106 107 108 109 110" autobridge_interfaces="bridge0" autobridge_bridge0="em0 em1.*" I wanted to make certain interfaces on the bridge 'sticky', but if I add: ifconfig_bridge0="sticky em1.100 sticky em1.101 sticky em1.102 sticky em1.103 sticky em1.104 sticky em1.105 sticky em1.106 sticky em1.107 sticky em1.108 sticky em1.109 sticky em1.110" Then the autobridge interface isn't created and I'm back to my ugly ifconfig_bridge0 hack. Is there an alternative way to do this? Thank you, -Peter ___ 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: VLANs, routing, multicast and HP switches, oh my...
On 2010-Jun-14 13:17:06 -0700, Kurt Buff wrote: >We'll be simulating installations of our software and hardware for >customer installations that have WANs between sites, with several >complementary applications, including a multicast app that is critical >to the whole effort. While it's a bit much to expect us to be able to >simulate a WAN at this point, I want to be able to simulate at least >two subnets with routed multicast between them. I have been running FreeBSD-based WAN simulators at work for more than a decade. As with you, the driver has been to replicate customer configurations for testing purposes. My current system provides about 60 different subnets (using VLANs) and about 12 simulated WANs. It uses two FreeBSD boxes providing NAT between the corporate intranet and various test LANs, as well as routing and WAN simulation between LANs. Each box runs VLANs over LACP (via lagg(4)) through dual NICs to redundant switches. The boxes provide automatic failover via carp(4). The WAN simulation is done using dummynet(4) and the NAT and CARP via pf(4). By default, pf and dummynet don't work together but Ermal Luçi wrote some patches that I'm using together with some local adaption. Whilst I have run into some rough edges, the system has been very successful overall. >take your point about the packets traveling over the same wire. It >would be best if I could get a multiport router - perhaps a layer3 >switch (I'd love to get them an HP 3400cl) - but that costs much money >that I don't have to spend at the moment. My recommendation is that you just use managed switches that support VLANs and push all the traffic into the FreeBSD box via a trunk, then let the FreeBSD box handle all the routing. -- Peter Jeremy pgpG1zHz1ZhKG.pgp Description: PGP signature
Re: Server network interface problem?
On 2010-Sep-22 14:32:52 -0400, Carlos Kamtha wrote: >To solve this problem, i plugged out the network cable and plugged it back in. >... >a.) Could this be an issue with the driver on this release for em0? Possibly - there have been some issues with em(4) and some chipsets. Alternatively, it could equally well have been a glitch on the associated switchport. >b.) Why was I not able to ssh to the client servers while the NFS server was >down? Logging into a client entails filesystem accesses and if any of those filesystems are NFS mounted then those accesses will block if the NFS server is non-responding. Note that by default, sshd will search /lib, /usr/lib and /usr/local/lib (as well as subordinate compat libraries) to dlopen() nss modules - which means that a local root and /usr could still block if you have a NFS mounted /usr/local. -- Peter Jeremy pgphPQD1bqcxe.pgp Description: PGP signature
UDP checksum invalid on FreeBSD7/x86
Hi there, first of, this is my first posting to this list, hopfully it is the right place, if not please direct me, I was not being thick intentionally. I have a fresh installation of FreeBSD7 on x86, with no big changes to the system. Situation: Two PCs, one running linux and my own programs client application one running freebsd7 and my own programs server application The client and server of my program interchange UDP packets of various sizes. The problem I see is that small packets sent from the FreeBSD PC to the Linux PC are sent with an invalid UDP checksum (verified via tcpdump on the linux box). In my tests all packets with less than 30 bytes UDP payload had an invalid checksum set. All packets with more than 15 bytes had the correct checksum set. So, the "exact" number should be somewhere between 15 and 30 bytes. The receiving Linux box discards the packets with invalid checksums, which of course is problematic for my applications well-being. To "fix" the problem I did: sudo sysctl -w net.inet.udp.checksum=0 This doesn't seem to be a real fix, but more a work-around. If any more information (regarding my installation, my hardware or how my application uses the networking functions) is required, just ask. Thanks in advance for your responses. PS: I also tried with the client application on other operating systems than linux (e.g. win32), and the same problem occured, so this does seem to be a freebsd issue. Peter -- Today is the first day of the rest of your life. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: UDP checksum invalid on FreeBSD7/x86
On Friday 20 June 2008 11:10:06 Andrey V. Elsukov wrote: > > I have a fresh installation of FreeBSD7 on x86, with no big changes to > > the system. > > Can you show `ifconfig -u` output? re0: flags=8843 metric 0 mtu 1500 options=9b ether 00:19:66:59:85:7f inet6 fe80::219:66ff:fe59:857f%re0 prefixlen 64 scopeid 0x1 inet 192.168.1.13 netmask 0xff00 broadcast 192.168.1.255 media: Ethernet autoselect (1000baseTX ) status: active lo0: flags=8049 metric 0 mtu 16384 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x5 inet 127.0.0.1 netmask 0xff00 Peter -- Billy: Mom, you know that vase you said was handed down from generation to generation? Mom:Yes? Billy: Well, this generation dropped it. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: UDP checksum invalid on FreeBSD7/x86
On Friday 20 June 2008 11:38:16 Andrey V. Elsukov wrote: > Peter Kirk wrote: > >> Can you show `ifconfig -u` output? > > > > re0: flags=8843 metric 0 mtu 1500 > > options=9b > > It's problem in re(4) driver. > Try to use `ifconfig re0 -rxcsum -txcsum`. You can add these > parameters to your rc.conf. In /etc/rc.conf I changed the line ifconfig_re0="inet 192.168.1.13 netmask 255.255.255.0" to ifconfig_re0="-rxcsum -txcsum inet 192.168.1.13 netmask 255.255.255.0" Now the problem no longer appears, even with "net.inet.udp.checksum=1". Thanks for answering this so promptly, hopefuly the re(4) driver can be fixed to avoid this kind of problem (or the -rxcsum -txcsum added automatically for this card). Peter -- Your manuscript is both good and original, but the part that is good is not original and the part that is original is not good. -- Samuel Johnson ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: UDP checksum invalid on FreeBSD7/x86
On Saturday 21 June 2008 02:19:40 Pyun YongHyeon wrote: > > Now the problem no longer appears, even with "net.inet.udp.checksum=1". > Thanks > for answering this so promptly, hopefuly the re(4) driver can be > fixed to > avoid this kind of problem (or the -rxcsum -txcsum added > automatically for > this card). > > Try re(4) on 7-stable and let me know how it goes. > Most checksum offload and bus_dma(9) related issues were fixed in > 7-stable. Sorry, I might not be in sync with "FreeBSD terms", but we installed FreeBSD-7 (the latest stable version), aren't I then already running 7-stable? uname -a says: FreeBSD FreeBSD32.zocker 7.0-RELEASE FreeBSD 7.0-RELEASE #0: Sun Feb 24 19:59:52 UTC 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC i386 Peter -- If you think nobody cares if you're alive, try missing a couple of car payments. -- Earl Wilson ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: SOLVED (was Re: Problem clarification (was: Problems with vlan + carp + alias))
On 2008-Jun-26 22:06:11 +0200, Giulio Ferro <[EMAIL PROTECTED]> wrote: > I guess what I could do was to "poison" their arp cache for each >address with a "is-at" message. Is there a way to force the sending >of these messages for all the addresses of an interface? The kernel should send out gratuitous ARP requests whenever you assign an address to an interface. You could confirm that this is happening by tcpdumping the interface whilst you add aliases. Rummaging around in ports, you might find net/arping or net/p5-Net-ARP useful if you want to manually generate gratuitous ARP requests. -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. pgpzclAQNBmMO.pgp Description: PGP signature
Re: SOLVED (was Re: Problem clarification (was: Problems with vlan + carp + alias))
On 2008-Jun-27 22:59:56 +0200, Giulio Ferro <[EMAIL PROTECTED]> wrote: >Peter Jeremy wrote: >> The kernel should send out gratuitous ARP requests whenever you assign >> an address to an interface. You could confirm that this is happening >> by tcpdumping the interface whilst you add aliases. >> >I have bad news for you all: this doesn't seem to happen for alias >interfaces. I've just tried to replicate what happened days >ago. I've verified that only the base (non alias) interface sends >proper is-at messages. The aliases don't I'm not seeing this on physical interfaces. I can't immediately verify this on VLAN interfaces but could at work next week. Adding 192.168.123.253 as an alias on FreeBSD 7.0-STABLE (mid May): 08:21:39.899113 00:0f:b0:74:9c:a3 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: arp who-has 192.168.123.253 tell 192.168.123.253 Adding 192.168.123.253 as an alias on FreeBSD 6.3-PRERELEASE: 08:24:21.077266 00:12:0e:20:2b:ad > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: arp who-has 192.168.123.253 tell 192.168.123.253 -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. pgpmwFmgmkYdF.pgp Description: PGP signature
arplookup x.x.x.x failed: host is not on local network
I'm occasionally seeing pairs of messages like the following on my NAT host: arplookup 192.168.181.114 failed: host is not on local network arpresolve: can't allocate route for 192.168.181.114 In my particular configuration, there are dual subnets between the NAT and target host. My initial assumption was that the request was arriving on the other subnet and I added if_xname to the arplookup printf() - but that shows that interface matches the IP address. I've looked back through the mailing lists but the previous reports of this problem don't match my scenario. I've seen this with FreeBSD 5.3, 6.2 and 7.0. The (in)frequency of the problem makes me wonder if it's actually a resource exhaustion problem. Has anyone got any suggestions? -- Peter Jeremy pgpxzJAMP0wQz.pgp Description: PGP signature
Re: arplookup x.x.x.x failed: host is not on local network
OK, my responses to the replies so far. One off-line reply requested a topology and netstat output. Since the toplogy may be relevant, below is an extremely simplified approximation (the real network has about 60 subnets and about 70 hosts, each appearing in between two and four subnets). Corp Network 192.168.10.0/24 | 192.168.12.0/24 +--+-+--| | |--+-+-+ .1| .2| .254| | |.254.3| .4| +---+ +---+ +---+ +---+ +---+ | | | | | | | | | | | host1 | | host2 | | NAT | | host3 | | host4 | | | | | | | | | | | +---+ +---+ +---+ +---+ +---+ .1| .2| .254| |.254.3| .4| +--+-+--| |--+-+-+ 192.168.11.0/24 192.168.13.0/24 The errors appear to be randomly spread across hosts and subnets. It does not appear consistently and seems to correlate with load (I am getting significant numbers at present and the NAT host is routing about 90Kpps and 100MBps if netstat can be believed). The problem also shows up on another interior routing host that has visibility across the internal networks so it isn't related to NAT or directly related to host load (that host is only seeing about 3.5Kpps - but is also a much slower host). I have managed to capture a tcpdump across the error. syslog reported: Jul 3 21:28:30 kernel: arplookup 192.168.169.26 failed: host is not on local network and the packets for that host during that second are: 21:28:30.320340 00:0b:cd:d6:66:26 > 00:03:ba:ab:6f:ef, ethertype 802.1Q (0x8100), length 64: vlan 169, p 0, ethertype IPv4, IP (tos 0x0, ttl 64, id 29304, offset 0, flags [none], length: 28) 192.168.169.26 > 192.168.169.111: icmp 8: echo request seq 35079 21:28:30.320429 00:d0:b7:20:8f:ee > 00:03:ba:ab:6f:ef, ethertype 802.1Q (0x8100), length 46: vlan 168, p 0, ethertype IPv4, IP (tos 0x0, ttl 63, id 29304, offset 0, flags [none], length: 28) 192.168.169.26 > 192.168.169.111: icmp 8: echo request seq 35079 21:28:30.320445 00:0b:cd:d6:66:26 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 169, p 0, ethertype ARP, arp who-has 192.168.169.250 tell 192.168.169.26 21:28:30.320459 00:0b:cd:d6:66:26 > 00:d0:b7:20:8f:ee, ethertype 802.1Q (0x8100), length 64: vlan 169, p 0, ethertype IPv4, IP (tos 0x0, ttl 64, id 29307, offset 0, flags [none], length: 28) 192.168.169.26 > 192.168.169.250: icmp 8: echo request seq 35079 21:28:30.320493 00:d0:b7:20:8f:ee > 00:0b:cd:d6:66:e4, ethertype 802.1Q (0x8100), length 46: vlan 168, p 0, ethertype IPv4, IP (tos 0x0, ttl 64, id 15305, offset 0, flags [none], length: 28) 192.168.169.250 > 192.168.169.26: icmp 8: echo reply seq 35079 21:28:30.320531 00:d0:b7:20:8f:ee > 00:0b:cd:d6:66:26, ethertype 802.1Q (0x8100), length 46: vlan 169, p 0, ethertype ARP, arp reply 192.168.169.250 is-at 00:d0:b7:20:8f:ee (this was captured MAC 00:d0:b7:20:8f:ee). Possibly, I'm seeing packet leakage from the switches and that is confusing FreeBSD - definitely the first packet above should not be visible. On 2008-Jul-03 09:05:15 +0200, Daniel Ponticello <[EMAIL PROTECTED]> wrote: >i'm having exactly the same problem, but without NAT configuration. Just >a simple host on network 192.168.170.xxx >that when tries to reach an host on 192.168.181.xxx: it gives the same error Except that in my case, the addresses _are_ local. On 2008-Jul-03 02:16:30 -0500, David DeSimone <[EMAIL PROTECTED]> wrote: >My theory is that this is a response to ARP requests. ARP requests are >broadcast, so the BSD box hears someone asking for this IP, but cannot >find it on any local interfaces, and so complains that it cannot >construct a proper reply. Except that the address it's complaining about is on a local subnet. Interestingly, in the above case, the host is spuriously seeing a packet and has re-routed it via vlan168 - which is the wrong subnet, though the destination host will still see it there. On 2008-Jul-03 10:48:22 +0300, Stefan Lambrev <[EMAIL PROTECTED]> wrote: >I bet 192.168.181.114 have a wrong network mask ;) You lose. -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. pgpWSmglYC3aZ.pgp Description: PGP signature
Re: Freebsd IP Forwarding performance (question, and some info) [7-stable, current, em, smp]
On 2008-Jul-07 13:25:13 -0700, Julian Elischer <[EMAIL PROTECTED]> wrote: >what you need is a speculative prefetch where you an tell teh >processor "We will probably need the following address so start >getting it while we go do other stuff". This looks like the PREFETCH instructions that exist in at least amd64 and SPARC. Unfortunately, their optimal use is very implementation- dependent and the AMD documentation suggests that incorrect use can degrade performance. -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. pgptHl9lUe7aI.pgp Description: PGP signature
Re: smbmount / smbclient : strangely varying transfer speeds
On 2008-Jul-07 16:15:40 +, Achim <[EMAIL PROTECTED]> wrote: >Performance with a single client is degraded when the client is smbmount and >downloading. >With a second transfer in any direction, performance becomes better, to about >3.5 resp. 8 MB/s depending on the second connection up- or downloading. >Unlike smbmount, single smbclient transfers yield acceptable results. Is this two transfers between a single server and single client or between a single server and two clients? In the former case, you might like to try a transfers involving two clients or two servers to try and identify which end is behaving oddly. -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. pgpmeZrUKgFAm.pgp Description: PGP signature
Re: too many open file descriptors messages since bind 9.4.2-P1 (port dns94)
On 2008-Jul-15 16:09:17 -0700, Bakul Shah <[EMAIL PROTECTED]> wrote: >IIRC, when poll() returns n, you only look at the first n >values in the pollfd array so it is a win when you expect a >very small number of fds to be ready. In the select case you >have to test the bit array until you see the last ready fd. No. Both poll(2) and select(2) return the number of FDs ready for I/O. You need to scan the pollfd or fd_set array until you find that many FDs ready. poll(2) is a win if you only need to test a small number of FDs compared to the number of FDs that the process has open. In the case of bind, you have a large number of FDs to test, of which you are only expecting a very small number to be ready - if you don't treat fd_set as opaque, select(2) allows you to quickly skip large (roughly wordsize) chunks of un-interesting FDs. Note that, based on sys_generic.c in 7.x and -CURRENT, poll(2) is limited to checking FD_SETSIZE descriptors, whilst select(2) has no upper limit. -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. pgpeMmtesf5SB.pgp Description: PGP signature
Re: "ping" with packets larger then 25152 bytes fails.
On 2008-Jul-16 10:41:57 +0300, Eitan Shefi <[EMAIL PROTECTED]> wrote: >When I run "ping" between 2 identical FreeBSD hosts, with packets larger >then 25152 bytes, "ping" fails. Intriguing. >Does someone has an idea what might cause this failure ? No, but a few more datapoints: - it only affects real network connections - localhost is unaffected - The problem also occurs when pinging FreeBSD 7.x from linux but not when the same linux system pings a Winbloze box. - Pinging either linux or winbloze from FreeBSD 7.x fails. -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. pgpmhSTDXKGbq.pgp Description: PGP signature
Re: "ping" with packets larger then 25152 bytes fails.
On 2008-Jul-16 12:37:59 -0700, Barney Cordoba <[EMAIL PROTECTED]> wrote: >> >When I run "ping" between 2 identical FreeBSD hosts, with packets larger >> >then 25152 bytes, "ping" fails. ... >Isn't this sort of like going to your auto dealer and complaining that you get >vibration at 240mph? I don't think so. There are no specific limits on the size of ICMP ECHO REQUEST or ICMP ECHO REPLY packets, therefore the only limit should be the IP packet limit (64KB). It does work with other IP stacks and with the loopback interface on FreeBSD. Poking around a bit more, the culprit looks like net.inet.ip.maxfragsperpacket - which is set to 16 by default. -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. pgpEyJ2bKFIKF.pgp Description: PGP signature
Signal quality/strength of FreeBSD hostap vs. commercial products
Hi, I am trying to build a FreeBSD wireless router for a while and I noticed that the signal strength is always substantial lower compared to common available wireless routers. At first I thought it was due to the wireless card I used, but I have tried several different ones and several different antennas, but it doesn¹t come close to common routers. Strangely enough when I started to use an adhoc connection, the signal strength reported was as good as a common router. For clients I have used different cards as well as Windoze and MACOSX. Setting of txpower doesn¹t do anything. Any explanations? Peter ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: lost routes
On 2008-Sep-23 10:00:50 +0200, Giulio Ferro <[EMAIL PROTECTED]> wrote: >I think this is a very old freebsd problem, dating back to freebsd5 >or even before. I don't recall seeing it, or previous references to this problem, so all I can offer is more questions. I presume you aren't running any sort of routing daemon or DHCP client. >Every now and again static routes are lost by freebsd. >In my fw/router/vpn box (average traffic about 10Mb/s) with a lot >of interfaces, physical, vlan and virtual, once every x weeks (x very >variable) one of the routes get lost. Is it a random route, or is it always the same route being lost? If it's different routes, is there anything in common between the routes that are lost? Are all your interfaces on disjoint subnets? -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. pgpDouhXIQYk7.pgp Description: PGP signature
Re: CARP performance tuning question.
Whilst I don't doubt that you have a problem, your comments don't correlate particularly well with the data you have provided and this makes it difficult to immediately suggest a solution. On 2008-Nov-05 16:40:32 +0300, pluknet <[EMAIL PROTECTED]> wrote: >AT work we use device carp(4) under high load: carp(4) is solely a failover mechanism. It either generates or receives somewhat under 1pps per carp interface and the state it maintains is basically 'master' or 'backup'. I suspect the 'load' is being caused by pf(4), possibly in conjunction with pfsync(4). >The problem is that the server experiences a bad interactivity (from >70k states and very bad from 120-150k) >i.e. when a network workload (and interrupts count) begin to increase. > >>From top(1): >CPU states: 0.0% user, 0.0% nice, 0.4% system, 76.3% interrupt, 23.3% idle > PID USERNAMETHR PRI NICE SIZERES STATETIME WCPU COMMAND > 13 root 1 -44 -163 0K 8K WAIT 407:43 57.86% swi1: net I agree that swi1 is using a significant amount of CPU but top is still reporting >23% idle so you shouldn't be getting poor interactive performance. >ATM pfctl -s info shows such numbers: > >State Table Total Rate > current entries 153972 > searches 6052078938 4800.8/s > inserts120373545 95.5/s > removals 120219573 95.4/s That shows the load on pf(4) but doesn't really reflect what the system is doing as a whole. >It works currently under UP, but could be rebuilt to work under SMP >(Xeon 5130) if that helps. Unfortunately, I don't know if this will help or not because I'm not sure what bottleneck you are hitting. >Can someone give hints to decrease interrupt count and to help with >the server stability at all? Well, you haven't actually reported what the interrupt count or what instability you are seeing so this is a bit difficult. Can you please provide some more information: - output from 'uname -a' - output from 'vmstat -i; sleep 10; vmstat -i' under load - output from 'netstat -i' - 10-15 seconds of output from 'netstat -i 1' under load - What is the box doing? Is it a straight filtering router? Does it handle NAT? Is it running apps itself (eg web, ftp, mail)? - What speed are the interface(s) running at? - What instability problems are you seeing? - Please provide more details on what you mean by 'bad interactivity'. - How complex is your pf ruleset? How many rules? Anything unusual? - What scheduler are you using? - What is the full output of 'pfctl -s info'? -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. pgpLULZODpu1a.pgp Description: PGP signature
