FreeBSD jail can't talk to internet through multiple routers

[Jeff]

Hi,

I run PCBSD 9.1 and have a jail setup (uses the Warden PBI to set it up).

In that jail which has it's own local IP like 192.168.1.12, I have an Apache 
server running Drupal.

Normally when I connect the computer to a single router that is connected to a 
modem, I set "nameserver 192.168.1.1", i.e. the router LAN IP or gateway, in 
etc/resolv.conf and have no problems.

Now I have added a 2nd router daisy chained from the primary router, running a 
subnet (primary router has IP: 192.168.1.1 and secondary router: 192.168.2.1).  

The computer running the jail is plugged into the secondary router.

The problem is, the jail can't contact the internet.  I can SSH into the jail 
but it takes a very long time to connect, like 30 seconds or so.


I've tried different IP addresses for "nameserver" but nothing works.

I have no problems using the internet from the main part of the computer, just 
the jails.


Any ideas why this happens and how to get around it?  I've had this problem for 
years with different versions of FreeBSD.

Do I need to create a static route through to the gateway, and if so, why is 
that not a problem using a browser from the main part of the machine?


Thanks,

Jeff
___
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"

Net problem with server running in jail

[Jeff]

 active
plip0: flags=108810
 metric 0 mtu 1500
lo0: flags=8049
 metric 0 mtu 16384

    inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3
    inet6 ::1 
prefixlen 128
    inet 127.0.0.1 netmask 0xff00
pfsync0: 
flags=0<> metric 0 mtu 1460
    syncpeer: 224.0.0.240 
maxupd: 128

pflog0: flags=0<> metric 0 mtu 33204
--
#
 netstat -rn
Routing tables

Internet:
Destination     
Gateway          Flags   Refs Use    Netif   Expire
default       
 192.168.1.2         UGS 0       3323 bge0

127.0.0.1        127.0.0.1            UH        0   22        
lo0
192.168.1.0/24 
link#1            UC        0   0          bge0
192.168.1.2      
00:21:29:e4:34:e4  UHLW   2  447       bge0   1176

192.168.1.255  ff:ff:ff:ff:ff:ff              UHLWb 1   59         
bge0

Internet6:
Destination  
 Gateway   Flags  Netif Expire
::1  
 ::1   UHL lo0

fe80::%lo0/64 fe80::1%lo0   
U   lo0
fe80::1%lo0   
link#3    UHL lo0
ff01:3::/32  
 fe80::1%lo0   UC  lo0

ff02::%lo0/32 fe80::1%lo0   
UC  lo0
=


What could cause the server latency to be so high, and why can't Drupal access 
the internet?  I have had this problem on and off for years, going back to FBSD 
6, but have never figured out the problem or how I got out of it.  This time 
nothing is working.

Thanks, Jeff







___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

tcp listen problem

[Jeff]

We are seeing an intermittent problem with FreeBSD 6.2 and our
custom web server application, where incoming listens will
sometimes not be passed to our application to be accepted. It is as
if the listen queue is "clogged" somehow, and all incoming listens
are blocked from being passed to our application. The clogged state
lasts anywhere from a few minutes to over 30 minutes, then (if we
wait it out) picks up and runs as if nothing had gone wrong. When the
application picks up, the pending requests are accepted by our
application with an error that they timed out on the client, and with
new listens accepted and working fine. Other applications, and other
ip:port pairs in our application, all continue to work fine while a
listen for a particular ip:port is clogged.

Our short-term fix for the problem is to check for incoming listens
completing, and if none come in for a 2 second period to call
ourselves and make sure that our call to ourselves completes. If not,
then we kill the instance and restart. Restarting the application
fixes the problem immediately (except that the listens in the queue
at the time of the restart are lost and get errors). The problem is
that the short-term fix reduces our uptime from 100% to 99.5%, and
this is simply not an acceptable level of service for our customers;
we have to fix this...

Internal details on what we are doing:
* using select for polled I/O, with all I/O requests coming out of a
single thread
* using threads for incoming requests in a single process (this is
because it is a database application, and we need all threads to
access the database cache)

We've checked a tcpdump of incoming calls, and can't see anything
funny about the calls that clog the listen queue; they look fine to
us. So doesn't look like an attack per se.

Incidence seems to be random. We might have 4-5 days without any,
then get 10 in one day close together, or get one every now and then.

Any help would be much appreciated, and we would be happy to hire
someone on a consulting basis to help resolve.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

IPMI doesn't work...

[Jeff]

on a 5.3 amd64 system.  anyone have any luck or know anything about 
this?  i can query variables right up until the point where the kernel 
loads, then nothing.  ibm is saying this can be caused by the actual nic 
driver (the Baseboard Management Controller (BMC) shares the network 
interface); the system uses a Broadcom BCM5704C Dual gig adapter:

bge0:  mem 
0xfe00-0xfe00,0xfe01-0xfe01 irq 24 at device 1.0 on pci2

anyone have any idea why this may be the case?  unfortunately for me and 
others here, the inability to remotely manage boxes (console/power 
cycle/detect drive failures/etc) via ipmi will be a deal breaker in our 
push for FBSD in our fleet (couple hundred) of dual proc amd64 IBM e325 
servers.  SuSE here we come (unwillingly)...

thx
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: IPMI doesn't work...

[Jeff]

Julian Elischer wrote:
I use IPMI with intel boards using the fxp driver.
it seems to work ok..
The only problem I have seen its that is IS possible for the OS to 
turn off the
NIC so that IPMI can't be reached..
Usually during a  'suspend' or similar.
On a server you wouldn't do that however.
I don't think it's the case of the OS turning off the NIC.  We can 
access/monitor/control the chassis via the BMC fine through the bios 
assigned IP address when the computer is off, and when it is booting, 
but lose control when the kernel loads (the bios assigned ip address is, 
of course, different from what OS assigns).  It seems odd to me how the 
BMC shares the NIC, but maybe this is normal...I'm new to IPMI.

___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: IPMI doesn't work...

[Jeff]

Jung-uk Kim wrote:
On Monday 14 March 2005 02:32 pm, Jeff wrote:
 


on a 5.3 amd64 system.  anyone have any luck or know anything about
this?  i can query variables right up until the point where the
kernel loads, then nothing.  ibm is saying this can be caused by
the actual nic driver (the Baseboard Management Controller (BMC)
shares the network interface); the system uses a Broadcom BCM5704C
Dual gig adapter:
bge0: 
mem 0xfe00-0xfe00,0xfe01-0xfe01 irq 24 at device
1.0 on pci2
   

Does 'in-band' mode work for you?  Try FreeIPMI to check:
http://www.gnu.org/software/freeipmi/
http://www.freshports.org/sysutils/freeipmi/
 

I'm not sure what you mean by in band.  The IP address of the BMC is 
assigned via the bios and is different from what the OS later assigns.  
With imiptool we can turn on/powercycle/monitor via the BMC assigned 
address up until the point where the kernel loads.  Once it does, the 
BMC no longer responds.  This doesn't happen with the two linux distros 
we've tried it on.  Wtih both, including SuSE, we can still 
query/control via the BMC using ipmitool.  It seems to be some sort of 
driver issue to me.  I find it confusing that the NIC is shared between 
the BMC and the OS, but I guess that's just how it's done.  Perhaps the 
bsd broadcomm driver is simply blocking this somehow...

jeff
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: IPMI doesn't work...

[Jeff]

so i poked through the broadcom driver code for linux  
(http://www.broadcom.com/drivers/downloaddrivers.php) and found quite a 
few mentions of ASF/IPMI in the code.  a little research shows that the 
Alert Standard Forum (ASF) defines the Remote Management Control Packet 
(RMCP)  used in IPMI-over-LAN.  see the readme for ipmitool:

http://cvs.sourceforge.net/viewcvs.py/ipmitool/ipmitool/README?rev=1.2&view=markup
the readme also says the address of the bmc must be the same as that of 
the system (as someone mentioned earlier), but i've found this not to be 
the case on other platforms.  it makes a lot of sense to not tie the two 
addresses together.  a change in ip

unfortunateley, i'm no driver coder or i'd attempt a patch...

Michael Vince wrote:
Just out of interest has any one got serial console to work with this 
IPMI stuff?
I was looking at regular 9pin serial alternatives since Dell machines 
normally only have 1 serial port and I prefer 2.

Regards,
Mike
Bruce M Simpson wrote:
On Mon, Mar 14, 2005 at 04:26:16PM -0800, Jeff wrote:
 

I don't think it's the case of the OS turning off the NIC.  We can 
access/monitor/control the chassis via the BMC fine through the bios 
assigned IP address when the computer is off, and when it is 
booting, but lose control when the kernel loads (the bios assigned 
ip address is, of course, different from what OS assigns).  It seems 
odd to me how the BMC shares the NIC, but maybe this is normal...I'm 
new to IPMI.
  

I can only speak for looking at the Intel gigabit chip datasheets and
our em(4) driver somewhat, but there are registers which control the
'pass through' which IPMI uses. It could be that the bge driver is
unaware of the registers Broadcom added to support IPMI.
In this case we'd need to find out what they are and teach the driver
not to meddle with them.
Regards,
BMS
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
 


___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: IPMI doesn't work...

[Jeff]

Jung-uk Kim wrote:
On Tuesday 15 March 2005 01:14 am, Jeff Behl wrote:
 

Julian Elischer wrote:
   

Jeff wrote:
 

I'm not sure what you mean by in band.  The IP address of the
BMC is assigned via the bios and is different from what the OS
later assigns.  With imiptool we can turn on/powercycle/monitor
via the BMC assigned address up until the point where the kernel
loads.  Once it does, the BMC no longer responds.  This doesn't
happen with the two linux distros we've tried it on.  Wtih both,
including SuSE, we can still query/control via the BMC using
ipmitool.  It seems to be some sort of driver issue to me.  I
find it confusing that the NIC is shared between the BMC and the
OS, but I guess that's just how it's done.  Perhaps the bsd
broadcomm driver is simply blocking this somehow...
   

you have to assign it the same address!
 

that's not the way it's supposed to work, afaik.  it'd be silly to
tie the BMC address and the OS assigned address together.  you give
the BMC an ip address via a little program that comes from IBM and
this address is independent of the ip address that whatever os you
use on the system assigns to the nic.  the redbook that Jung-uk
sent a link for shows this process if you're interested.
   

I believe you are correct.  If you have the same IP address, the 
packet reaches host OS and (I think) it must be discarded by OS.  
IPMI spec. is very verbose but I found very simple explanation here:

http://www.ethereal.com/lists/ethereal-dev/200304/msg00233.html
'IPMI messages are encapsulated in Remote Management Control Protocol 
packets.  RMCP is a UDP-based protocol that uses port 623 for remote 
system control when the system is in a pre-os or os-absent state.  
RMCP can also use port 664 for secure traffic.'

FYI, IPMI v2.0 defines extended RMCP, so called RMCP+.
 

like i said earlier, having different ip addresses (the BMC's being
in private address space) works fine with the linux kernel...
   

Just out of my curiosity, are you using bcm or tg3 driver on Linux?
Thanks,
Jung-uk Kim
 

the tg3, according to lsmod.  it looks like the bcm and the tg3 share 
common code (tigon3.c is included in the bcm source)...

___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

kerberos problems

[Jeff]

Hello,

Recently I have setup KerberosV (the kdc is on a NetBSD system).
I have client boxes on NetBSD, OpenBSD, and FreeBSD.  On all of the
boxes, I can successfully kinit (k5init on FreeBSD) a ticket, and 
change my password.  Then I enable telnet on all of the above,
I can connect to any of the three (Net/Open/FreeBSD) boxes, from either
the Net, or OpenBSD boxes,  however when I try to telnet out from the
FreeBSD box (I have tried this on both a 4.7-RELEASE and -CURRENT box)
(separate machines entirely FWIW)
I get...

[ Trying mutual KERBEROS5 ([EMAIL PROTECTED])... ]
Bus error (core dumped)

...
I have not yet tried to debug the core file, that is my next step,
but in the mean time, if anyone knows what/where the problem may be,
I would appreciate any suggestions.

Thank You
Jeff

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message

Re: kerberos problems

[Jeff]

I managed to track down another thread that I must have missed
during earlier purusing of the archives, that states the same problem
that was "fixed" by installing krb5 from ports, which I am attempting 
currently.  Does anyone know of a fix/where the problem lies for the
krb5 that ships with FBSD?

Thanks

> Recently I have setup KerberosV (the kdc is on a NetBSD system).
> I have client boxes on NetBSD, OpenBSD, and FreeBSD.  On all of the
> boxes, I can successfully kinit (k5init on FreeBSD) a ticket, and 
> change my password.  Then I enable telnet on all of the above,
> I can connect to any of the three (Net/Open/FreeBSD) boxes, from either
> the Net, or OpenBSD boxes,  however when I try to telnet out from the
> FreeBSD box (I have tried this on both a 4.7-RELEASE and -CURRENT box)
> (separate machines entirely FWIW)
> I get...
> 
> [ Trying mutual KERBEROS5 ([EMAIL PROTECTED])... ]
> Bus error (core dumped)
> 
> ...
> I have not yet tried to debug the core file, that is my next step,
> but in the mean time, if anyone knows what/where the problem may be,
> I would appreciate any suggestions.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message

vlan changes to support ipoib

[Jeff Roberson]

Hi Folks,

I have made some changes to vlans and I was wondering if anyone would care 
to review or test.  Especially current vlan users.  The diff is here:


http://people.freebsd.org/~jeff/vlan.diff

I can't say that I like adding all of the function pointers but with vlan 
support available as a loadable module I have little choice.  The new 
functions allow a driver to fetch the virtual interface associated with a 
tag, cache and fetch a cookie pointer in a virtual interface, and fetch 
the tag of a virtual interface.


Additionally, the driver was changed to make no assumptions about address 
size unless the type is IFT_ETHER.  This means for multicast entries we 
store a full sockaddr_dl rather than an ethernet address.  It actually 
simplifies the code here.  I also simplified the VLAN_ARRAY stuff by 
moving it into functions that match the hash names so there aren't ifdef's 
everywhere.  I've tested both hash and array.


I also changed the global mtx to an sx lock so the vlan_config event 
handlers can allocate memory.  The way ipoib works requires a full new 
ipoib softc when a vlan is created.  I didn't want to duplicate the vlan 
config logic so I store that softc using the cookie field and fetch it 
when necessary.  As a result ipoib also doesn't need the weird 
vlan_input() recursion since the packets appear on the correct device as 
they are received.


I am committing this to my infiniband tree immediately but I would like 
some review before I merge to current.


Thanks,
Jeff
___
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: vlan changes to support ipoib

[Jeff Roberson]

On Sun, 9 Jan 2011, Bjoern A. Zeeb wrote:


On Sat, 8 Jan 2011, Jeff Roberson wrote:


Hi Folks,

I have made some changes to vlans and I was wondering if anyone would care 
to review or test.  Especially current vlan users.  The diff is here:


http://people.freebsd.org/~jeff/vlan.diff

I can't say that I like adding all of the function pointers but with vlan 
support available as a loadable module I have little choice.  The new 
functions allow a driver to fetch the virtual interface associated with a 
tag, cache and fetch a cookie pointer in a virtual interface, and fetch the 
tag of a virtual interface.


Additionally, the driver was changed to make no assumptions about address 
size unless the type is IFT_ETHER.  This means for multicast entries we 
store a full sockaddr_dl rather than an ethernet address.  It actually 
simplifies the code here.  I also simplified the VLAN_ARRAY stuff by moving 
it into functions that match the hash names so there aren't ifdef's 
everywhere.  I've tested both hash and array.


I also changed the global mtx to an sx lock so the vlan_config event 
handlers can allocate memory.  The way ipoib works requires a full new 
ipoib softc when a vlan is created.  I didn't want to duplicate the vlan 
config logic so I store that softc using the cookie field and fetch it when 
necessary.  As a result ipoib also doesn't need the weird vlan_input() 
recursion since the packets appear on the correct device as they are 
received.


I am committing this to my infiniband tree immediately but I would like 
some review before I merge to current.


May I ask you to split the diff up into logical junks for both review
and commit?  Otherwise possible errors not caught with by review will
just be a lot harder to track down later.


Most if not all of the chunks are interdependent or useless without each 
other.  When I commit to current it will probably be a merge from my 
branch anyway.


What would you like to see separated?



Some of the stuff like "Initialize from parent" seems to be simple
enough to be possibly merged just upfront leaving the real beef.


I notice that I don't have many comments.  Perhaps if I documented better 
what I have done it would be sufficient?


Thanks,
Jeff



/bz

--
Bjoern A. Zeeb You have to have visions!
Going to jail sucks --  All my daemons like it!
 http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/jails.html


___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

8.0-REL lagg(4) + vlan(4) + em(4) problems

[Jeff Blank]

I've just upgraded a 7.1-REL server to 8.0-REL and have lost my
ability to use vlan(4) on top of lagg(4) on top of em(4).  (Not sure
about other interface types, just encountered the problem tonight.)
Using tcpdump, I see that I can receive 802.1q-tagged traffic (and on
the correct VLAN interface), but the switch appears to receive frames
from the server without 802.1q tags--the only bridge entry on the
switch port is on the "default" untagged VLAN.  Setting the switch
port to untagged and configuring lagg0 with an IP address works fine
(bidirectionally), and making em0 or em1 the vlandev for the VLAN
interface also works fine.

My ems, in case the problem is there and not in lagg:

e...@pci0:5:0:0: class=0x02 card=0x135e8086 chip=0x105e8086 rev=0x06 
hdr=0x00
vendor = 'Intel Corporation'
device = 'HP NC360T PCIe DP Gigabit Server Adapter (n1e5132)'
class  = network
subclass   = ethernet
e...@pci0:5:0:1: class=0x02 card=0x135e8086 chip=0x105e8086 rev=0x06 
hdr=0x00
vendor = 'Intel Corporation'
device = 'HP NC360T PCIe DP Gigabit Server Adapter (n1e5132)'
class  = network
subclass   = ethernet

I didn't see anything about this on current@, stable@, or here over
the last few months, only at the FreeBSD forums
(http://forums.freebsd.org/showthread.php?t=7668).  There's also open
PR kern/132715, but I'm not experiencing panics, just incorrect
behaviour.  Is my issue known in any way?  Any suggestions other than
filing a PR (which I'll be happy to do)?

thanks,
Jeff
___
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: 8.0-REL lagg(4) + vlan(4) + em(4) problems

[Jeff Blank]

I wrote:
> I've just upgraded a 7.1-REL server to 8.0-REL and have lost my
> ability to use vlan(4) on top of lagg(4) on top of em(4).

I should have mentioned that I'm using lagg failover.  I can reproduce
my problem in single-user as follows:

# ifconfig em0 up
# ifconfig em1 up
# ifconfig lagg0 create laggproto failover laggport em0 laggport em1 up
# ifconfig vlan20 create vlan 20 vlandev lagg0
# ifconfig vlan20 / up

Jeff
___
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/142518: [em] [lagg] Problem on 8.0-STABLE with em and lagg

[Jeff Blank]

The following reply was made to PR kern/142518; it has been noted by GNATS.

From: Jeff Blank 
To: bug-follo...@freebsd.org
Cc:  
Subject: Re: kern/142518: [em] [lagg] Problem on 8.0-STABLE with em and lagg
Date: Wed, 13 Jan 2010 11:37:16 -0500

 On Mon, Jan 11, 2010 at 09:45:11AM +, lini...@freebsd.org wrote:
 > http://www.freebsd.org/cgi/query-pr.cgi?pr=142518
 
 Please see also kern/141646.  This may well be the same issue.
 
 Jeff
___
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/141646: [em] em(4) + lagg(4) + vlan(4) generates ISL-tagged frames instead of 802.1q-tagged frames

[Jeff Blank]

On Fri, Jan 29, 2010 at 02:47:39PM -0800, Jack Vogel wrote:
> What's with the encrypted messages entered in this bug suddenly?

Just base64-encoded plain text--it appears GNATS is not base64-aware.
To summarize (I received a copy directly), Mr. Anishchuk is
experiencing the same problem and suggested a workaround (also posted
to the list previously) involving "ifconfig_emN='-vlanhwtag up'" in
rc.conf.  He also seemed to think it was twice-Q-tagged frames rather
than ISL-tagged frames, which does not match my packet captures.

> An important update - I have root caused this. Turns out its kinda
> interesting.
> The reason there is a problem is due to the stacked pseudo devices, since
> the vlan device is on lagg, and not directly on em, the em driver is not
> getting
> the "event" of the vlan attachment, and thus the vlan hw filter routine is
> never
> run, that routine sets a CRITICAL bit in the control register which
> differentiates
> between ISL and 802 tags... and thus our failure :(
> The question now is what to do about this, I am thinking about this now

Interesting indeed.  I look forward to a fix (and have alternate
interfaces and -vlanhwtag in the mean time).

thanks,
Jeff
___
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/141646: [em] em(4) + lagg(4) + vlan(4) generates ISL-tagged frames instead of 802.1q-tagged frames

[Jeff Blank]

On Fri, Jan 29, 2010 at 04:13:50PM -0800, Jack Vogel wrote:
> Fix is just checked into HEAD,  its sort of a workaround, but really a
> pretty acceptable one. Let me know if it works for you.

should it work to import HEAD's sys/dev/e1000 into 8.0R (or some part
of it)?  I can test it out on Monday if so.  anything else I'd need to
do in that case?

thanks,
Jeff
___
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/141646: [em] em(4) + lagg(4) + vlan(4) generatesISL-tagged frames instead of 802.1q-tagged frames

[Jeff Blank]

On Sat, Jan 30, 2010 at 01:47:31AM -, Steven Hartland wrote:
> Since your using lagg there Jeff have you done on perf testing at
> all, when I tested here dual em0 + lagg + lacp => cisco 6509 although
> all seemed to negotiate correctly, balancing wasn't working at all.

Haven't done any perf testing, but I'm using failover, not LACP.

Jeff
___
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/141646: [em] em(4) + lagg(4) + vlan(4) generates ISL-tagged frames instead of 802.1q-tagged frames

[Jeff Blank]

On Fri, Feb 05, 2010 at 03:26:46PM +0100, Ermal Luçi wrote:
> Anybody interested can please try the patch at this location
> http://tinyurl.com/yk7qbtb.
> It is against 8-STABLE though should apply even to 8-RELEASE.

Ermal,

This works great!  I see it's been committed to HEAD as well.

Thank you!

Jeff
___
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/125239: [gre] kernel crash when using gre

[Jeff Mo]

The following reply was made to PR kern/125239; it has been noted by GNATS.

From: Jeff Mo 
To: bug-follo...@freebsd.org, damien.sau...@uclouvain.be
Cc:  
Subject: Re: kern/125239: [gre] kernel crash when using gre
Date: Wed, 17 Feb 2010 10:32:00 -0800

 --00504502c5f9e57206047fd010ce
 Content-Type: text/plain; charset=ISO-8859-1
 
 Hello all,
 
 I found the solution about why this bug occurs :
 <http://www.freebsd.org/cgi/query-pr.cgi?pr=125239&cat=>
 I would like to contribute my knowledge to FreeBSD website and you can
 find my solution in the attached. Please let me know your comment and
 look forward to your reply.
 
 Thanks,
 -- 
 Jeff Mo
 Santa Clara University
 Linux+, SCJP, SCWCD, MCSD
 
 --00504502c5f9e57206047fd010ce
 Content-Type: application/octet-stream; name=kern_125239
 Content-Disposition: attachment; filename=kern_125239
 Content-Transfer-Encoding: base64
 X-Attachment-Id: f_g5sgk88g0
 
 VGhlIHByb2JsZW0gaW4gMTI1MjM5IG9jY3VycyBiZWNhdXNlIHRoZSBpbXBsZW1lbnRhdGlvbiBv
 ZiBpbl9zZXRfdHVubmVsIGZ1bmN0aW9uIGluCgphZl9pbmV0LmMgd3JvbmdseSBjcmVhdGVzIGEg
 bG9jYWwgc3RydWN0IHZhcmlhYmxlIChhZGRyZXEpLCByYXRoZXIgdGhhbiB1c2luZyBleGlzdGlu
 ZwoKZ2xvYmFsIHN0cnVjdCB2YXJpYWJsZShpbl9hZGRyZXEpLCB0byBzdG9yZSByZWxhdGVkIGFk
 ZHJlc3MgaW5mb3JtYXRpb24gb2YgdHVubmVsLgoKVGhlcmVmb3JlLCB3aGVuIHdlIHVzZSBnZGIg
 dG8gdHJhY2UgdGhlIGNvZGUgYmVmb3JlIGVudGVyaW5nIGlvY3RsLCB3ZSBmb3VuZCB0aGF0IGFm
 cAoKLT5hZl9hZGRyZXEgZG9lcyBub3QgY2FycnkgYW55IHNvdXJjZSBhbmQgZGVzdGluYXRpb24g
 YWRkcmVzcyBpbmZvcm1hdGlvbiBpbnRvIGtlcm5lbC4KVGhlIGZvbGxvd2luZyBzaG93cyB0aGUg
 dHJhY2luZyByZXN1bHQgYmVmb3JlIG1vZGlmaWNhdGlvbjoKCihnZGIpIHAgKihzdHJ1Y3QgaWZh
 bGlhc3JlcSAqKWFmcC0+YWZfYWRkcmVxCiQxID0gewogIGlmcmFfbmFtZSA9ICdcMCcgPHJlcGVh
 dHMgMTUgdGltZXM+LAogIGlmcmFfYWRkciA9IHsKICAgIHNhX2xlbiA9IDAgJ1wwJywKICAgIHNh
 X2ZhbWlseSA9IDAgJ1wwJywKICAgIHNhX2RhdGEgPSAnXDAnIDxyZXBlYXRzIDEzIHRpbWVzPgog
 IH0sCiAgaWZyYV9icm9hZGFkZHIgPSB7CiAgICBzYV9sZW4gPSAwICdcMCcsCiAgICBzYV9mYW1p
 bHkgPSAwICdcMCcsCiAgICBzYV9kYXRhID0gJ1wwJyA8cmVwZWF0cyAxMyB0aW1lcz4KICB9LAog
 IGlmcmFfbWFzayA9IHsKICAgIHNhX2xlbiA9IDE2ICdcMDIwJywKICAgIHNhX2ZhbWlseSA9IDAg
 J1wwJywKICAgIHNhX2RhdGEgPSAiXDAwMFwwMDDDg8K/w4PCv8ODwr/Dg8K/XDAwMFwwMDBcMDAw
 XDAwMFwwMDBcMDAwXDAwMCIKICB9Cn0KCk91ciBwcm9wb3NlZCBzb2x1dGlvbiBpcyB2ZXJ5IHN0
 cmFpZ2h0Zm9yd2FyZC4gSW5zdGVhZCBvZiBkZWNsYXJpbmcgYSBuZXcgbG9jYWwKCnZhcmlhYmxl
 LCB3ZSBzaG91bGQgc3RvcmUgYWRkcmVzcyBkYXRhIGluIHRoZSBnbG9iYWwgdmFyaWFibGUgdGhh
 dCB3aWxsIGJlIHVzZWQgYXMgYQoKcGFyYW1ldGVyIG9mIGlvY3RsIGZ1Y3Rpb24uIE9uY2Ugb3Vy
 IGNoYW5nZXMgYXJlIGFwcGxpZWQsIFRoZSBzeXN0ZW0gcnVucyBhcyBub3JtYWwgYXMgaXQgc2hv
 dWxkIGJlIGFuZCBub3QgY3Jhc2ggYWdhaW4uCgpUaGUgZm9sbG93aW5nIGZpeCBpcyBhcHBsaWVk
 IHRvIHNvdXJjZSBmcm9tIHRoZSBGcmVlQlNEIDcuMCByZWxlYXNlCgotLS0gYWZfaW5ldC5jLm9s
 ZCAgICAgICAyMDA4LTA5LTI5IDExOjI1OjMyLjAwMDAwMDAwMCArMDAwMAorKysgYWZfaW5ldC5j
 ICAgMjAwOC0xMC0wMSAwMjowMzoxMS4wMDAwMDAwMDAgKzAwMDAKQEAgLTE2NywxMyArMTY3LDEy
 IEBACiBzdGF0aWMgdm9pZAogaW5fc2V0X3R1bm5lbChpbnQgcywgc3RydWN0IGFkZHJpbmZvICpz
 cmNyZXMsIHN0cnVjdCBhZGRyaW5mbyAqZHN0cmVzKQogewotICAgICAgIHN0cnVjdCBpZmFsaWFz
 cmVxIGFkZHJlcTsKLSAgICAgICBtZW1zZXQoJmFkZHJlcSwgMCwgc2l6ZW9mKGFkZHJlcSkpOwot
 ICAgICAgIHN0cm5jcHkoYWRkcmVxLmlmcmFfbmFtZSwgbmFtZSwgSUZOQU1TSVopOwotICAgICAg
 IG1lbWNweSgmYWRkcmVxLmlmcmFfYWRkciwgc3JjcmVzLT5haV9hZGRyLCBzcmNyZXMtPmFpX2Fk
 ZHItPnNhX2xlbik7Ci0gICAgICAgbWVtY3B5KCZhZGRyZXEuaWZyYV9kc3RhZGRyLCBkc3RyZXMt
 PmFpX2FkZHIsIGRzdHJlcy0+YWlfYWRkci0+c2FfbGVuKTsKKyAgICAgICBtZW1zZXQoJmluX2Fk
 ZHJlcSwgMCwgc2l6ZW9mKGluX2FkZHJlcSkpOworICAgICAgIHN0cm5jcHkoJmluX2FkZHJlcS5p
 ZnJhX25hbWUsIG5hbWUsIElGTkFNU0laKTsKKyAgICAgICBtZW1jcHkoJmluX2FkZHJlcS5pZnJh
 X2FkZHIsIHNyY3Jlcy0+YWlfYWRkciwgc3JjcmVzLT5haV9hZGRyLT5zYV9sZW4pOworICAgICAg
 IG1lbWNweSgmaW5fYWRkcmVxLmlmcmFfZHN0YWRkciwgZHN0cmVzLT5haV9hZGRyLCBkc3RyZXMt
 PmFpX2FkZHItPnNhX2xlbik7CgotICAgICAgIGlmIChpb2N0bChzLCBTSU9DU0lGUEhZQUREUiwg
 JmFkZHJlcSkgPCAwKQorICAgICAgIGlmIChpb2N0bChzLCBTSU9DU0lGUEhZQUREUiwgJmluX2Fk
 ZHJlcSkgPCAwKQogICAgICAgICAgICAgICAgd2FybigiU0lPQ1NJRlBIWUFERFIiKTsKIH0KClRo
 ZSBmb2xsb3dpbmcgc2hvd3MgdGhlIHRyYWNpbmcgcmVzdWx0IGFmdGVyIG1vZGlmaWNhdGlvbjoK
 CihnZGIpIHAgKihzdHJ1Y3QgaWZhbGlhc3JlcSAqKWFmcC0+YWZfYWRkcmVxCiQxID0gewogIGlm
 cmFfbmFtZSA9ICJncmUwIiwgJ1wwJyA8cmVwZWF0cyAxMSB0aW1lcz4sCiAgaWZyYV9hZGRyID0g
 ewogICAgc2FfbGVuID0gMTYgJ1wwMjAnLAogICAgc2FfZmFtaWx5ID0gMiAnXDAwMicsCiAgICBz
 YV9kYXRhID0gIlwwMDBcMDAwXG5cblxuXDAwMVwwMDBcMDAwXDAwMFwwMDBcMDAwXDAwMFwwMDAi
 CiAgfSwKICBpZnJhX2Jyb2FkYWRkciA9IHsKICAgIHNhX2xlbiA9IDE2ICdcMDIwJywKICAgIHNh
 X2ZhbWlseSA9IDIgJ1wwMDInLAogICAgc2FfZGF0YSA9ICJcMDAwXDAwMFxuXG5cblwwMDJcMDAw
 XDAwMFwwMDBcMDAwXDAwMFwwMDBcMDAwIgogIH0sCiAgaWZyYV9tYXNrID0gewogICAgc2FfbGVu
 ID0gMTYgJ1wwMjAnLAogICAgc2FfZmFtaWx5ID0gMCAnXDAnLAogICAgc2FfZGF0YSA9ICJcMDAw
 XDAwMMODwr/Dg8K/w4PCv8ODwr9cMDAwXDAwMFwwMDBcMDAwXDAwMFwwMDBcMDAwIgogIH0KfQoK
 CkNoaWVoLUZ1IE1vLCBTdHVkZW50CkNPRU4gMjg0LCBPcGVyYXRpbmcgU3lzdGVtcyBDYXNlIFN0
 dWR5ClNhbnRhIENsYXJhIFVuaXZlcnNpdHkKCg==
 --00504502c5f9e57206047fd010ce--
___
freebsd-net@freebsd.org mailing

Re: kern/144898: [wpi] [panic] wpi panics system

[jeff curry]

The following reply was made to PR kern/144898; it has been noted by GNATS.

From: jeff curry 
To: bug-follo...@freebsd.org
Cc: kamik...@bsdforen.de
Subject: Re: kern/144898: [wpi] [panic] wpi panics system
Date: Sun, 2 May 2010 12:45:41 -0700

 --0050450156d6b0f0cd0485a1b8cc
 Content-Type: text/plain; charset=ISO-8859-1
 
 This is happening to me as well, 8.0-release p2, amd64, 4 GB RAM, same
 motherboard chipset and graphics card ( Dell D630 ).
 
 wpi0: device timeout
 wpi0: could not set power mode
 wpi0: device config failed
 
 kldunload -> kldload panics the system often but not always. wpi0 device
 timeouts happen more often with X/gnome running. wireless will not work
 after this until a reboot ( when kldload doesn't cause kernel panics )
 
 --0050450156d6b0f0cd0485a1b8cc
 Content-Type: text/html; charset=ISO-8859-1
 Content-Transfer-Encoding: quoted-printable
 
 This is happening to me as well, 8.0-release p2, amd64, 4 GB RAM, same moth=
 erboard chipset and graphics card ( Dell D630 ).wpi0: device timeou=
 twpi0: could not set power mode
 wpi0: device config failedkldunload -> kldload panics the system=
  often but not always. wpi0 device timeouts happen more often with X/gnome =
 running. wireless will not work after this until a reboot ( when kldload do=
 esn't cause kernel panics )
 
 
 --0050450156d6b0f0cd0485a1b8cc--
___
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"

Question about "kern/125239: [gre] kernel crash when using gre"

[Jeff Mo]

Hi Sir,

I am trying to dive deeper into the stack frames of  the following bug:
kern/125239: [gre] kernel crash when using greI use FreeBSD 7.0 and already
reproduce it, but I am not sure about what the following sentence means:
"ifp=Variable "ifp" is not available"?

I will be very thankful if anyone can give me some instruction.

Regards
Jeff

==

(kgdb) f 7
#7  0xc082263b in in_ifinit (ccc.
) at /usr/src/sys/netinet/in.c:817
817 if (rtinitflags(ia)) {
(kgdb) info f
Stack level 7, frame at 0xd22f3b58:
 eip = 0xc082263b in in_ifinit (/usr/src/sys/netinet/in.c:817);
saved eip 0xc0823607
 called by frame at 0xd22f3bb8, caller of frame at 0xd22f3ad4
 source language c.
 Arglist at 0xd22f3b50, args: ifp=Variable "ifp" is not available.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Need Help!

[Jeff Mo]

Dear All ,

After I run the following commands three times,

  1 ifconfig gre0 create
  2 ifconfig gre0 tunnel 10.101.1.1 10.101.1.2 netmask 255.255.255.255
  3 ifconfig gre0 destroy

I found something weird:

   1. in /var/log/messages , line 907 , there should be TAILQ_REMOVE because
   of  ifconfig gre0 destroy, but nothing happened.
   2. when i do the command second time, ia1=0xc2df1600 supposed not be
   there.
   3. Some thing wrong with line 914,915,920,921,931,932,937,938
   4. does "ifconfig gre0 destroy" causes TAILQ_REMOVE be called?

Please nicely give me some comments.

Thanks and Regards
Jeff

/var/log/messages

first time

895 Aug 16 16:30:11 JeffMo kernel: TAILQ_INSERT_TAIL:ia=0xc2df1600
896 Aug 16 16:30:11 JeffMo kernel:
TAILQ_INSERT_TAIL:ia->ia_ifp=0xc27d6c00
897 Aug 16 16:30:11 JeffMo kernel: before TAILQ_FOREACH:ia1=0xc28e6b00
898 Aug 16 16:30:11 JeffMo kernel: before
TAILQ_FOREACH:ia1->ia_ifp=0xc2824400
899 Aug 16 16:30:11 JeffMo kernel: before TAILQ_FOREACH:ia1=0xc298ca00
900 Aug 16 16:30:11 JeffMo kernel: before
TAILQ_FOREACH:ia1->ia_ifp=0xc27d6000
901 Aug 16 16:30:11 JeffMo kernel: after TAILQ_FOREACH:ia1=0xc28e6b00
902 Aug 16 16:30:11 JeffMo kernel: after
TAILQ_FOREACH:ia1->ia_ifp=0xc2824400
903 Aug 16 16:30:11 JeffMo kernel: after TAILQ_FOREACH:ia1=0xc298ca00
904 Aug 16 16:30:11 JeffMo kernel: after
TAILQ_FOREACH:ia1->ia_ifp=0xc27d6000
905 Aug 16 16:30:11 JeffMo kernel: after TAILQ_FOREACH:ia1=0xc2df1600
906 Aug 16 16:30:11 JeffMo kernel: after
TAILQ_FOREACH:ia1->ia_ifp=0xc27d6c00
907 Aug 16 16:30:11 JeffMo kernel:

second time

908 Aug 16 16:30:34 JeffMo kernel: TAILQ_INSERT_TAIL:ia=0xc3144d00
909 Aug 16 16:30:34 JeffMo kernel:
TAILQ_INSERT_TAIL:ia->ia_ifp=0xc27d1c00
910 Aug 16 16:30:34 JeffMo kernel: before TAILQ_FOREACH:ia1=0xc28e6b00
911 Aug 16 16:30:34 JeffMo kernel: before
TAILQ_FOREACH:ia1->ia_ifp=0xc2824400
912 Aug 16 16:30:34 JeffMo kernel: before TAILQ_FOREACH:ia1=0xc298ca00
913 Aug 16 16:30:34 JeffMo kernel: before
TAILQ_FOREACH:ia1->ia_ifp=0xc27d6000
914 Aug 16 16:30:34 JeffMo kernel: before TAILQ_FOREACH:ia1=0xc2df1600
915 Aug 16 16:30:34 JeffMo kernel: before
TAILQ_FOREACH:ia1->ia_ifp=0x3e391
916 Aug 16 16:30:34 JeffMo kernel: after TAILQ_FOREACH:ia1=0xc28e6b00
917 Aug 16 16:30:34 JeffMo kernel: after
TAILQ_FOREACH:ia1->ia_ifp=0xc2824400
918 Aug 16 16:30:34 JeffMo kernel: after TAILQ_FOREACH:ia1=0xc298ca00
919 Aug 16 16:30:34 JeffMo kernel: after
TAILQ_FOREACH:ia1->ia_ifp=0xc27d6000
920 Aug 16 16:30:34 JeffMo kernel: after TAILQ_FOREACH:ia1=0xc2df1600
921 Aug 16 16:30:34 JeffMo kernel: after
TAILQ_FOREACH:ia1->ia_ifp=0x3e391
922 Aug 16 16:30:34 JeffMo kernel: after TAILQ_FOREACH:ia1=0xc3144d00
923 Aug 16 16:30:34 JeffMo kernel: after
TAILQ_FOREACH:ia1->ia_ifp=0xc27d1c00
924 Aug 16 16:30:34 JeffMo kernel:

third time

   925 Aug 16 16:30:57 JeffMo kernel: TAILQ_INSERT_TAIL:ia=0xc3145800
926 Aug 16 16:30:57 JeffMo kernel:
TAILQ_INSERT_TAIL:ia->ia_ifp=0xc2812400
927 Aug 16 16:30:57 JeffMo kernel: before TAILQ_FOREACH:ia1=0xc28e6b00
928 Aug 16 16:30:57 JeffMo kernel: before
TAILQ_FOREACH:ia1->ia_ifp=0xc2824400
929 Aug 16 16:30:57 JeffMo kernel: before TAILQ_FOREACH:ia1=0xc298ca00
930 Aug 16 16:30:57 JeffMo kernel: before
TAILQ_FOREACH:ia1->ia_ifp=0xc27d6000
931 Aug 16 16:30:57 JeffMo kernel: before TAILQ_FOREACH:ia1=0xc2df1600
932 Aug 16 16:30:57 JeffMo kernel: before TAILQ_FOREACH:ia1->ia_ifp=0
933 Aug 16 16:30:57 JeffMo kernel: after TAILQ_FOREACH:ia1=0xc28e6b00
934 Aug 16 16:30:57 JeffMo kernel: after
TAILQ_FOREACH:ia1->ia_ifp=0xc2824400
935 Aug 16 16:30:57 JeffMo kernel: after TAILQ_FOREACH:ia1=0xc298ca00
936 Aug 16 16:30:57 JeffMo kernel: after
TAILQ_FOREACH:ia1->ia_ifp=0xc27d6000
937 Aug 16 16:30:57 JeffMo kernel: after TAILQ_FOREACH:ia1=0xc2df1600
938 Aug 16 16:30:57 JeffMo kernel: after TAILQ_FOREACH:ia1->ia_ifp=0

#diff -uw in.c.ori in.c

--- in.c.ori2008-08-16 13:50:54.0 +
+++ in.c2008-08-16 16:43:29.0 +
@@ -320,7 +320,23 @@
 ia->ia_broadaddr.sin_family = AF_INET;
 }
 ia->ia_ifp = ifp;
+//add by jeff:start
+ printf("TAILQ_INSERT_TAIL:ia=%p\n" , ia);
+printf("TAILQ_INSERT_TAIL:ia->ia_ifp=%p\n" , ia->ia_ifp);
+struct in_ifaddr *ia1;
+TAILQ_FOREACH(ia1, &in_ifaddrhead, ia_link) {
+ printf("before TAILQ_FOREACH:ia1=%p\n" , ia1);
+ printf("before TAILQ_FOREACH:ia1->ia_ifp=%p\n" ,
ia1->ia_ifp);
+}
+//add by jeff:end
 TAILQ_INSERT_TAIL(&in_ifaddrhead, ia, ia_link);
+//add by 

Re: kern/127050: [carp] ipv6 does not work on carp interfaces [regression]

[Jeff Wheelhouse]

The following reply was made to PR kern/127050; it has been noted by GNATS.

From: Jeff Wheelhouse <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Cc:  
Subject: Re: kern/127050: [carp] ipv6 does not work on carp interfaces 
[regression]
Date: Wed, 10 Sep 2008 15:02:00 -0400

 I am experiencing the identical behavior on the following releases:
 
 6.3-RELEASE-p4
 6.4-PRERELEASE (as of Sep 6)
 
 I have reproduced the problem on both amd64 and i386, on both physical  
 interfaces and VLAN interfaces.
 
 The problem is the same:
 - two machines,  both configured correctly
 - both machines can ping6 each other
 - carp configures correctly, and announcements are observed on the  
 relevant LAN via tcpdump
 - one machine goes to MASTER and one goes to BACKUP
 - an additional machine on the same LAN can ping6 both machines
 - none of the three machines can ping (or route through) the CARP IPv6  
 address
 
 However, I'm *assuming* these are the CARP announcements (since they  
 are from the right IPv6 addresses and MASTER/BACKUP status seems to  
 work:
 
 11:54:51.818511 IP6 A:B:C:D::1 > ff02::12: ip-proto-112 36
 11:54:52.855924 IP6 A:B:C:D::1 > ff02::12: ip-proto-112 36
 11:54:53.893300 IP6 A:B:C:D::1 > ff02::12: ip-proto-112 36
 11:54:54.930386 IP6 A:B:C:D::1 > ff02::12: ip-proto-112 36
 11:54:55.967965 IP6 A:B:C:D::1 > ff02::12: ip-proto-112 36
 11:54:57.004987 IP6 A:B:C:D::1 > ff02::12: ip-proto-112 36
 11:54:58.042481 IP6 A:B:C:D::1 > ff02::12: ip-proto-112 36
 
 I would be happy to help troubleshoot this problem in any way possible.
 
 Thanks,
 Jeff
 
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

mbuf revision, testers/comments wanted.

[Jeff Roberson]

http://people.freebsd.org/~jeff/mbuf_ref2.diff

Hello,

I have been experimenting with different revisions to the mbuf api to 
improve performance and simplify code.  This patch is the first of several 
proposed steps towards those goals.  The aim of this patch is two fold;


1)  Revising the reference counting system so that we can eliminate 
reference uma zones and the significant uma_find_refcnt() costs in some 
workloads.  This is done by making all mbufs reference counted and using 
the owning mbuf's ref for the ext_ref.  In this model we never reference 
data, we only reference other mbufs owning the data.


2)  Improve allocation and free performance by reducing the special cases 
in the format and using inlines when appropriate.  In particular, the 
simplification of the m_ext structure yields less code and confusion for 
dealing with external storage on free.  The ctor/dtor mbuf routines are no 
longer used.  A zone pointer and length was added to struct mbuf to 
simplify free and size calculations.


A number of routines were made much, much simpler by the addition of a 
16bit size field.  Previously we dependend on calculating the size by 
figuring out if it was an ext, pkthdr, or standard mbuf.  Ultimately, this 
patch moves us closer to having a size agnostic mbuf which we can use to 
experiment with different allocation sizes or even backending to malloc 
for dynamically sized mbufs.


I would appreciate testing feedback from varied workloads to make sure 
there are no bugs before I go forward with this.  I have tested only host 
oriented networking with a few drivers.  It is not anticipated that there 
will be any significant incompatibilities introduced with this round but 
there is always that possibility.


Thanks,
Jeff
___
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: mbuf revision, testers/comments wanted.

[Jeff Roberson]

On Sun, 1 Feb 2009, Fabian Keil wrote:


Fabian Keil  wrote:


Jeff Roberson  wrote:


http://people.freebsd.org/~jeff/mbuf_ref2.diff



I have been experimenting with different revisions to the mbuf api to
improve performance and simplify code.  This patch is the first of
several proposed steps towards those goals.  The aim of this patch is
two fold;



I would appreciate testing feedback from varied workloads to make sure
there are no bugs before I go forward with this.  I have tested only
host oriented networking with a few drivers.  It is not anticipated
that there will be any significant incompatibilities introduced with
this round but there is always that possibility.



5)
Finally, I tested the patch on an IBM ThinPad R51. The kernel
hangs on boot, the last messages are (hand transcribed):

iwi0:  mem 0xc0214000-0xc0214fff irq 11 at device 
2.0 on pci2
iwi0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xc0214000
iwi0: could not allocate rx mbuf
iwi0: could not allocate Rx ring
bpfdetach: was not attached


Never mind, kernel and user land weren't completely in
sync and this might be related to the recent wlan commits.
I'll retry with an up-to-date user land.



Thank you for your feedback.  I'll add your style suggestions to my patch. 
As it turns out I hadn't tested recently without INVARIANTS enabled.  I 
seem to have a bug related to that.  I'll post a new patch soon.


Thanks,
Jeff


Fabian


___
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: mbuf revision, testers/comments wanted.

[Jeff Roberson]

On Sun, 1 Feb 2009, Fabian Keil wrote:


Fabian Keil  wrote:


Jeff Roberson  wrote:


http://people.freebsd.org/~jeff/mbuf_ref2.diff



I have been experimenting with different revisions to the mbuf api to
improve performance and simplify code.  This patch is the first of
several proposed steps towards those goals.  The aim of this patch is
two fold;



I would appreciate testing feedback from varied workloads to make sure
there are no bugs before I go forward with this.  I have tested only
host oriented networking with a few drivers.  It is not anticipated
that there will be any significant incompatibilities introduced with
this round but there is always that possibility.



5)
Finally, I tested the patch on an IBM ThinPad R51. The kernel
hangs on boot, the last messages are (hand transcribed):

iwi0:  mem 0xc0214000-0xc0214fff irq 11 at device 
2.0 on pci2
iwi0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xc0214000
iwi0: could not allocate rx mbuf
iwi0: could not allocate Rx ring
bpfdetach: was not attached


Never mind, kernel and user land weren't completely in
sync and this might be related to the recent wlan commits.
I'll retry with an up-to-date user land.



I have updated the patch here:

http://people.freebsd.org/~jeff/mbuf_ref2.diff

This resolves the !INVARIANTS bug and improves the style as you suggested.

Thanks,
Jeff


Fabian


___
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: mbuf revision, testers/comments wanted.

[Jeff Roberson]

On Sun, 1 Feb 2009, Julian Elischer wrote:


Jeff Roberson wrote:

http://people.freebsd.org/~jeff/mbuf_ref2.diff

Hello,

I have been experimenting with different revisions to the mbuf api to 
improve performance and simplify code.  This patch is the first of several 
proposed steps towards those goals.  The aim of this patch is two fold;


1)  Revising the reference counting system so that we can eliminate 
reference uma zones and the significant uma_find_refcnt() costs in some 
workloads.  This is done by making all mbufs reference counted and using 
the owning mbuf's ref for the ext_ref.  In this model we never reference 
data, we only reference other mbufs owning the data.


2)  Improve allocation and free performance by reducing the special cases 
in the format and using inlines when appropriate.  In particular, the 
simplification of the m_ext structure yields less code and confusion for 
dealing with external storage on free.  The ctor/dtor mbuf routines are no 
longer used.  A zone pointer and length was added to struct mbuf to 
simplify free and size calculations.


A number of routines were made much, much simpler by the addition of a 
16bit size field.  Previously we dependend on calculating the size by 
figuring out if it was an ext, pkthdr, or standard mbuf.  Ultimately, this 
patch moves us closer to having a size agnostic mbuf which we can use to 
experiment with different allocation sizes or even backending to malloc for 
dynamically sized mbufs.


I would appreciate testing feedback from varied workloads to make sure 
there are no bugs before I go forward with this.  I have tested only host 
oriented networking with a few drivers.  It is not anticipated that there 
will be any significant incompatibilities introduced with this round but 
there is always that possibility.





generally I like it.

We discussed someof this before..


It would be nice if you added more comments than you stripped out
I personally think that some descriptions of what you are doing
would be great in teh comments.


Yes, I can do that.  I hadn't added as much because things are still a bit 
in flux.




ascii art too if needed...

Also some diagrams in any form you want would be nice..
all that about 1000 words and a picture is true.


I'll have to see about that.  Any suggestions similar to visio for unix? 
I guess graphviz can also do datastructure diagrams but I have not used it 
for this before.  I'll check it out but if you have other suggestions it's 
welcome.


Thanks,
Jeff




Thanks,
Jeff
___
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"



___
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: mbuf revision, testers/comments wanted.

[Jeff Roberson]

On Sun, 8 Feb 2009, Fabian Keil wrote:


Jeff Roberson  wrote:


On Sun, 1 Feb 2009, Fabian Keil wrote:


Fabian Keil  wrote:


Jeff Roberson  wrote:


http://people.freebsd.org/~jeff/mbuf_ref2.diff



I have been experimenting with different revisions to the mbuf api to
improve performance and simplify code.  This patch is the first of
several proposed steps towards those goals.  The aim of this patch is
two fold;



I would appreciate testing feedback from varied workloads to make sure
there are no bugs before I go forward with this.  I have tested only
host oriented networking with a few drivers.  It is not anticipated
that there will be any significant incompatibilities introduced with
this round but there is always that possibility.



5)
Finally, I tested the patch on an IBM ThinPad R51. The kernel
hangs on boot, the last messages are (hand transcribed):

iwi0:  mem 0xc0214000-0xc0214fff irq 11 at device 
2.0 on pci2
iwi0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xc0214000
iwi0: could not allocate rx mbuf
iwi0: could not allocate Rx ring
bpfdetach: was not attached


Never mind, kernel and user land weren't completely in
sync and this might be related to the recent wlan commits.
I'll retry with an up-to-date user land.



I have updated the patch here:

http://people.freebsd.org/~jeff/mbuf_ref2.diff

This resolves the !INVARIANTS bug and improves the style as you suggested.


I run into several system hangs (or maybe panics) yesterday,
mostly with Xorg running so I didn't get any details.

I got one on the console though. After running a regression
test that opens multiple HTTP connections to the loop back
device, I used rsync to restore some files that were damaged by
an earlier hang. That lead to a page fault in em_start_locked().

While I dumped core from the debugger,
savecore didn't find the dump afterwards.

Anyway, there's a screen shot available at:
http://www.fabiankeil.de/bilder/freebsd/mbuf-patch-page-fault-em_start_locked.jpg


Can you open gdb on kernel.debug and tell me what:

list *(em_start_locked+0x1e5)

outputs?

Thanks,
Jeff



Before the patch I didn't see any surprising panics
in quite a while. I reverted the patch for now to
verify that the system is stable without it.

Fabian


___
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"

mbuf layout optimizations

[Jeff Roberson]

http://people.freebsd.org/~jeff/mbuf2.diff

Hello,

This is a call for testers and feedback on my mbuf layout improvements. 
I'm trying to decide whether I will push to have these included in 8.0. 
After reducing the scope slightly from my last patch, I have not 
encountered any problems.  Kip Macy has also been using it for the past 
few weeks without issue.


You should not expect any functional changes from this patch.  The goal 
is mostly to pave the way fors more sensible mbuf handling in the future, 
although it does offer a few performance benefits.


The only issue is that cxgb support requires another set of patches from 
Kip.  If anyone needs those I will prod him to reply with that diff.


Thanks,
Jeff
___
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: mbuf layout optimizations

[Jeff Roberson]

On Fri, 19 Jun 2009, Barney Cordoba wrote:





--- On Fri, 6/19/09, Jeff Roberson  wrote:


From: Jeff Roberson 
Subject: mbuf layout optimizations
To: n...@freebsd.org, curr...@freebsd.org
Date: Friday, June 19, 2009, 5:12 AM
http://people.freebsd.org/~jeff/mbuf2.diff

Hello,

This is a call for testers and feedback on my mbuf layout
improvements. I'm trying to decide whether I will push to
have these included in 8.0. After reducing the scope
slightly from my last patch, I have not encountered any
problems.  Kip Macy has also been using it for the past
few weeks without issue.

You should not expect any functional changes from this
patch.  The goal is mostly to pave the way fors more
sensible mbuf handling in the future, although it does offer
a few performance benefits.

The only issue is that cxgb support requires another set of
patches from Kip.  If anyone needs those I will prod
him to reply with that diff.

Thanks,
Jeff


I thought that the purpose of m_tags was to keep individual applications from having to 
"patch" mbufs. Has that idea proven to be too
performance-challenged?


m_tags are unrelated to this diff.  This addresses the fundamental memory 
allocation mechanisms and layout of the mbuf.  It reduces the amount of 
book keeping necessary and makes reference counts more pervasive.


Thanks,
Jeff



Barney
___
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: GPL issues around OFED code in FreeBSD 9.1

[Jeff Meegan]

According to their EULA, it is BSD licensed.

http://www.mellanox.com/page/mlnx_ofed_eula?mtag=linux_sw_drivers 


—j

> On Sep 3, 2015, at 1:07 PM, Jack Vogel  wrote:
> 
> We (meaning Intel when I was still there) raised this issue with George a
> long time ago, I'm not sure
> what the resolution was.
> 
> If Mellanox is the owner then they should have released the code somewhere
> without any
> GPL license in it, as Intel does with code they multi-license.
> 
> Jack
> 
> 
> On Thu, Sep 3, 2015 at 12:07 PM, K. Macy  wrote:
> 
>> On Sep 3, 2015 10:33 AM, "Vijay Singh"  wrote:
>>> 
>>> Someone told me that once the OFED code hit kernel.org the GPL is the
>> only
>>> license that applies. Does anyone have insights about that?
>> 
>> That sounds bizarre since mellanox wrote the code and explicitly dual
>> licensed.
>> 
>> The problem you *do* run in to is code creep. The Linux internal interfaces
>> are almost certainly totally undocumented, so a clean room reimplementation
>> as they change or bugs get fixed - changing behaviors - is not possible.
>> Over time the tendency is to copy and paste from Linux to OFED or the shim
>> layer creating real ambiguity about provenance. In practice it's not so
>> much of a problem because Linus tends to adhere to an interpretation of the
>> GPLv2 that is not vendor unfriendly the way some of his lieutenants would
>> prefer (see Greg's efforts to call closed source drivers derived works).
>> 
>> Nonetheless, if you're paranoid an audit is in order.
>> 
>> Cheers.
>> 
>>> 
>>> On Mon, Aug 31, 2015 at 10:25 AM, Garrett Cooper 
>>> wrote:
>>> 
 
> On Aug 31, 2015, at 09:34, Hrishikesh Keremane via freebsd-hackers <
 freebsd-hack...@freebsd.org> wrote:
> 
> [Sorry for cross posting]
> 
> Hi,
> 
> We are working on a product(FreeBSD based) that would require RDMA
>> over
 iWARP and are considering using the OFED stack in FreeBSD 9.1.
> We will be making some changes to the OFED stack to customize it to
>> our
 requirements.
> 
> The concern is regarding the implications of GPL licensing of OFED on
 our code base.
> Has anyone worked with OFED in FreeBSD and/or is aware of the
>> licensing
 issues around it?
> 
> Thanks in advance for your help.
> 
> Please include me in your replies as I am not subscribed to these
>> lists.
 
 The OFED stack is BSD/GPLv2 dual licensed IIRC. the Mellanox import
>> might
 have made it 100% BSD licensed though.
 
 There's freebsd-infinib...@freebsd.org as well. It's a low traffic
>> list,
 but it might hit a better target audience in the future.
 
 Cheers,
 -NGie
 ___
 freebsd-net@freebsd.org mailing list
 https://lists.freebsd.org/mailman/listinfo/freebsd-net
 To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
 
>>> ___
>>> freebsd-hack...@freebsd.org mailing list
>>> https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
>>> To unsubscribe, send any mail to "
>> freebsd-hackers-unsubscr...@freebsd.org"
>> ___
>> freebsd-net@freebsd.org mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-net
>> To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
>> 
> ___
> freebsd-net@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

netgraph snooping failing using tcpdump with ng_tee and ng_eiface

[Jeff Kletsky]

I'm in the process of trying to debug a deeper question with netgraph,
but am puzzled as to why I can't seem to use tcpdump with ng_tee and
ng_eiface. I don't see any packets with tcpdump on either the ng_eiface
connected to ng_tee left2right or to ng_tee right2left when there are
packets flowing through the ng_tee.

TL;DR
I can't see packets using tcpdump on ng_eiface connected to ng_tee

The configuration can be seen in detail with a graphic from ncgtl dot:
<http://wildside.wagsky.com/freebsd/ngctl/ngctl.testjail_tapped.png>

In summary:

re0 (ether) --\
 ||
re0_tee_upperre0_tee_lower
 ||
re0_bridge ---/
 |
ng0_testjail_tee
 |
ng0_testjail (eiface, passed to a vnet-enabled jail)

The jail can clearly communicate through ng0_testjail to the outside
world (physically connected to re0)

(ifconfig and netstat -rn for host and jail at the bottom of this message)

I've added ng_eiface nodes to all the left2right and right2left tees:

+ mkpeer ng0_testjail_tee: eiface left2right ether
+ mkpeer ng0_testjail_tee: eiface right2left ether
+ mkpeer re0_tee_lower: eiface left2right ether
+ mkpeer re0_tee_lower: eiface right2left ether
+ mkpeer re0_tee_upper: eiface left2right ether
+ mkpeer re0_tee_upper: eiface right2left ether

If I run 'tcpdump -i ngeth1' on the host (left2right tap on ng_tee
between the jail's VNET ng_eiface and the ng_bridge), I can see it is
put into promiscuous mode:

ngeth1: flags=8902 metric 0 mtu 1500
options=28
ether 00:00:00:00:00:00
nd6 options=29
media: Ethernet autoselect (1000baseT )
status: active

If I make a connection to the outside world from inside the jail, I
would expect the packets to flow through
  ng0_testjail (eiface in jail)
  ng0_testjail_tee
  re0_bridge
  re0_tee_lower or re0_tee_upper
  re0
and back again.

Based on this, I would expect there to be packets copied to the taps
of the ng0_testjail_tee and then to the ng_eiface tap attached to the 
ng_tee.


However, I don't see anything with tcpdump on the ng_eiface tap.

What am I missing here in being able to "snoop" the traffic within my
virtual netgraph network?

Are the packets somehow bypassing the virtual network and being routed
directly to re0?



TIA,

Jeff







Host:
-

re0: flags=8943 metric 0 
mtu 1500

 
options=8209b
ether d0:50:99:51:38:eb
inet 192.168.6.13 netmask 0xff00 broadcast 192.168.6.255
nd6 options=29
media: Ethernet autoselect (1000baseT )
status: active


Routing tables

Internet:
DestinationGatewayFlags  Netif Expire
default192.168.6.1UGS re0
127.0.0.1  link#2 UH  lo0
192.168.6.0/24 link#1 U   re0
192.168.6.13   link#1 UHS lo0


VNET jail:
--

ng0_testjail: flags=8843 metric 
0 mtu 1500

options=28
ether 02:00:28:51:38:eb
inet 192.168.6.213 netmask 0xff00 broadcast 192.168.6.255
nd6 options=29
media: Ethernet autoselect (1000baseT )
status: active


Routing tables

Internet:
DestinationGatewayFlags  Netif Expire
default192.168.6.1UGSng0_test
127.0.0.1  link#1 UH  lo0
192.168.6.0/24 link#2 U  ng0_test
192.168.6.213  link#2 UHS lo0

arp -a:

wildside.pn.wagsky.com (192.168.6.1) at 68:05:ca:34:34:7f on 
ng0_testjail expires in 966 seconds [ethernet]

? (192.168.6.213) at 02:00:28:51:38:eb on ng0_testjail permanent [ethernet]


___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

netncp/netsmb users please test a patch.

[Jeff Roberson]

http://people.freebsd.org/~jeff/select.diff

I have redone the select locking.  This included changing some cruft in 
smb/ncp.  I have tested smb myself, but would appreciate more feedback.  I 
am not able to test ncp.  Please let me know if this works for you.


Thanks,
Jeff
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

RE: %cpu in system - squid performance in FreeBSD 5.3

[Jeff Behl]

 
As a follow up to the below (original message at the very bottom), I
installed a load balancer in front of the machines which terminates the
tcp connections from clients and opens up a few, persistent connections
to each server over which requests are pipelined.  In this scenario
everything is copasetic:

last pid:  3377;  load averages:  0.12,  0.09,  0.08
up 0+17:24:53  10:02:13
31 processes:  1 running, 30 sleeping
CPU states:  5.1% user,  0.0% nice,  1.8% system,  1.2% interrupt, 92.0%
idle
Mem: 75M Active, 187M Inact, 168M Wired, 40K Cache, 214M Buf, 1482M Free
Swap: 4069M Total, 4069M Free

  PID USERNAME PRI NICE   SIZERES STATE  C   TIME   WCPUCPU
COMMAND
  474 squid 960 68276K 62480K select 0  53:38 16.80% 16.80%
squid
  311 bind  200 10628K  6016K kserel 0  12:28  0.00%  0.00%
named



It's actually so good that one machine can now handle all traffic
(around 180 Mb/s) at < %50 cpu utilization.  Seems like something in the
network stack is responsible for the high %system cpu util...

jeff


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Jeff Behl
Sent: Tuesday, December 07, 2004 9:17 AM
To: Sean Chittenden
Cc: [EMAIL PROTECTED]
Subject: Re: %cpu in system - squid performance in FreeBSD 5.3

I upgraded to STABLE but  most cpu time is still being spent in system.

This system is doing ~20Mb/s total with all content being grabbed out of
memory.  I see similar results when running MySQL (a lot of time being
spent in system)

Any ideas on what updates to be on the lookout for that might help with
this?  Am I right in guessing that this is a SMP issue and doesn't have
anything to do with AMD architecture?

thx



FreeBSD www2 5.3-STABLE FreeBSD 5.3-STABLE #2: Sun Dec  5 21:06:14 PST 
2004 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/SMP  amd64


last pid: 15702;  load averages:  0.15,  0.31,  0.31up 
0+19:55:14  09:09:28
38 processes:  2 running, 36 sleeping
CPU states:  5.4% user,  0.0% nice, 12.7% system,  3.4% interrupt, 78.4%
idle
Mem: 163M Active, 284M Inact, 193M Wired, 72K Cache, 214M Buf, 1245M
Free
Swap: 4069M Total, 4069M Free

  PID USERNAME PRI NICE   SIZERES STATE  C   TIME   WCPUCPU
COMMAND
  486 squid 960 79820K 73996K CPU1   1 110:00 15.04% 15.04%
squid
  480 squid 960 75804K 70012K select 0 105:56 14.89% 14.89%
squid





Sean Chittenden wrote:

>> but the % system time can fluctuate up to 60 at times.  My question 
>> is if this is about the type of performance I could expect, or if 
>> people have seen better.
>
>
> I don't know about other people, but I suspect you're running into 
> lock contention.  Try using a post 5.3 snapshot (something from
> RELENG_5) since alc@ has set debug.mpsafevm=1, which lets many calls 
> to the VM run without GIANT, which I suspect is your problem and why 
> the system usage is all over the place.  -sc
>

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
To unsubscribe, send any mail to
"[EMAIL PROTECTED]"



howdy,

I've got a dual proc AMD64 (2gHz) FreeBSD 5.3R system running two squid
processes (to take advantage of both CPUs). Each process is doing
around 195 req/s, and the total bandwidth is ~40Mb/s (gig nic via bge
driver). Squid is being used exclusively as a reverse proxy, with all
content being served out of memory (very little disk activity).

Top shows:

CPU states: 16.0% user, 0.0% nice, 42.7% system, 7.6% interrupt, 33.6%
idle
Mem: 898M Active, 569M Inact, 179M Wired, 214M Buf, 171M Free
Swap: 4069M Total, 4069M Free

PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU CPU COMMAND
14598 squid 108 0 463M 459M select 0 39.2H 59.96% 59.96% squid
14605 squid 105 0 421M 416M CPU0 1 38.4H 49.95% 49.95% squid

but the % system time can fluctuate up to 60 at times. My question is
if this is about the type of performance I could expect, or if people
have seen better. I was expecting to see much better performance,
seeing how everything is being served out of memory, but maybe I'm
asking too much? 400 reqs/s from RAM doesn't seem like much. Is this a
FreeBSD issue (anybody else with similar experience)? A majority of the
cpu time being spent in system would seem to indictate such. What is
all the system load? How can i tell?

Any help/pointers/remarks appreciated

thanks,
jeff
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: %cpu in system - squid performance in FreeBSD 5.3

[Jeff Behl]

Yes, I believe the kqueue version of squid would show much better 
results.  Unfortunately it fails to compile and I have yet the time to 
try mucking with it more.  I'll get back to the list when I am able to 
get it up and running...

jeff
Mohan Srinivasan wrote:
Following up to a mail from Jeff Behl and Sean Chittenden back in Dec.
http://lists.freebsd.org/pipermail/freebsd-net/2004-December/006074.html
From your description, it looks like moving a kqueue based Squid will 
help considerably (it looks like there is a version of Squid that
is kqueue based - not sure how stable that is though). If you drop a quick 
kernel profile, you will see most of the system CPU being spent in select() 
caused polling of descriptors. In my previous experience with a Squid-based 
proxy several years ago, once you dropped more than a couple of hundred 
connections into select(), CPU utilization spiked sharply because of 
the descriptor polling.

We then hoisted Squid on top of a (homebrew) version of kqueue, which 
caused system CPU to drop dramatically, because all the descriptor polling
was avoided.

mohan
 

___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: IPMI doesn't work...

[Jeff Behl]

Julian Elischer wrote:

Jeff wrote:


 

I'm not sure what you mean by in band.  The IP address of the BMC is 
assigned via the bios and is different from what the OS later 
assigns.  With imiptool we can turn on/powercycle/monitor via the BMC 
assigned address up until the point where the kernel loads.  Once it 
does, the BMC no longer responds.  This doesn't happen with the two 
linux distros we've tried it on.  Wtih both, including SuSE, we can 
still query/control via the BMC using ipmitool.  It seems to be some 
sort of driver issue to me.  I find it confusing that the NIC is 
shared between the BMC and the OS, but I guess that's just how it's 
done.  Perhaps the bsd broadcomm driver is simply blocking this 
somehow...

you have to assign it the same address!
that's not the way it's supposed to work, afaik.  it'd be silly to tie 
the BMC address and the OS assigned address together.  you give the BMC 
an ip address via a little program that comes from IBM and this address 
is independent of the ip address that whatever os you use on the system 
assigns to the nic.  the redbook that Jung-uk sent a link for shows this 
process if you're interested.

like i said earlier, having different ip addresses (the BMC's being in 
private address space) works fine with the linux kernel...

___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: IPMI doesn't work...

[Jeff Behl]

Michael Vince wrote:
Just out of interest has any one got serial console to work with this 
IPMI stuff?
I was looking at regular 9pin serial alternatives since Dell machines 
normally only have 1 serial port and I prefer 2.
yep, we've gotten this to work, but again only with linux.  it looks 
just like you're seeing it over the serial port...pretty click.  i'm 
sure it'd work with bsd just as well if we could get to the bmc after 
the kernel loads...
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: IPMI doesn't work...

[Jeff Behl]

Julian Elischer wrote:

Jung-uk Kim wrote:
On Tuesday 15 March 2005 01:14 am, Jeff Behl wrote:
 

Julian Elischer wrote:
  

Jeff wrote:


I'm not sure what you mean by in band.  The IP address of the
BMC is assigned via the bios and is different from what the OS
later assigns.  With imiptool we can turn on/powercycle/monitor
via the BMC assigned address up until the point where the kernel
loads.  Once it does, the BMC no longer responds.  This doesn't
happen with the two linux distros we've tried it on.  Wtih both,
including SuSE, we can still query/control via the BMC using
ipmitool.  It seems to be some sort of driver issue to me.  I
find it confusing that the NIC is shared between the BMC and the
OS, but I guess that's just how it's done.  Perhaps the bsd
broadcomm driver is simply blocking this somehow...
  
you have to assign it the same address!

that's not the way it's supposed to work, afaik.  it'd be silly to
tie the BMC address and the OS assigned address together.  you give
the BMC an ip address via a little program that comes from IBM and
this address is independent of the ip address that whatever os you
use on the system assigns to the nic.  the redbook that Jung-uk
sent a link for shows this process if you're interested.
  

I believe you are correct.  If you have the same IP address, the 
packet reaches host OS and (I think) it must be discarded by OS.  
IPMI spec. is very verbose but I found very simple explanation here:
 

I simply have a firewall rule throwing those away.
We have a Class -C full of those machines and if I had to duplicate 
the addresses I'd need 2.

we've been assigning private addresses to the BMCs making them only 
reachable via a local admin host...
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Looking for networking solution.

[Jeff Meegan]

> Hi guys.
> 
> Thanks for the help and good advices.
> I just received source code from guys at MITRE in McLean, VA for
FreeBSD and will do some testing on it.
> "The code is an open implementation of ISO International Standards and
it's yours for the asking; there is no licensing."
> 
> I was thinking, maybe someone would be interested in implementing it
into FreeBSD's and/or NetBSD's source tree since the code is avaliable
for both the BSD's?
> 
> 

Hello Marcin,

   The code from Mitre is a reference implementation that was written
quite a while ago.  It has not kept up with improvements in hardware 
and makes some poor assumptions about the underlying system.  It could
use some update, but I do not know the correct path to get these 
committed anywhere.  In any case, if I recall correctly, it is 
entirely in user space, and may be best tracked in the ports collection.

Jeff

___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

ipfw -- selecting locally generated packets

[Jeff Kletsky]

From time to time, I rewrite my firewall rules to take advantages of 
the ever-improving set of features that ipfw provides. One of the 
challenges I have faced in the past was selecting packets that are 
generated on the firewall host itself, as opposed to those that it 
received through an interface.


While I find most of the Linux firewall implementations untenable for a 
variety of reasons, it does provide differentiation between what they 
call "OUTPUT" and "FORWARD". I'm looking to see if there is a "better" 
way to implement this kind of selection with the 11.1 version of ipfw.


"out and not in" may years ago seemed an obvious selector, and it's good 
to see that it is now clearly documented that it doesn't work in "man 
ipfw" with "(in fact, out is implemented as not in)".


"not recv any" doesn't seem to be helpful either

    $ sudo ipfw add 64000 count ip from any to any out xmit any not 
recv any

    64000 count ip from any to any out

In the past, I've tagged all incoming packets and used that tag to 
differentiate between the two.


Is there something "cleaner" (or perhaps clearer) that using a tag in 
that way?



TIA,

Jeff



___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: ipfw -- selecting locally generated packets

[Jeff Kletsky]

On 5/3/18 6:35 AM, Julian Elischer wrote:

On 3/5/18 12:08 am, Michael Sierchio wrote:
On Mon, Apr 30, 2018 at 10:48 AM, Jeff Kletsky  
wrote:



"not recv any" doesn't seem to be helpful either

 $ sudo ipfw add 64000 count ip from any to any out xmit any not 
recv

any


The loopback interface, lo0 ?
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"


As was pointed out a selector might be

add 100 ip from me to any out not recv *

one wonders if that would work or maybe

skipto {line x) any from any to any out recv *

followed by lines htat are for locally generated.

these not tested..


Looks like

 [not] recv *

is going to work.

Part of my refactor is to do "dispatch" with call/skipto (as Julian 
Elischer noted above), so the potential inefficiencies of what I'm 
guessing is a string glob only happen "once" per packet (per pass), 
rather than on dozens of rules. Rule 16, below, could probably skip the 
test, but for the likely tiny performance impact, readability and 
maintainability have me leaving it in.



I took a *quick* look on a "live" routing system (standard ipfw points; 
no bridging, no ether) with


sudo ipfw add 13 set 5 drop all from any to any via ng*    # Kill packet 
clones
sudo ipfw add 14 set 5 ngtee 100 ip4 from any to any in    # incoming 
packets
sudo ipfw add 15 set 5 ngtee 200 ip4 from any to any out recv \* # 
forwarded packets
sudo ipfw add 16 set 5 ngtee 300 ip4 from any to any out not recv \*    
# locally generated packets


$ sudo ngctl

mkpeer ipfw: iface 100 inet
mkpeer ipfw: iface 200 inet
mkpeer ipfw: iface 300 inet

and bringing up those new interfaces and using tcpdump.

Took a brief bit to figure out how to get around the lack of link-level 
headers on ng_ipfw output for tcpdump (documented in ng_tag, of all 
places) as "mkpeer ipfw: eiface NNN ether" and "tcpdump -ni ngX" doesn't 
know what to make of things.


It feels like something of a hack-ish approach using ng_iface to wrap 
the "bare" packet with a link-level header, especially as it appears to 
be injecting a second copy of the packet into the stack (hence rule 13, 
above). Figuring out a "better" way to "monitor" packet flow through 
ipfw may be on my list in the future, but that was sufficient to let me 
go ahead with further config/test.



Thanks for all the help!

After so many years with FreeBSD and ipfw, eyes with a different 
perspective can reveal new tricks to this old dog.


Jeff




___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

In-kernel NAT [ipfw] dropping large UDP return packets

[Jeff Kletsky]

When a T-Mobile "femto-cell" is trying to establish its IPv4, IPSEC 
tunnel to the T-Mobile provisioning servers, the reassembled, 4640-byte 
return packet is silently dropped by the in-kernel NAT, even though it 
"matches" the outbound packet from less than 100 ms prior.


All other operations of the firewall seem to be functioning as expected. 
This includes iPhones using "WiFi Calling" which utilizes similar IPSEC 
connections to T-Mobile servers (though fragmentation has not been seen 
on those connections). The connection for the femto-cell can be handled 
by a Linux/netfilter NAT. Proper reassembly of the packet fragments 
within the firewall ("reass ip from any to any"), at the start of the 
rule set, prior to NAT, has been confirmed with ngtee and wireshark.



Is there a known issue with large packets and in-kernel NAT?


The only sysctl that I found that seemed related was the UDP timeout. 
For good measure I upped it to 30 (seconds), but that did not change the 
behavior.



Are there known causes and/or resolutions for this behavior?


Is there a way to be able to "monitor" the NAT table?

(I didn't see anything obvious in the ipfw, natd, or libalias man pages.)


Thanks!

Jeff


11.1-RELEASE-p9 FreeBSD 11.1-RELEASE-p9 #0: Tue Apr  3 16:59:16 UTC 2018 
r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64


Additional details at 
https://forums.freebsd.org/threads/in-kernel-nat-dropping-large-udp-return-packets.66262/


pcapng files and ipfw rule set available on request to freebsd {a} 
wagsky {.} com




___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: In-kernel NAT [ipfw] dropping large UDP return packets

[Jeff Kletsky]

On 6/13/18 10:22 AM, Michael Sierchio wrote:


On Wed, Jun 13, 2018 at 10:16 AM, Jeff Kletsky  wrote:

When a T-Mobile "femto-cell" is trying to establish its IPv4, IPSEC tunnel

to the T-Mobile provisioning servers, the reassembled, 4640-byte return
packet is silently dropped by the in-kernel NAT, even though it "matches"
the outbound packet from less than 100 ms prior.



Do you have a 'reass' rule before applying nat on inbound traffic?

- M

Yes, at the start of the rule set.

Reassembly confirmed to be working by wireshark examination of the ngtee 
"taps" shown


$ sudo ipfw list
1 deny ip from any to any recv ng*
4 ngtee 100 ip from any to any proto udp dst-port 500,4500 in
4 ngtee 100 ip from any to any proto udp frag in
4 ngtee 110 ip from any to any proto udp dst-port 500,4500 out
4 ngtee 110 ip from any to any proto udp frag out
5 reass ip from any to any
6 ngtee 101 ip from any to any proto udp dst-port 500,4500 in // 
reassembled in
6 ngtee 101 ip from any to any proto udp frag in // never should be 
frags after reass
6 ngtee 111 ip from any to any proto udp dst-port 500,4500 out // 
reass out
6 ngtee 111 ip from any to any proto udp frag out // never should be 
frage after reass

[...]

___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: In-kernel NAT [ipfw] dropping large UDP return packets

[Jeff Kletsky]

On 6/13/18 12:01 PM, Andrey V. Elsukov wrote:


On 13.06.2018 20:16, Jeff Kletsky wrote:

When a T-Mobile "femto-cell" is trying to establish its IPv4, IPSEC
tunnel to the T-Mobile provisioning servers, the reassembled, 4640-byte
return packet is silently dropped by the in-kernel NAT, even though it
"matches" the outbound packet from less than 100 ms prior.
Are there known causes and/or resolutions for this behavior?

Is there a way to be able to "monitor" the NAT table?

(I didn't see anything obvious in the ipfw, natd, or libalias man pages.)

The kernel version of libalias uses m_megapullup() function to make
single contiguous buffer. m_megapullup() uses m_get2() function to
allocate mbuf of appropriate size. If size of packet greater than 4k it
will fail. So, if you use MTU greater than 4k or if after fragments
reassembly you get a packet with length greater than 4k, ipfw_nat()
function will drop this packet.


Thanks!!

Mystery solved...

/usr/src/sys/netinet/libalias/alias.c

#ifdef _KERNEL
/*
 * m_megapullup() - this function is a big hack.
 * Thankfully, it's only used in ng_nat and ipfw+nat.

suggests that the "old school" approach of natd might resolve this. I'll 
give it a try when I'm close enough to the box to resolve it when I make 
a configuration error.


Jeff

___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: In-kernel NAT [ipfw] dropping large UDP return packets

[Jeff Kletsky]

On 6/13/18 1:28 PM, Andrey V. Elsukov wrote:

On 13.06.2018 23:04, Jeff Kletsky wrote:

The kernel version of libalias uses m_megapullup() function to make
single contiguous buffer. m_megapullup() uses m_get2() function to
allocate mbuf of appropriate size. If size of packet greater than 4k it
will fail. So, if you use MTU greater than 4k or if after fragments
reassembly you get a packet with length greater than 4k, ipfw_nat()
function will drop this packet.


Thanks!!

Mystery solved...

/usr/src/sys/netinet/libalias/alias.c

#ifdef _KERNEL
/*
  * m_megapullup() - this function is a big hack.
  * Thankfully, it's only used in ng_nat and ipfw+nat.

suggests that the "old school" approach of natd might resolve this. I'll
give it a try when I'm close enough to the box to resolve it when I make
a configuration error.

I didn't look at the rest of libalias, but you, probably, can improve
this hack to use 9k or 16k mbufs. You can replace m_get2() call in
m_megapullup() with the following code:

if (len <= MJUMPAGESIZE)
mcl = m_get2(len, M_NOWAIT, MT_DATA, M_PKTHDR);
else if (len <= MJUM9BYTES)
mcl = m_getjcl(M_NOWAIT, MT_DATA, M_PKTHDR, MJUM9BYTES);
else if (len <= MJUM16BYTES)
mcl = m_getjcl(M_NOWAIT, MT_DATA, M_PKTHDR, MJUM16BYTES);
else
goto bad;



Tested and "works for me" on 11.1-RELEASE-p10 with GENERIC kernconf

8<
--- alias.c.orig    2017-07-20 16:42:02.0 -0700
+++ alias.c    2018-06-13 15:41:46.862121000 -0700
@@ -1758,7 +1758,14 @@
 if (m->m_next == NULL && M_WRITABLE(m))
     return (m);

-    mcl = m_get2(len, M_NOWAIT, MT_DATA, M_PKTHDR);
+    if (len <= MJUMPAGESIZE)
+        mcl = m_get2(len, M_NOWAIT, MT_DATA, M_PKTHDR);
+    else if (len <= MJUM9BYTES)
+        mcl = m_getjcl(M_NOWAIT, MT_DATA, M_PKTHDR, MJUM9BYTES);
+    else if (len <= MJUM16BYTES)
+        mcl = m_getjcl(M_NOWAIT, MT_DATA, M_PKTHDR, MJUM16BYTES);
+    else
+        goto bad;
 if (mcl == NULL)
     goto bad;
 m_align(mcl, len);
>8

Thanks again!

Jeff

___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

VNET / netgraph jails -- Locking down?

[Jeff Kletsky]

For several years I've been using netgraph to provide connectivity for 
"service hosts" in jails on a "jail server"


Since I'm finally getting the jail server off FreeBSD 9 and solidly onto 
11, I've got the chance to rewrite the scripting of how I'm handling 
jail connectivity and am hoping that I can lock things down a bit better 
than what I have presently.



The approach I use looks similar to that now in the jail examples. Basically

  /---> ng_eiface_jail1
real_interface = ng_ether <---> ng_bridge <---> ng_eiface_jail2
  \---> ng_eiface_jail3

While this works well, it concerns me that the real interface has to be 
in promiscuous mode (and have autosrc off).


If one of the service jails is "taken over" then there isn't a way that 
I know of to lock out changing the IP address of the interface it has, 
or potentially gaining access to another VLAN through creation of a 
cloned interface, especially if the bridge is off the parent interface, 
not off a VLAN interface.



How do people manage this in practice when the jail has the risk of 
compromise?



I prefer approaches where the jail's notion of it's own IP address is 
the same as that of other hosts connecting to it, at least within my own 
little private-address-space world.



One thing that I've been considering is:
* Configure the jail's IP on the real interface (or appropriate VLAN 
interface) as an alias
* Send packets through ng_ipfw to an ng_eiface that the jail gets, using 
ipfw and a lookup table
* Tag the packets on return with ng_tag with a unique identifier for 
that jail's interface so ipfw can tell the only acceptable source IP

* Deny any so-tagged packets that don't have the proper source address

(jail ID by itself is not enough for the outbound packets, as some of 
the jails are dual homed.)



Has anyone tried this kind of method? Any other/better suggestions?


Would ng_ip_input be the appropriate way to "send" the packets coming 
from the jail?



Thanks!


Jeff




___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: Securing the root account

[Jeff Gentry]

> I come from the Windoze side of the playground, where you are able to
> rename the Administrator account name, in order to provide a bit more
> security.

How is that anything other than security through obscurity?

That is fairly retarded and will not really provide anything except
for a *false* sense of security.

-Jeff


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message

ENOBUFS and network performance tuning

[Jeff Behl]

I have 4.3, and soon to be 4.4, boxes dedicated to a single app which 
basically 'bounces' traffic between two incoming TCP connections.  After 
around 240 sessions (each session consisting of two incoming connections 
with traffic being passed between them), I started getting ENOBUFS 
errors.  netstat -m showed mbuf's never peaked, so we increased 
kern.ipc.somaxconn from 128 -> 256.  Should this help the problem?

Any other guidelines to help tune a FreeBSD box for this sort of use 
would be greatly appreciated.  Currently, the only change we make is 
increasing MAXUSERS to 128, though I'm not sure this is the preferred 
approach.

Also, is there a definitive guide to what all the kernel variables 
(sysctl -a) are?

thanks
Jeff


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message

FW: 3com gigabit 3c996b-t

[Jeff Lawton]

 

I am having trouble getting a 3com 3c996b-t to
installed correctly. Is here a reference on how to properly set up the
bge(4) driver. I am useing 4.5 release

 

 

 

Jeff

 

RE: 3com gigabit 3c996b-t

[Jeff Lawton]

Bge detects the card and it shows up on ifconfig it does not detect
1000basetx on autoselect even though the card and the switch both register
1000baset. I connected it to a 100base t port and it seems to work fine. How
do I get it to switch to 1000baset

This is the bge section of ifconfig

bge0: flags=8843 mtu 1500
options=3
inet 192.168.0.166 netmask 0xff00 broadcast 192.168.0.255
inet6 fe80::204:76ff:fee0:12a9%bge0 prefixlen 64 scopeid 0x1
ether 00:04:76:e0:12:a9
media: Ethernet autoselect (100baseTX )
status: active

Jeff
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On
Behalf Of Jesper Skriver
Sent: Friday, February 22, 2002 5:53 PM
To: Jeff Lawton
Cc: [EMAIL PROTECTED]
Subject: Re: FW: 3com gigabit 3c996b-t

On Fri, Feb 22, 2002 at 05:41:03PM -0500, Jeff Lawton wrote:

> I am having trouble getting a 3com 3c996b-t to installed correctly. Is
> here a reference on how to properly set up the bge(4) driver. I am
> useing 4.5 release

If you told what the problem was, it would be a whole lot easier to help
...

/Jesper

--
Jesper Skriver, jesper(at)skriver(dot)dk  -  CCIE #5456
Work:Network manager   @ AS3292 (Tele Danmark DataNetworks)
Private: FreeBSD committer @ AS2109 (A much smaller network ;-)

One Unix to rule them all, One Resolver to find them,
One IP to bring them all and in the zone to bind them.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message

3com gigabit 3c996b-t

[Jeff Lawton]

On 100baset it only works for a few minuites I can mount other nfs
drives and ftp to other machines. But when I ssh in to it. I get in and about 4
commands, it disconnects and will not let me back in and It can no longer
connect to anything either.

 

Jeff Lawton

Ideal Solution, LLC

 

siocsifmedia error w/bge driver

[Jeff Lawton]

I am attempting to install a 3com 996b-t on a 4.5 i386 machine and I receive
“siocsifmedia Device Not Configured” when I attempt to for it into
1000basetx mode with the following command:

Ifconfig bge0 media 1000baseTX

Any help with this is greatly appreciated.

Jeff Lawton
Ideal Solution, LLC



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message

3com gigabit 3c996b-t

[Jeff Lawton]

 "siocsifmedia Device Not Configured" when I attempt to force it into
 1000basetx mode with the following command:
 Ifconfig bge0 media 1000baseTX
 Any help with this is greatly appreciated.
>
>
>
>
> Jeff Lawton
> Ideal Solution, LLC
>
> -Original Message-
> From: Jesper Skriver [mailto:[EMAIL PROTECTED]]
> Sent: Saturday, February 23, 2002 8:52 AM
> To: Jeff Lawton
> Subject: Re: FW: 3com gigabit 3c996b-t
>
> On Fri, Feb 22, 2002 at 07:17:27PM -0500, Jeff Lawton wrote:
> > Bge detects the card and it shows up on ifconfig it does not detect
> > 1000basetx on autoselect even though the card and the switch both
register
> > 1000baset. I connected it to a 100base t port and it seems to work fine.
> How
> > do I get it to switch to 1000baset
>
> 'man bge' would tell you
>
> ifconfig bge0 media 1000baseTX
>
> /Jesper
>
> --
> Jesper Skriver, jesper(at)skriver(dot)dk  -  CCIE #5456
> Work:Network manager   @ AS3292 (Tele Danmark DataNetworks)
> Private: FreeBSD committer @ AS2109 (A much smaller network ;-)
>
> One Unix to rule them all, One Resolver to find them,
> One IP to bring them all and in the zone to bind them.
>

/Jesper

--
Jesper Skriver, jesper(at)skriver(dot)dk  -  CCIE #5456
Work:Network manager   @ AS3292 (Tele Danmark DataNetworks)
Private: FreeBSD committer @ AS2109 (A much smaller network ;-)

One Unix to rule them all, One Resolver to find them,
One IP to bring them all and in the zone to bind them.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message

RE: 3com gigabit 3c996b-t

[Jeff Lawton]

Thank you, if you get a functioning driver please let me know.  Does any one
know if I would be better off returning this card and getting a more
supported one like the intel pro1000 or dge-500tx. does any one have a
recommendation. My company wants to use this as a btrieve (I know yuk) file
server. We have a database that we have been using for years. This is an
temporary performance increase while we work on a client server system.

Jeff Lawton
Ideal Solution, LLC

-Original Message-
From: Brooks Davis [mailto:[EMAIL PROTECTED]]
Sent: Monday, February 25, 2002 2:39 PM
To: Jeff Lawton
Cc: [EMAIL PROTECTED]
Subject: Re: 3com gigabit 3c996b-t

On Fri, Feb 22, 2002 at 06:58:20PM -0500, Jeff Lawton wrote:
> Bge detects the card and it shows up on ifconfig it does not detect
> 1000basetx on autoselect even though the card and the switch both register
> 1000baset. I connected it to a 100base t port and it seems to work fine.
How
> do I get it to switch to 1000baset
>
> This is the bge section of ifconfig
>
> bge0: flags=8843 mtu 1500
> options=3
> inet 192.168.0.166 netmask 0xff00 broadcast 192.168.0.255
> inet6 fe80::204:76ff:fee0:12a9%bge0 prefixlen 64 scopeid 0x1
> ether 00:04:76:e0:12:a9
> media: Ethernet autoselect (100baseTX )
> status: active

At least on the systems I'm trying to use 3C996B-T's on, the MII support
is clearly hosed.  I'm seeing it probe 32 instances on ukphys which is
bogus.  I'm going to try and look at it some time this week, but someone
with more driver experience would probalby have more luck.

-- Brooksk

--
Any statement of the form "X is the one, true Y" is FALSE.
PGP fingerprint 655D 519C 26A7 82E7 2529  9BF0 5D8E 8BE9 F238 1AD4


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message

Getting rid of maxsockets.

[Jeff Roberson]

Would anyone be upset if I got rid of maxsockets and consequently the
limits on the *pcb zones?  This was previously used so that the zone
allocator could allocate items at interrupt time.  Now you can just supply
M_NOWAIT/WAITOK and get the desired effect without a hard limit.

Jeff


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message

Re: Getting rid of maxsockets.

[Jeff Roberson]

On Wed, 20 Mar 2002, Alfred Perlstein wrote:

>
> That depends on what this implies. :)
>
> Does it mean that when giving M_NOWAIT there's a chance it may fail
> more often than the old zone allocator?  Meaning does M_NOWAIT mean
> "only allocate from cache" or do you do close to the same thing that
> the zone allocator does except in a more flexible manner?
>
> Sorry if the question is niave, I'm not extremely familiar with the
> previous and current code.
>

Currently it means, if I can't get KVA or a page to back it, return NULL.
It just stops operations that would REALLY block.  The old code reserved
the KVA up front and just found a page at interrupt time.

Jeff


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message

Re: Getting rid of maxsockets.

[Jeff Roberson]

On Wed, 20 Mar 2002, Mike Silbersack wrote:
>
> We still need to cap the number of sockets somehow, as it would be bad for
> sockets to consume all memory.  If you want to move the socket limit to
> someplace where it can be modified via a sysctl, that'd be great.  As
> you're going through and UMAing everything, I think it'd be best if you
> kept the limits the same for now.
>

I have kept the current limits in place, but I think that it's somewhat
ugly to have this policy enforced in the allocator where it is hard to
adjust with a sysctl.  Perhaps maxsockets could stay but become run time
adjustable.

Is there any case where we will have lots of pcbs w/o sockets?  If so, all
of the limits checking can be done in the socket code and the pcb code can
completely forget about it.

>
> Once everything's UMA'd, then we can develop new sizing parameters.

Everything has been UMA'd other than MD code, so I'm working on making the
system take advantage of it.

>
> Mike "Silby" Silbersack
>


Thanks!
Jeff


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message

Re: Getting rid of maxsockets.

[Jeff Roberson]

On Wed, 20 Mar 2002, Alfred Perlstein wrote:

> >
> > Currently it means, if I can't get KVA or a page to back it, return NULL.
> > It just stops operations that would REALLY block.  The old code reserved
> > the KVA up front and just found a page at interrupt time.
>
> Bottom line, will the semantics change?
>
> What it sounds like is that if things aren't "just right" (which may
> be the majority of times) we may fail earlier than the old code would,
> is this true?
>
> Basically, what changes semantically because of your change?
>

The short answer is, no we won't fail any earlier.  The reason the KVA was
reserved before was so that you wouldn't have to grab a lock at interrupt
time to do allocations.  Now we can grab locks, we just can't msleep.
This makes things a lot simpler.


Jeff


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message

Re: Getting rid of maxsockets.

[Jeff Roberson]

On Fri, 22 Mar 2002, Mike Silbersack wrote:

> There's one big target, though:  mbufs.  I know that Bosko put a lot of
> work into his new mbuf allocator, but if you could find a way to merge
> mbufs into the slab allocator the benefits would be huge.  Have you
> discussed doing this with Bosko yet?
>
> Mike "Silby" Silbersack
>

We have talked about it quite a bit.  I'd love to remove the hard limit on
mbufs.  I may do this soon, but I have other uma related work that will
probably come before it.

Jeff


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message

Re: reproducible watchdog timeout in bge

[Jeff Royle]

MQ wrote:

2007/1/22, Wishmaster <[EMAIL PROTECTED]>:


Hello LI,

Sunday, January 21, 2007, 12:52:55 AM, you wrote:

LX> Wishmaster wrote:
>> Hi,
>>
>> http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/92090

LX> Have you tried this one?

LX> http://people.freebsd.org/~delphij/misc/patch-bge-releng62

LX> Cheers,

Yes, i tried, but have no effect.

after reboot interface works, but if i try to ping with packet for
example 1500 bytes and interval 0.01s it looks like

answer
answer
answer

. over 50 or less icmp answers then
ping: sendto: No buffer space available
ping: sendto: No buffer space available
ping: sendto: No buffer space available
ping: sendto: No buffer space available
ping: sendto: No buffer space available
ping: sendto: No buffer space available
ping: sendto: No buffer space available

in dmesg:
bge0: watchdog timeout -- resetting
bge0: link state changed to DOWN
bge0: link state changed to UP

--
Best regards,
Wishmastermailto:[EMAIL PROTECTED]



What about other NIC chips from Broadcom? And how about the packets other
than icmp under the same load?
___


I have been unable to produce time outs with my current setup in 
6.2-Release.


[EMAIL PROTECTED]:0:0:  class=0x02 card=0x81491043 chip=0x165914e4 rev=0x11 
hdr=0x00

vendor   = 'Broadcom Corporation'
device   = 'BCM5750A1 NetXtreme Gigabit Ethernet PCI Express'
class= network
subclass = ethernet

Reading the PR, I attempted triggering this through CVSing and through 
the above mentioned ping tests.


So far nothing.

The only issue I have seen using these NICs in 6.2R is if I nail up the 
NIC at 100baseTX full-duplex I sometimes loose connectivity.   Nothing 
in the logs indicate watchdog timeouts or any other issue.   I simply 
brought the NIC back down to auto-neg and all seems fine.   I am 
assuming this is a incompatibility between the BGE and my switch, RS8000.


I have a Asus P5MT-S with dual BGE NIC's

Cheers,

Jeff
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: send() returns error even though data is sent, TCP connection still alive

[Jeff Davis]

On Wed, 2007-01-31 at 15:04 -0500, Garrett Wollman wrote:
> In article <[EMAIL PROTECTED]>,
> Jeff Davis  <[EMAIL PROTECTED]> wrote:
> 
> >You should see something like "write failed: host is down" and the
> >session will terminate. Of course, when ssh exits, the TCP connection
> >closes. The only way to see that it's still open and active is by
> >writing (or using) an application that ignores EHOSTDOWN errors from
> >write().
> 
> I agree that it's a bug.  The only time write() on a stream socket
> should return the asynchronous error[1] is when the connection has
> been (or is in the process of being) torn down as a result of a
> subsequent timeout.  POSIX says "may fail" for these errors write()
> and send() on sockets
> 

As far as I'm concerned, a fix for this bug is critical. We have had to
move production apps off some of our freebsd servers.

Regards,
Jeff Davis

___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

polling on 4.7 crash...

[Jeff Behl]

FreeBSD rack1-5.nwk 4.7-RELEASE-p1 FreeBSD 4.7-RELEASE-p1 #1: Tue Nov 12
10:37:37 PST 2002 [EMAIL PROTECTED]:/usr/src/sys/compile/GENERIC2  i386


Has anyone had problems with polling on a 4.7 box?  It worked for about
24 hours then blew up with the below.  While it worked it worked
fantastically, dropping cpu time spent in interrupt from ~%40 to %0.

The system was using the fxp driver and was sniffing a fully saturated
100mb line while doing very little trasnmitting of data itself.  I don't
see how HUPing syslogd could have caused it, but it did happen at the
same time.

Anyone experienced this or know of a fix?  I'd be more than happy to
help out in any testing.

If this code works reliably it will be of great use to us; props to
Luigi for writing it!

-jeff


Nov 14 12:15:00 rack1-5 syslogd: restart
Nov 14 12:15:00 rack1-5 /kernel: rent process   = Idle
Nov 14 12:15:00 rack1-5 /kernel: interrupt mask = net bio cam
Nov 14 12:15:00 rack1-5 /kernel: trap number= 12
Nov 14 12:15:00 rack1-5 /kernel: panic: page fault
Nov 14 12:15:00 rack1-5 /kernel: Uptime: 2d1h32m36s
Nov 14 12:15:00 rack1-5 /kernel:
Nov 14 12:15:00 rack1-5 /kernel:
Nov 14 12:15:00 rack1-5 /kernel: Fatal trap 12: page fault while in
kernel mode
Nov 14 12:15:00 rack1-5 /kernel: fault virtual address  = 0xc1e14c10
Nov 14 12:15:00 rack1-5 /kernel: fault code = supervisor
write, page not present
Nov 14 12:15:00 rack1-5 /kernel: instruction pointer= 0x8:0xc0172797
Nov 14 12:15:00 rack1-5 /kernel: stack pointer  = 0x10:0xc027f5d0
Nov 14 12:15:00 rack1-5 /kernel: frame pointer  = 0x10:0xc027f5e4
Nov 14 12:15:00 rack1-5 /kernel: code segment   = base 0x0,
limit 0xf, type 0x1b
Nov 14 12:15:00 rack1-5 /kernel: = DPL 0, pres 1, def32 1, gran 1
Nov 14 12:15:00 rack1-5 /kernel: processor eflags   = interrupt
enabled, resume, IOPL = 0
Nov 14 12:15:00 rack1-5 /kernel: current process= Idle
Nov 14 12:15:00 rack1-5 /kernel: interrupt mask = net bio cam
Nov 14 12:15:00 rack1-5 /kernel: trap number= 12
Nov 14 12:15:00 rack1-5 /kernel: panic: page fault
Nov 14 12:15:00 rack1-5 /kernel: Uptime: 2d1h32m37s
Nov 14 12:15:00 rack1-5 /kernel:


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message

Re: polling on 4.7 crash...

[Jeff Behl]

Great! I've instaleld rev. 1.110.2.27 so we'll see how it fares.

Thanks much!

Jeff



Guy Helmer wrote:

Jeff Behl wrote:


FreeBSD rack1-5.nwk 4.7-RELEASE-p1 FreeBSD 4.7-RELEASE-p1 #1: Tue Nov


12


10:37:37 PST 2002
[EMAIL PROTECTED]:/usr/src/sys/compile/GENERIC2  i386

Has anyone had problems with polling on a 4.7 box?  It worked 
for about
24 hours then blew up with the below.  While it worked it worked
fantastically, dropping cpu time spent in interrupt from ~%40 to %0.

The system was using the fxp driver and was sniffing a fully saturated
100mb line while doing very little trasnmitting of data 
itself.  I don't
see how HUPing syslogd could have caused it, but it did happen at the
same time.


Yes, Ian Dowse just committed a fix to if_fxp.c in 4.7-stable (and
previously, to -current) that solved this problem with the fxp driver.
Look for rev. 1.110.2.27 of if_fxp.c
(http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/fxp/if_fxp.c) or
cvsup the updates.

Hope this helps,
Guy



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message

when are mbuf clusters released?

[Jeff Behl]

running apache-2.0.42 we're running into mbuf cluster exhaustion.  going
by what 'man tuning' says:

We recommend values between 1024 and 4096 for machines with mod-
erates amount of memory, and between 4096 and 32768 for machines with
greater amounts of memory.  Under no circumstances should you specify an
arbitrarily high value for this parameter, it could lead to a boot-time
crash.

you'd think we would have been fine at 32768.  setting it to 64000
helped, but only for a while; usage was still slowly creeping up

5066/52544/256000 mbufs in use (current/peak/max):
 5058 mbufs allocated to data
 8 mbufs allocated to packet headers
5031/50612/64000 mbuf clusters in use (current/peak/max)
114360 Kbytes allocated to network (15% of mb_map in use)


is there some strange interaction going on between apace2 and bsd?
killing apache caused the mbuf clusters to start draining, but only
slowly.  will clusters still be allocated in FIN_WAIT_? states?  TIME_WAIT?

This maching was serving a couple hundred connections a second...which
doesn't seem like it should have taxed it much (p3 1.2 gHz).  CPU util
was low.

Any help appreciated.

Jeff



FreeBSD dell350-12.snv 4.6.2-RELEASE FreeBSD 4.6.2-RELEASE #0: Tue Oct
15 16:20:35 GMT 2002
[EMAIL PROTECTED]:/usr/src/sys/compile/EC-DELL-03  i386


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message

Re: when are mbuf clusters released?

[Jeff Behl]

Thanks for the info.  Could you explain how mbuf clusters and mbufs are 
related?  i'd like to better understand how we can run out of one and 
not the other.  also, is there an upper value for mbuf clusters that we 
should be wary of?  again, the tuning page is quite vague on this. 
64000 seems to not do the trick so i was thinking of 2X this.  we have 
plenty of memory (1GB and the machine only runs apache).

for those interested, we think we've found why we're getting lots of 
connections in FIN_WAIT_1 state...it appears to be some sort of odd/bad 
interaction between IE and flash (we think).  these machines serve popup 
adds (sorry!), and we're guessing that when a user with a slower 
connection gets one of these pop-ups and kills the window before the 
flash file is done downloading, IE leaves the socket open...sorta, and 
here's where it gets interesting.  it leaves it open, but closes the 
window (sets it to 0)...or is the plugin doing this?  apache is done 
sending data and considers the conenction closed, so its client timeout 
feature never comes into play.  but there is still data in the sendq, 
including the FIN, we believe.  BSD obeys the spec (unfortunately) and 
keeps probing to see if the window has opened so it can transmit the 
last of the data.  this goes on indefinitely!  so we get gobs 
connections stuck in fin_wait_1.  interestingly, we have a solaris 
machine serving the same purpose and it does not have the problem.  it 
seems to not folluw the rfc and silently closes the conenction after a 
number of tries when a socket is in fin_wait_1.  these seems more 
reasonable to me.  this seems (as i've read from other posts as well) 
quite an opportunity for a DoS attackjust keep advertising a window 
of 0.  a single client could easily tie everything up in fin_wait_1...

anyone think of a workaround (besides not serving pop-ups :)

jeff


Mike Silbersack wrote:
On Mon, 30 Dec 2002, Jeff Behl wrote:



5066/52544/256000 mbufs in use (current/peak/max):
5031/50612/64000 mbuf clusters in use (current/peak/max)

is there some strange interaction going on between apace2 and bsd?
killing apache caused the mbuf clusters to start draining, but only
slowly.  will clusters still be allocated in FIN_WAIT_? states?  TIME_WAIT?



Before I answer your question, let me explain how clusters are allocated.
The first number above shows how many are in use at the moment.  The
second number shows how many have been used, and are currently allocated.
The third is the limit you have set.

What this means is that once an mbuf (or cluster) has been allocated, it
is never truly freed, only returned to the free list.  As a result, after
your spike in mbuf usage, you never really get the memory back.  However,
this may be OK if you have plenty of ram.



This maching was serving a couple hundred connections a second...which
doesn't seem like it should have taxed it much (p3 1.2 gHz).  CPU util
was low.

Any help appreciated.

Jeff



Now, on to why the value spiked.  Yes, connections in FIN_WAIT* states
still hang on to mbuf clusters relating to the data they have been asked
to send.  There was a DoS script going around which intentionally stuck
many sockets on a server in the FIN_WAIT_2 state until enough had been
stuck to cause mbuf cluster exhaustion.  To determine if this is the case,
just run netstat -n and look at the sendq value; if you see high sendq
values on a lot of sockets, this may be your answer.

The other possibility is that you're being hit with lots of IP
fragments... currently, the IP reassembly code allows too many unassembled
packets to sit around.  There's no way to inspect the IP reassembly queue
actively, but you could use netstat -s to see "fragments received" - if
the number is high, then it's likely something is up.

Mike "Silby" Silbersack



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message

Re: possible DoS in dc driver

[Jeff Jirsa]

On Tue, 21 Jan 2003, Jacques A. Vidrine wrote:

> Long, lng ago, someone reported a dc driver bug.  However,
> a couple of us have tried and failed to reproduce the problem.  I
> thought I'd bounce the issue here before completely forgetting about
> it.

I'm not seeing it on 4.5. MBUF exhaustion: yes, lockup: no.

( From a different machine)
[10:51pm] jeff@snip (~) # sudo ping -f -s 5 snip
Password:
PING snip (snip): 5 data bytes





^C

(On the 4.5 machine)
[10:52pm] jeff@snip (~) # ifconfig dc0
dc0: flags=8843 mtu 1500
inet snip netmask 0xf800 broadcast snip.255
ether 00:a0:cc:37:50:fa
media: Ethernet autoselect (100baseTX )
status: active
[10:52pm] jeff@snip (~) # uname -a
FreeBSD snip 4.5-RELEASE-p1 FreeBSD 4.5-RELEASE-p1 #0: Fri Mar
1 15:09:01 GMT 2002
jeff@snip:/usr/src/sys/compile/snip_4_5  i386
[10:52pm] jeff@snip (~) dmesg -a | tail
m_clalloc failed, consider increase NMBCLUSTERS value
m_clalloc failed, consider increase NMBCLUSTERS value
m_clalloc failed, consider increase NMBCLUSTERS value
m_retry failed, consider increase mbuf value
m_clalloc failed, consider increase NMBCLUSTERS value
m_clalloc failed, consider increase NMBCLUSTERS value
m_clalloc failed, consider increase NMBCLUSTERS value
m_clalloc failed, consider increase NMBCLUSTERS value
m_retry failed, consider increase mbuf value
m_retryhdr failed, consider increase mbuf value

The system does drop icmp echo requests, if that matters.

- Jeff


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message

Broadcom BCM5703X causing reboot? 4.8-RC2

[Jeff Behl]

I saw some threads that seemed to relate to the bge driver in -net, so i
thought i'd post
here as well...
FreeBSD blade7-bc2.sjc 4.8-RC2 FreeBSD 4.8-RC2 #1: Wed Mar 26 20:17:42
GMT 2003
i've had two reboots in the last 30 mins on a fairly heavly loaded web
server (apache).  the following immediately precedes both reboots (no
more messages after this):
Mar 28 19:15:29 blade7-bc2 /kernel: NMI ISA 24, EISA 0
Mar 28 19:15:29 blade7-bc2 /kernel: Mar 28 19:15:29 blade7-bc2 /kernel:
NMI ISA 24, EISA 0
Mar 28 19:15:37 blade7-bc2 /kernel: bge1: watchdog timeout -- resetting
Mar 28 19:15:38 blade7-bc2 /kernel: bge1: gigabit link up
here's how the cards are detected:

Mar 28 19:18:36 blade7-bc2 /kernel: bge0:  mem 0xfbff-0xfbff irq 10 at
device 1.0 on pci1
Mar 28 19:18:36 blade7-bc2 /kernel: bge0: Ethernet address:
00:09:6b:00:4f:ff
Mar 28 19:18:36 blade7-bc2 /kernel: pcib2:  on
motherboard
Mar 28 19:18:36 blade7-bc2 /kernel: pci2:  on pcib2
Mar 28 19:18:36 blade7-bc2 /kernel: bge1:  mem 0xf9ff-0xf9ff irq 11 at
device 1.0 on pci2
Mar 28 19:18:36 blade7-bc2 /kernel: bge1: Ethernet address:
00:09:6b:00:50:00
any ideas or help?  these are the first blades we've put into production
(IBM bladecenter)...which isn't boding well at all for using the
remaining 12 blades.  the machines are only pumping out around 9Mb/s.
from other threads on this list, it would seem others have seen these
watchdog timeouts and related it to a possible error in the chipset
itself.  has this been confirmed?  will disabling checksum offload, as
someone mentioned, fix this?  i wouldn't be surprised if this was some
sort of chipset issue as the management module for the blades logs
errors whenever i get a reboot:
09:56:25 (image1.sjc) PFA Alert, see preceding error in system error
log.
09:56:22 (image1.sjc) 00150500 PERR: Master Read parity error Slot=00
VendID=14E4 DevID=16A7 Status=83
09:56:21 (image1.sjc) 00150700 PERR: Slave signaled parity error Slot=00
VendID=1166 DevID=0101 Status
any help greatly appreciated.  we would really like to keep this 
bladecenter and not have to look into moving to linux...bleh

jeff

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Intel PRO/1000 and BRIDGE

[Jeff Opie]

2647 802.1d config 8000.00:05:32:98:35:80.8010 root
8000.00:05:32:98:35:80 pathcost 0 age 0 max 20 hello 2 fdelay 15
07:01:44.878281 802.1d config 8000.00:05:32:98:35:80.8010 root
8000.00:05:32:98:35:80 pathcost 0 age 0 max 20 hello 2 fdelay 15
07:01:45.461321 208.255.47.30.17754 > paynetonline.com.pop3: S
2843466202:2843466202(0) win 64240  (DF)
>
This looks a lot different than output from the current operational
BRIDGE box (promiscuous mode on fxp0, fxp1) which I want to replace.
Please let me know if I can supply more info.
 
]hanks in advance - 
 
Jeff Opie
[EMAIL PROTECTED]
 
 
 
 
 


___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

IPv6 udp socket bind: EADDRNOTAVAIL?

[Jeff W. Boote]

I have a long running IPv6 daemon that uses both tcp and udp. It accepts
requests on a tcp socket, and then performs an action on a udp socket
using the same local address that the tcp request came in on. (I am
calling bind on the udp socket to allocate a port number to return to
the client over the tcp connection.)

My problem is that I get intermittent bind failures for the udp socket.
I'm trying to understand what is going on here. The udp bind is for the
same address as the local address of the tcp socket. (Although the tcp
socket was originally bound using the wildcard.)

I have tracked this down to the following lines in the kernel code:

in6_pcb.c:129
if (!in6_ifaddr) /* XXX broken! */
return (EADDRNOTAVAIL);

It looks like the kernel's list of v6 interfaces is empty for some
reason. Is that correct, or is there some other reason this list would
be empty?

Questions:
1. The comment says broken. Anyone know why the comment says that? (The
IPv4 version of bind says the same thing...)

2. This system is auto configuring this address... Is it possible that
I'm just having this problem because the system is reconfiguring the
address at this time? (I must admit that I have not looked at the auto
configuration stuff.)

Thanks,
jeff

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message

Re: IPv6 udp socket bind: EADDRNOTAVAIL?

[Jeff W. Boote]

. (almost an addrinfo
# structure.)
# Now this is the part where I actually use that sockaddr.
# localaddr->saddr is either sender or receiver from the
# initialization function depending upon the context of
# the actual request. (In the error case it is the sender,
# but that is only because that is the case I've been
# testing - there is no difference in the two cases until
# after the socket is bound.)
/*
 * Create the socket.
 */
ep->sockfd = socket(localaddr->saddr->sa_family,localaddr->so_type,
localaddr->so_protocol);
if(ep->sockfd<0){
OWPError(ctx,OWPErrFATAL,OWPErrUNKNOWN,"socket(): %M");
goto error;
}

/*
 * bind it to the local address getting an ephemeral port number.
 */
if(bind(ep->sockfd,localaddr->saddr,localaddr->saddrlen) != 0){
OWPError(ctx,OWPErrFATAL,OWPErrUNKNOWN,
"bind([%s]:%s): %M",localaddr->node,localaddr->port);
goto error;
}

#
# And this is an example of the error messages I have been seeing:
Nov 26 16:30:10 nms2-ipls owampd[87121]: FILE=endpoint.c, LINE=437, 
bind([2001:468:12:2:203:47ff:fef1:5071]:0): Can't assign requested address
Nov 26 16:30:12 nms2-ipls owampd[87134]: FILE=endpoint.c, LINE=437, 
bind([2001:468:12:2:203:47ff:fef1:5071]:0): Can't assign requested address
Nov 26 16:30:13 nms2-ipls owampd[87121]: FILE=endpoint.c, LINE=437, 
bind([2001:468:12:2:203:47ff:fef1:5071]:0): Can't assign requested address


Now, when this happens, it happens for about 10 seconds - and then things
start working again. So, how likely is it that not initializing sa_len
was causing this? (My ipv4 tests never had problems, and I would think
they would behave the same in this particular regard.)

(If anyone has actually read down this far, I truely thank you.)

Thanks,
jeff

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message

FreeBSD 5.0 dual-stack server

[Jeff W. Boote]

Hi,

I have some server code that I've been developing using FreeBSD 4.6 and
4.7. I want this code to run with both IPv4 and IPv6. I have been using
getaddrinfo with AF_UNSPEC to bind a wildcard server socket. (This is
the method recommended in Stevens UNP.)

In any case - my server code works fine on 4.6 and 4.7 binding to both
address families. However, I have just received a report of it only
binding the v6 address on a FreeBSD 5.0 system. (As reported from
"netstat -a -p tcp" - and by the fact that clients that try and use the
v4 address are unable to get a connection.)

It is behaving as if the IPV6_BINDV6ONLY sockopt is set... Has the
"default" value for this changed?

Is it recommended that any server that wants to bind to the dual-stack
needs to make sure this sockopt is unset? I am not doing that...

I just found the net.inet6.ip6.bindv6only sysctl variable doing a web
search... What is the default value for this sysctl on 5.0?

(I guess I may need to install 5.0 on a box, and stop bothering
others...)

Thanks,
jeff
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: FreeBSD 5.0 dual-stack server

[Jeff W. Boote]

Hajimu UMEMOTO wrote:
> boote> It is behaving as if the IPV6_BINDV6ONLY sockopt is set... Has the
> boote> "default" value for this changed?
> 
> Yes.
> BTW, IPV6_BINDV6ONLY has been superseded by IPV6_V6ONLY.

Ah - thanks.

> boote> Is it recommended that any server that wants to bind to the dual-stack
> boote> needs to make sure this sockopt is unset? I am not doing that...
> 
> Yup, where you can do it, you should do so.
> However, I suggest opening two sockets, one is for IPv6 and the other
> is for IPv4, instead of using IPv4-mapped IPv6 address.

Hmm. So the trade-off is calling select or using IN6_IS_ADDR_V4MAPPED?
(My applications need to understand the addresses at a pretty detailed
level anyway - I'll probably stick to the dual-stack method.)
 
> boote> I just found the net.inet6.ip6.bindv6only sysctl variable doing a web
> boote> search... What is the default value for this sysctl on 5.0?
> 
> net.inet6.ip6.bindv6only=1 by default on 5-CURRENT.

This seems to contradict the recommendation in RFC 3493 (which I realize
is only informational)... I've been doing a web search to try and find
some kind of record for the rational used for making this default to
v6only. I haven't found anything substantial yet. Does anyone on this
list know why? (I'm guessing there must be a good reason - and if so, I
want to make sure I'm dealing with those issues in my applications.)

> boote> (I guess I may need to install 5.0 on a box, and stop bothering
> boote> others...)
> 
> You don't need to install 5.0.  You can simply get same effect by
> setting net.inet6.ip6.bindv6only=1.

Thanks!
jeff
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: FreeBSD 5.0 dual-stack server

[Jeff W. Boote]

Hajimu UMEMOTO wrote:
> boote> This seems to contradict the recommendation in RFC 3493 (which I realize
> boote> is only informational)... I've been doing a web search to try and find
> boote> some kind of record for the rational used for making this default to
> boote> v6only. I haven't found anything substantial yet. Does anyone on this
> boote> list know why? (I'm guessing there must be a good reason - and if so, I
> boote> want to make sure I'm dealing with those issues in my applications.)
> 
> Yes, this breakage against RFC2553/3493 is intentional.  Please refer:
> 
> draft-cmetz-v6ops-v4mapped-api-harmful-00.txt

Thanks!

So... This would mean an application that wanted to be address
independent would have to create a socket for every single wildcard
sockaddr returned from getaddrinfo. And then use select/accept instead
of just accept. That is kind of ugly... But, I guess it does make sense
in the new world of multiple addresses and address families per host.

jeff
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Forward: HEADS UP! Default value of ip6_v6only changed

[Jeff W. Boote]

Hajimu UMEMOTO wrote:
> 
> Hi,
> 
> Our default of net.inet6.ip6.v6only was off in 4.X, and was changed to
> on on 5.X to follow NetBSD's practice.  This behavior on 5.X breaks
> RFC2553/3493, and the change was intentional from security
> consideration.  But, NetBSD changed it off by default.
> How do you think our default of on?

As long as it is documented well, and the workaround (setting the
IPV6_V6ONLY sockopt "off") is referenced, I don't think it really
matters. Application programmers realize they have *some* work to do
when porting applications to V6. A single sockopt call is not
unreasonable. I think "on" for the security reasons outlined is the
right call - it will at least make people think about those issues, and
most would not without something bringing it up. (That said, it would be
nice if NetBSD would pick a direction and keep it.)

jeff
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"