Re: Notification of change of IP address/Routing etc
On 2022-Aug-31 10:18:44 +0200, Martin Stiemerling wrote: >I am looking for a mechanism to get a notification from the OS when, for >instance, an IP address on an interface or a routing entry is being changed. Assuming you are using the base OS version of dhclient, you could use /etc/dhclient-exit-hooks, which is a shellscript documented in dhclient-script(8). -- Peter Jeremy signature.asc Description: PGP signature
Re: Question: Why ain't I getting gigabit speed?
On 2013-Feb-07 15:13:27 -0800, "Ronald F. Guilmette" wrote: >I just aquired a brand new chepie gigabit PCI ethernet card off eBay. >The main chip on it appears to be an RTL8110S-32. ... >I've tried two different CAT6 cables, two different LAN ports on my E2000, >and I've even tried the card in two different PCI slost on my motherboard, >but the results are always the same. Based on the testing you've done, I'd suspect a broken card. I'll echo the comments that Realtek is the cheapest end of the market and you'd be better off with a Broadcom or Intel NIC. >P.S. dmesg has this to say about the card: > >re0: port >0xbe00-0xbeff mem 0xdf9ff000-0xdf9ff0ff irq 18 at device 5.0 on pci4 >re0: Chip rev. 0x0400 >re0: MAC rev. 0x >re0: Ethernet address: 00:13:3b:02:03:bd >re0: link state changed to UP >re0: link state changed to DOWN >re0: link state changed to UP The critical information you've left out is the phy details. This should look something like: miibus0: on re0 rgephy0: PHY 1 on miibus0 rgephy0: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow On 2013-Feb-08 12:48:32 -0800, "Ronald F. Guilmette" wrote: >I did some more experiments. Fortunately, I had a CAT6 crossover cable >lying around. For future reference, you can join GigE interfaces with either straight through or crossover cables. >In the case of connecting to the laptop, all seemed to work correctly, >however ifconfig showed that my re0 device in this case believed itself >to be "master". (I suspect that this may make a difference, and that >the current FreeBSD re driver may perhaps behave better when it is >acting as master.) The "master" term seems to only define which end is the clock source. >in the output from "ifconfig re0", *however* a moment or two later, >suddenly the connection was entirely dropped, and now the ifconfig >output said "no carrier". What status was reported on the lights at each end? -- Peter Jeremy pgpAs2VtFUApg.pgp Description: PGP signature
Re: point-to-point network with unknown peer ip address
On 2013-Feb-20 02:56:55 -0800, "M. V." wrote: >I have 2 FreeBSD8.2 systems. I have a point-to-point interface >(myif0) on each side connected together, but on each side I don't >know IP address of the other side. to make the connection work, On >each side I set IP address (2.2.2.32/24 and 2.2.2.33/24) and added a >route which sends all traffic to the network to interface: > >#route add 2.2.2.0/24 -interface myif0 > >#ifconfig myif0 >myif0: flags=89d1 >metric 0 mtu 1500 I'm not certain what you are trying to achieve but point-to-point links would normally be /32, not /24. >now, from one side if I ping the other side (say 2.2.2.33/24) >everything seems ok. but if I ping any other IP in the network (say >2.2.2.100/24) the other endpoint sends back packet + an ICMP REDIRECT >packet. 2.2.2.100 is not a valid address in the network you have described. Where did you expect you expect the packet to be sent? >my sysctl output: >... > >net.inet.ip.redirect: 1 >net.inet.icmp.drop_redirect: 0 >... You don't say what you are trying to achieve but my crystal ball says that you want net.inet.ip.forwarding=1 on the remote system. -- Peter Jeremy pgp4c2p5tAMBd.pgp Description: PGP signature
Re: Basic NAT server setup
On 2013-May-30 17:54:53 -0500, Joe Moog wrote:
>I'm building a server to handle outbound NAT to the internet using
>FreeBSD 9.1 and its built-in distribution of pf. What I want to be
>able to do is NAT three unique internal (private) VLANs to three
>unique public IPs.
>ext_if = "vlan11"
>ext_addr1 = "a.b.c.3"
>ext_addr2 = "a.b.c.4"
>ext_addr3 = "a.b.c.5"
>int_network1 = "10.0.1.0/24"
>int_network2 = "172.16.1.0/24"
>int_network3 = "192.168.1.0/24"
>nat on $ext_if from $int_network1 to any -> $ext_addr1
>nat on $ext_if from $int_network2 to any -> $ext_addr2
>nat on $ext_if from $int_network3 to any -> $ext_addr3
I don't see anything obviously wrong with what you've done. My initial
checks would be:
- Do you have the correct routes on the NAT box.
- Do you have a.b.c.{3,4,5} setup as aliases on vlan11 (or faked using
proxy ARP).
(My suspicion is the second point - packets are going out successfully
but the response is undeliverable because nothing is responding to the
switch's ARP requests for a.b.c.{3,4,5}).
Next would be to use tcpdump to do some snooping:
- Firstly, make sure the packets are are arriving on the NAT box with
appropriate src & dst IPs by tcpdump'ing the internal interface(s).
- Secondly, tcpdump the external interface and see what is going out
and returning (tcpdump will see the external addresses)
Finally, add some 'log' keywords and tcpdump pflog0. Unfortunately,
the stock FreeBSD tcpdump can't handle pflog packets. There are some
patches in bin/124825 but you will need to do some work to get them
to apply to the tcpdump in 9.1.
That will hopefully give you some pointers as to where to investigate.
--
Peter Jeremy
pgpKOuIGsvWtO.pgp
Description: PGP signature
Unable to use pf(4) NAT with jail on 9.2-RELEASE
I am trying to configure a new firewall and want to run squid in a jail but have been unsuccessful in getting outgoing NAT to work. I have previously used jails on 8.x and 10.x with traffic going both into and out of jails but I admit this is the first time I've tried to use NAT on the outgoing traffic. I've tried attaching the jail to each of lo0, lo1 using a 127/8 address; lo1, the internal and the external interface using a dummy (RFC1918) address and the internal interface using a valid-for-my-internal-network RFC1918 address, using a NAT rule like: nat on $ext_if from $jail_subnet to any -> $ext_addr Monitoring the external interface on another host, either no packets are transmitted (for the 127/8 addresses) or the source address is the unchanged RFC1918 address unchanged. As a specific example: In rc.conf: jail_squid_ip="198.168.120.4" # Dummy address jail_squid_interface="em0" # Internal interface jail_squid_exec_start="/usr/bin/fetch -o /tmp/zzz https://223.223.223.1/"; Complete pf.conf: nat log on re0 from 192.168.120.4/32 to any -> 223.223.223.2 pass quick all (changing the /32 to /24 makes no difference). ifconfig whilst the jail is trying to start: em0: flags=8843 metric 0 mtu 1500 options=4019b inet 192.168.123.124 netmask 0xff00 broadcast 192.168.123.255 inet 198.168.120.4 netmask 0x broadcast 198.168.120.4 re0: flags=8843 metric 0 mtu 1500 options=8209b inet 223.223.223.2 netmask 0xfffc broadcast 223.223.223.3 And tcpdump on a system connected to re0 shows: 21:25:44.030983 IP 198.168.120.4.36205 > 223.223.223.1.443: Flags [S], seq 1462646452, win 65535, options [mss 1460,nop,wscale 6,sackOK,TS val 712899226 ecr 0], length 0 (the source address should be 223.223.223.2). OTOH, if I use a more complete pf.conf and initiate the connection either on the host or on an "internal" box set to route through the firewall, everything works as expected. What am I doing wrong? -- Peter Jeremy pgpHe3KFE2Zph.pgp Description: PGP signature
Re: pow function in kernel space
On 2014-Jun-19 20:40:48 +0800, 张晗 wrote: >how can I implement, in an efficient, way the pow() function in kernel space ? > Is there any function I can use o r how I can evaluate pow function in kernel >model? Since the kernel only offers integer arithmetic, one approach would be square and multiply. What are you trying to do? Maybe we can offer an alternative to pow(3). -- Peter Jeremy pgp6AHdKYOfNS.pgp Description: PGP signature
Re: problem with vlan interfaces tagging/untagging in a simulated switch box
On 2012-Mar-04 10:01:07 +0330, h bagade wrote: >I have problems with vlan interfaces on freebsd. I want to make my >system like a switch with vlan ports and also a trunk port in >conjuction with other switches. I thought that vlan interfaces would >help me tagging traffic when traffic is going out the trunk port(or >when it receives on vlan ports). >The problem, I've encountered is that vlan interafaces on freebsd do >tagging/untagging when the traffic is sourced/destined from/to them >which in this case they should be assigned IP addresses. In other >words they won't tag the traffic passing through their parent >interface which I need to. I am doing this with no problems so I suspect you are doing something wrong. As an example, the following creates a IEEE802.1Q trunk on em0 with 192.168.1.0/24 untagged and the remaining subnett tagged: ifconfig em0 inet 192.168.1.123/24 ifconfig vlan10 inet 192.168.10.123/24 vlandev em0 vlan 10 ifconfig vlan11 inet 192.168.11.123/24 vlandev em0 vlan 11 ifconfig vlan12 inet 192.168.12.123/24 vlandev em0 vlan 12 ifconfig vlan13 inet 192.168.13.123/24 vlandev em0 vlan 13 Can you post the rc.conf etc entries that you are using and a description of what you are trying to achieve. -- Peter Jeremy pgppcO8hHBl6F.pgp Description: PGP signature
Re: problem with vlan interfaces tagging/untagging in a simulated switch box
Please don't top-post. On 2012-Mar-05 13:30:36 +0330, h bagade wrote: >on layer 2 switch, ports doesn't have ip addresses and traffic comming >from a vlan port is tagged and pass through trunk port. this means >that in our freebsd box which plays the role of switch, no interfaces >should have ip addresses. OK. Sorry, I misunderstood what you were trying to achieve. I am using FreeBSD as a router rather than a switch. That said, I suspect your problem is that you are misunderstanding how VLAN tagging is applied. If a packet flows through a vlan(4) device, the appropriate tag is removed from incoming (from the network) packets and added to outgoing (to the network) packets. Packets flowing through normal ethernet devies (your ethX) without also flowing through a vlan(4) are not tagged (and so will appear in the default vlan as far as an external switch is concerned). Internally (ie as seen by bridge(4) instances), packets are not tagged. The following example diagram shows 3 distinct packet flows: - packets tagged 5 in trunk1 and 6 in trunk0 - packets tagged 7 in trunk1 and 9 in trunk0 - packets tagged 8 in trunk0 and 10 in trunk2 +-- vlan5 --- bridge1 --- vlan6 --+ | | trunk1 --- eth1 -+- vlan7 --- bridge2 --- vlan9 --+-- eth0 --- trunk0 | bridge3 --- vlan8 --+ | trunk2 -- eth2 --- vlan10 This would be configured as: ifconfig vlan5 vlan 5 vlandev eth1 ifconfig vlan6 vlan 6 vlandev eth0 ifconfig vlan7 vlan 7 vlandev eth1 ifconfig vlan8 vlan 8 vlandev eth0 ifconfig vlan9 vlan 9 vlandev eth0 ifconfig vlan10 vlan 10 vlandev eth2 ifconfig bridge1 addm vlan5 addm vlan6 ifconfig bridge2 addm vlan7 addm vlan9 ifconfig bridge3 addm vlan8 addm vlan10 -- Peter Jeremy pgp7griifAX2e.pgp Description: PGP signature
Re: problem with vlan interfaces tagging/untagging in a simulated switch box
On 2012-Mar-06 09:15:57 +0330, h bagade wrote: >On 3/6/12, Peter Jeremy wrote: >> The following example diagram shows 3 distinct packet flows: >> - packets tagged 5 in trunk1 and 6 in trunk0 >> - packets tagged 7 in trunk1 and 9 in trunk0 >> - packets tagged 8 in trunk0 and 10 in trunk2 >> >> +-- vlan5 --- bridge1 --- vlan6 --+ >> | | >> trunk1 --- eth1 -+- vlan7 --- bridge2 --- vlan9 --+-- eth0 --- trunk0 >>| >>bridge3 --- vlan8 --+ >> | >> trunk2 -- eth2 --- vlan10 >> >I've described the function of Cisco switches in vlan >tagging/untagging. Real switches typically have everything tagged internally, with the native VLAN tags added/removed at the ingress/egress ports. This simplifies the internal switch logic (at the expense of meaning that tags have to be consistent across all trunks). FreeBSD works differently. Packets are _untagged_ internally and you need a separate bridge(4) device for each broadcast domain (vlan). > In your topology, packets should be tagged when >recieved on real interfaces to be send out to vlan interfaces. Packets are never tagged by real interfaces and always have tags added/removed by vlan devices. > It >would be fine when two trunks are communicating because on both side >packets are tagged. But as I mentioned before, Cisco switches receive >packets on an interface untagged and then sending packets tagged out >of trunk port, based on which interface it receives, You can connect a physical interface (ethX) directly to a bridge device to access untagged packets. Note that I'm not sure whether it is safe to access the native VLAN in a trunk in this way. To continue the above example, ifconfig bridge1 addm eth3 would result in packets arriving on eth3 leaving tagged as vlan 5 in trunk1, vlan 6 in trunk0 and vice versa. -- Peter Jeremy pgphisjpKbXaP.pgp Description: PGP signature
Re: lagg problems on diskless client
On 2012-Mar-28 13:16:06 +0300, "Raif S. Berent" wrote: >I have some problems implementing lagg(4) on dual NIC's on the diskless >client side. It may be because my switch is a cheap, un-managed Gbit switch >or hopefully some other reason. I would like to either get lagg working >properly or find an alternative method of solving the problem. Whilst I haven't specifically done this, I have done diskless booting on a wired NIC and then switched to a wired/wifi lagg. Have a look at http://www.bugs.au.freebsd.org/dokuwiki/doku.php/laggdiskless >I concede that under this structure lagg's loadbalance or LACP are probably >not going to work. FEC & LACP require support at both ends and so won't work. loadbalance & roundrobin should work but aren't really appropriate unless your interfaces are identical. >In general, as soon as lagg is brought up, NIC pool no longer responds to >pings and gives an "I'm busy now" message. Yes. Once you create the lagg, the interfaces comprising it will no longer work standalone and you can't atomically migrate the IP address from re0 to lagg0 - hence the script linked from the above page. -- Peter Jeremy pgpCaYsWbFQTE.pgp Description: PGP signature
Re: lagg problems on diskless client
Please don't top post. On 2012-Apr-02 12:25:06 +0300, Beeblebrox wrote: >I had looked into failover with wireless and tried it before posting, but >got nowhere. Wired/wireless on a diskfull system should be trivial. >1. With below setup in diskless client's rc.conf, the client is able to >boot and gets to login screen: >ifconfig_re1="up ether 00:30:67:91:6c:c2" >cloned_interfaces="lagg0" >ifconfig_lagg0="up laggproto failover laggport re1 192.168.2.2 netmask >255.255.255.0" Assuming you're netbooting off re0, that looks correct. >2. ifconfig at that point shows all good: same mac addr and lagg0 active. >re0: flags=8843 metric 0 mtu 1500 >options=8209b >ether 00:30:67:91:6c:c2 >inet 192.168.2.2 netmask 0xff00 broadcast 192.168.2.255 This is wrong - there should't be an IP address on re0 at this point. >media: Ethernet autoselect (100baseTX ) >status: active >re1: flags=8843 metric 0 mtu 1500 >options=8209b >ether 00:30:67:91:6c:c2 >media: Ethernet autoselect (1000baseT ) >status: active >lagg0: flags=8843 metric 0 mtu 1500 >options=8209b >ether 00:30:67:91:6c:c2 >media: Ethernet autoselect >status: active >laggproto failover >laggport: re1 flags=5 > >Now if I go and unplug NIC10/100 on diskless client and "list folder", the >client will freeze - so failover does not switch. After some time passes, >client informs that NFS server 192.168.2.1 is not responding. lagg0 shows only one laggport so there's no failover. Are you sure you installed /etc/rc.d/lagg or an equivalent script? >PS- I mistakenly double-posted: >http://docs.freebsd.org/cgi/getmsg.cgi?fetch=39210+0+current/freebsd-net I replied to this one because it had a meaningful subject. -- Peter Jeremy pgpInbilVoAg2.pgp Description: PGP signature
Re: lagg problems on diskless client
On 2012-Apr-03 14:51:57 +0300, Beeblebrox wrote: >Slightly different point of view: Under this scenario of dikless clients >having dual NICs would CRAP be a choice to consider? From what I have read >it can offer loadbalancing but as I understand it's not really applicable >to diskless node situations? (Two amusing typos in one sentence). Based on what you've said so far, no. carp provides load-balancing or failover between two (or more) hosts. lagg provides load-balancing or failover between two (or more) NICs on one host. -- Peter Jeremy pgpQkf5nduxKw.pgp Description: PGP signature
Re: lagg problems on diskless client
On 2012-Apr-03 13:17:50 +0300, Beeblebrox wrote: >> Please don't top post. >Wasn't aware I was doing that. This is better I hope? Yes but there's no need to quote the entire mail you're replying to. >> Are you sure you installed /etc/rc.d/lagg or an equivalent script? >I had not noticed the link to the script at the bottom - I placed script in >DC's private conf//etc/rc.d then booted the DC. I got system freeze and >1 message: >ifconfig: interface re0 cannot change link address! >looking through the script I found the problem: lagg_tmp:=/mnt. My DC /root >is *ro* so I'll have to change it to another tmp. Actually, it doesn't matter that the root is RO, just that /mnt exists so it can be used as a mountpoint. And, BTW, I've just noticed that, whilst $lagg_tmp is parameterised. /mnt is also hard-coded in several places in the script. Sorry about that. > Considering that my /var >and /etc are md-mounted, using either seems out of the question. I also >have /tmp mounted as tmpfs. Can I mkdir -p /tmp/lagg and mount lagg_tmp >there or does it have to be an NFS shared location - what do you suggest? AFAIR, I use a separate ramdisk because /etc/rc.d/lagg runs very early and other mountpoints cannot be relied on. -- Peter Jeremy pgprrfdNpGEnW.pgp Description: PGP signature
dhclient behaviour on link status changes
/etc/devd.conf includes a rule to start dhclient when an Ethernet or 802.11 interface reports "link up", with a comment: "No link down rule exists because dhclient automatically exits when the link goes down." IMHO, this is the desired behaviour, unfortunately it's not the way dhclient actually behaves. In my experience, dhclient will exit when the interface goes down but ignores link status changes. Looking at the source, it seems to exit only when there's no usable route (by monitoring RTF_UP). dhclient does monitor the link status using SIOCGIFMEDIA but only at startup (it will exit if the link doesn't come up within 10s of dhclient starting) and during DHCP exchanges (if the link goes down when it's expecting a DHCP response then it exits). Can anyone explain the rationale behind the current behaviour? -- Peter Jeremy pgpBpISxeP8qg.pgp Description: PGP signature
Re: dhclient behaviour on link status changes
On 2012-Apr-05 07:17:49 +1000, Peter Jeremy wrote: >/etc/devd.conf includes a rule to start dhclient when an Ethernet or >802.11 interface reports "link up", with a comment: "No link down rule >exists because dhclient automatically exits when the link goes down." >IMHO, this is the desired behaviour, unfortunately it's not the way >dhclient actually behaves. In my experience, dhclient will exit when >the interface goes down but ignores link status changes. I found an easy way to correct the behaviour & submitted bin/166656 -- Peter Jeremy pgpiKcpO4qBUI.pgp Description: PGP signature
Re: dhclient behaviour on link status changes
On 2012-Apr-05 13:22:37 -0700, YongHyeon PYUN wrote: >On Thu, Apr 05, 2012 at 12:39:46PM +1000, Peter Jeremy wrote: >> On 2012-Apr-05 07:17:49 +1000, Peter Jeremy wrote: >> >/etc/devd.conf includes a rule to start dhclient when an Ethernet or >> >802.11 interface reports "link up", with a comment: "No link down rule >> >exists because dhclient automatically exits when the link goes down." >> >IMHO, this is the desired behaviour, unfortunately it's not the way >> >dhclient actually behaves. In my experience, dhclient will exit when >> >the interface goes down but ignores link status changes. >> >> I found an easy way to correct the behaviour & submitted bin/166656 >Hmm, wouldn't this make dhclient die when speed/duplex/flow control >of established connection is changed by admin or remote link partner? >For instance, >#ifconfig foo0 media mdiaopt flow If the speed/duplex/flow control change triggered a "LINK DOWN" "LINK UP" kernel message then, yes, that would cause dhclient to restart. I think that depends on the NIC. I guess a potential work-around would be to have dhclient ignore outages shorter than a configurable value. I hadn't considered that because it's not something that I ever do on a running system. (This investigation was prompted by my ISP's approach to address grooming - they just remotely reboot the cablemodem and expect clients to re-DHCP. Existing valid leases are just ignored. Since the FreeBSD dhclient ignores the link outage, I just lose Internet connectivity until I manually restart DHCP). -- Peter Jeremy pgpb45UOdBj73.pgp Description: PGP signature
Re: System doesn't detect unplugged network cable and doesn't set interface up properly with DHCP
On 2012-Jul-12 13:41:39 -0700, Yuri wrote: >I have the simplest possible DHCP setup: ifconfig_re0="DHCP" in >/etc/rc.conf. > >When the system boots, it gets connected fine. > >Now, I disconnect my laptop and connect it to another network. >When cable is disconnected, IP address of this interface stays the same, >old one is not removed. >When I plug it into another network, the same IP address stays. New IP >doesn't get set. This is bad. >So I have to manually do 'ifconfig re0 down && remove && >ifconfig re0 up'. This is a bug in dhclient - see PR bin/166656, which includes a fix. -- Peter Jeremy pgpo1p1TtzlQz.pgp Description: PGP signature
Re: System doesn't detect unplugged network cable and doesn't set interface up properly with DHCP
On 2012-Jul-31 09:43:00 -0400, John Baldwin wrote: >On Saturday, July 14, 2012 3:51:25 am Jason Hellenthal wrote: >> >> On Fri, Jul 13, 2012 at 11:20:36AM -0700, Yuri wrote: >> > But even if it exits, it leaves the IP address that it has set, which is >> > wrong. This IP address survives through the next DHCP setup process and >ends up being the second IP address. >> > Should be very easy to on exit remove any IP address that was set during >> > dhclient process lifetime. >> >> I couldnt agree more. Interface tear down is definately needed here. > >Hmmm, this does seem true. Do you either of you have any patches for this, >or Peter, can you extend your patch to do this? It's not a case that I initially considered and I don't currently have a patch for this. I'll have a look into it. -- Peter Jeremy pgpVPl5hJPMBM.pgp Description: PGP signature
Re: System doesn't detect unplugged network cable and doesn't set interface up properly with DHCP
On 2012-Jul-13 11:20:36 -0700, Yuri wrote: >On 07/13/2012 02:48, Peter Jeremy wrote: >> This is a bug in dhclient - see PR bin/166656, which includes a fix. > >I think this PR addresses part of the problem: dhclient doesn't exit when the >link goes down. >But even if it exits, it leaves the IP address that it has set, which is >wrong. This IP address survives through the next DHCP setup process and ends >up being the second IP address. >Should be very easy to on exit remove any IP address that was set during >dhclient process lifetime. I agree that it _should_ be easy to remove the existing address and the existing patch in that PR should already do that. Unfortunately, there seems to be another issue in dhclient that means that it isn't. -- Peter Jeremy pgp2wKcx4d2CT.pgp Description: PGP signature
Re: System doesn't detect unplugged network cable and doesn't set interface up properly with DHCP
On 2012-Aug-17 11:48:17 -0400, John Baldwin wrote: >Hmm, I think I see the issue. It doesn't export the existing lease info to >the script when running the FAIL action. I just tested this change and it >removed the old IP on my laptop when I tested it just now. I did some investigating during the week and came to pretty much the same patch. But the existing "don't remove an existing address" behaviour looked like a design decision and I went digging to find exactly what ip->client->active represented - and, in particular, whether in could represent an address that dhclient hadn't added to the interface. I did find that it could be read from the leases file but didn't have time to fully work through the code. If you're happy that this patch can't incorrectly remove a pre-existing IP address (I'm now reasonably confident that it can't), then I'm happy that it otherwise works. -- Peter Jeremy pgprjxR90uyyW.pgp Description: PGP signature
Incorrect ARP table entries
I've run into a problem where the ARP table on several of my hosts is
apparently spontaneously replacing correct entries with incorrect MAC
addresses. I've done some digging with tcpdump and can't identify the
cause. I've tried to look in the code but lost my way since ARP and
IP routing seem to be closely intermingled. I'm hoping someone might
be able to shed some light on why it is behaving the way it is.
A rough diagram of the relevant part of the network is:
+-++-+
| | [1]| |
| local || |
| || |[3] +-+
+++| || |
H [2] | switch || remot |
+++| || |
| || |[4] +-+
| peer || |
| || |
+-++-+
The hosts seeing the problem are running 8.2p2/amd64 ("local") and
8.3p3/i386 ("peer") using pf/carp for failover. The remote host
("remot") is a HP DL380 running FreeBSD (various between 7 and 10).
My problem is that the entry for the DL380 iLO ([3], in vlan 157) is
randomly having the correct MAC address replaced with the MAC address
of the main interface ([4]). Note that the iLO is a physically
separate NIC.
'=' are all dual GigE links bonded using lagg/lacp with about 73 vlans
inside them.
[1] MAC "local-nic", IP addresses "local-157" in the iLO vlan (157) and
"local-ip" in vlan 91.
[2] cross-over cables joining dual FastE NICs bonded using lagg/lacp
carrying pfsync traffic only.
[3] DL380 iLO connected to a non-trunked switch port in vlan 157.
MAC "remot-ilo", IP "remo-mgmt".
[4] DL380 bge interfaces. MAC "remot-nic" and "remot-ip" in vlan 91.
vlan 157 in configured at the switch end but not used at the host
end (no interface in vlan 157 is created).
Wheen I run:
tcpdump -e -i lagg0 'ether host remot-nic or arp or (vlan and arp)'
on "local", the only references to remot-nic or remot-ilo are
(starting following an "arp -d remo-mgmt"):
12:15:41.481523 local-nic > broadcast, vlan 157, ARP, Request who-has remo-mgmt
tell local-157
12:15:41.481853 remot-ilo > local-nic, vlan 157, ARP, Reply remo-mgmt is-at
remot-ilo
12:15:43.337303 remot-nic > local-nic, vlan 91, IPv4, remot-ip.123 >
local-ip.123: NTPv4
12:15:43.337854 local-nic > remot-nic, vlan 91, IPv4, local-ip.123 >
remot-ip.123: NTPv4
12:16:46.338434 remot-nic > local-nic, vlan 91, IPv4, remot-ip.123 >
local-ip.123: NTPv4
12:16:46.338968 local-nic > remot-nic, vlan 91, IPv4, local-ip.123 >
remot-ip.123: NTPv4
12:17:50.338196 remot-nic > local-nic, vlan 91, IPv4, remot-ip.123 >
local-ip.123: NTPv4
12:17:50.339027 local-nic > broadcast, vlan 91, ARP, Request who-has remot-ip
tell local-ip
12:17:50.339253 remot-nic > local-nic, vlan 91, ARP, Reply remot-ip is-at
remot-nic
12:17:50.339272 local-nic > remot-nic, vlan 91, IPv4, local-ip.123 >
remot-ip.123: NTPv4
12:17:52.338532 remot-nic > broadcast, vlan 91, ARP, Request who-has other1
tell remot-ip
12:18:01.338517 remot-nic > broadcast, vlan 91, ARP, Request who-has other2
tell remot-ip
12:18:53.337620 remot-nic > local-nic, vlan 91, IPv4, remot-ip.123 >
local-ip.123: NTPv4
12:18:53.338145 local-nic > remot-nic, vlan 91, IPv4, local-ip.123 >
remot-ip.123: NTPv4
12:19:12.499330 remot-ilo > broadcast, vlan 157, ARP, Request who-has local-157
(local-nic) tell remo-mgmt
12:19:12.499353 local-nic > remot-nic, vlan 157, ARP, Reply local-157 is-at
local-nic
And I find in /var/log/messages:
Aug 22 12:19:12 local kernel: arp: remo-mgmt moved from remot-ilo to remot-nic
on vlan157
The ARP mapping for remo-mgmt to remot-ilo was correct following the
ARP exchange at 12:15:41 but at 12:19:12, "local" responds to the
wrong MAC address when replying to an ARP request. In the intervening
period, there are no references to "remot-nic" in vlan 157 or any ARP
requests mentioning remo-mgmt.
--
Peter Jeremy
pgpF24vJB31sZ.pgp
Description: PGP signature
Re: Incorrect ARP table entries
On 2012-Aug-22 14:02:01 +1000, Peter Jeremy wrote: >I've run into a problem where the ARP table on several of my hosts is >apparently spontaneously replacing correct entries with incorrect MAC >addresses. I've done some digging with tcpdump and can't identify the >cause. I've tried to look in the code but lost my way since ARP and >IP routing seem to be closely intermingled. I'm hoping someone might >be able to shed some light on why it is behaving the way it is. I've done some more detailed trawling through tcpdump captures and found that this is another entry in the "never buy HP" collection. It turns out the iLO is sending ARP requests with the correct link- layer source MAC address in the Ethernet frame but the "sender hardware address" in the ARP request is wrong - and (as required by RFC826) FreeBSD is using the latter MAC address to update its ARP table. Note that this iLO has a physically separate NIC and doesn't have provision for shared NIC so there's no excuse for it's behaviour. RFC826 is fairly clear that FreeBSD is behaving correctly in using the "sender hardware address" in the ARP request (though it doesn't specifically address the case where that is different to the link-layer source address). My work-around is to use arp(8) to permanently wire the correct MAC address into the local ARP table. -- Peter Jeremy pgp6S4zfEJu8G.pgp Description: PGP signature
Re: bridging VLAN interfaces and STP
On 2012-Aug-26 08:12:51 -0400, "Dustin J. Mitchell" wrote: >On Sat, Aug 25, 2012 at 7:04 PM, Dustin J. Mitchell wrote: >> Hey folks. I'm trying to set up a system with one 802.1q-tagged >> upstream, and a few untagged interfaces. So I'd like to bridge the >> vlan(4) interfaces on vr1 to specific other interfaces. Can you provide ifconfig output covering all the relevant interfaces. >And I can verify that STP's *not* working on those interfaces because >I just inadvertently created a forwarding loop. I'm not sure if this is intentional. >Incidentally, it makes sense in retrospect, but the if_bridge(4) >manpage doesn't mention that gateway_enable is required for bridging >to actually forward packets. If this is true, it's definitely wrong and a regression. gateway_enable relates to routing not bridging. -- Peter Jeremy pgp0tKR7gtvaX.pgp Description: PGP signature
Re: Problem with link aggregation + sshd
On 2012-Aug-21 23:18:15 +0200, Giulio Ferro wrote: >Scenario : freebsd 9 stable (yesterday) amd64 on HP server with 4 nic (igb) I have used lagg/lacp on 7.x, 8.x, 9.x and 10.x and haven't seen this problem. Can you please provide ifconfig output for all interfaces. -- Peter Jeremy pgpLMiR9Ws9DE.pgp Description: PGP signature
Re: Problem adding more than 8 network adapters
On 2012-Aug-28 11:44:44 +0200, Gustau Pérez i Querol wrote: > I'm running FreeBSD 9.1 RC1/AMD64 with VirtualBox. The problem I'm >facing is that I can't use more than 8 network adapters plugged to the >virtual machine. ... >I don't know if it's a net@ problem or maybe it is a problem with >the emulated PCI-bridge and then stable@ should be contacted. Also, I'm >not sure if a real machine would support more than 8 network adapters or >not. Any hints would be appreciated. I don't think I've ever used more than 6 physical NICs in a host but don't know of any reason for >8 to not work. Can you please post a "pciconf -lv" from FreeBSD and the equivalent "lspci" from Linux. A FreeBSD verbose boot log might also help. -- Peter Jeremy pgpXqtGGMbTJs.pgp Description: PGP signature
Re: bridging VLAN interfaces and STP
Sorry for the delay, Real Life™ intervened. On 2012-Aug-27 07:45:41 -0400, "Dustin J. Mitchell" wrote: >On Mon, Aug 27, 2012 at 5:49 AM, Peter Jeremy wrote: >> On 2012-Aug-26 08:12:51 -0400, "Dustin J. Mitchell" >> wrote: >>>On Sat, Aug 25, 2012 at 7:04 PM, Dustin J. Mitchell >>>wrote: >>>> Hey folks. I'm trying to set up a system with one 802.1q-tagged >>>> upstream, and a few untagged interfaces. So I'd like to bridge the >>>> vlan(4) interfaces on vr1 to specific other interfaces. ... >bridge10: flags=8843 metric 0 mtu 1500 >ether 02:f4:a1:63:5a:0a >nd6 options=21 >id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15 >maxage 20 holdcnt 6 proto rstp maxaddr 100 timeout 1200 >root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0 >member: vr3 flags=143 >ifmaxaddr 0 port 4 priority 128 path cost 55 >member: vr2 flags=143 >ifmaxaddr 0 port 3 priority 128 path cost 55 >member: vr1.10 flags=143 >ifmaxaddr 0 port 9 priority 128 path cost 20 >bridge20: flags=8843 metric 0 mtu 1500 >ether 02:f4:a1:63:5a:14 >nd6 options=21 >id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15 >maxage 20 holdcnt 6 proto rstp maxaddr 100 timeout 1200 >root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0 >member: vr0 flags=143 >ifmaxaddr 0 port 1 priority 128 path cost 55 >member: vr1.20 flags=143 >ifmaxaddr 0 port 10 priority 128 path cost 20 That looks like RSTP is enabled on both bridge10 and bridge20 but is not seeing incoming [R]STP packets. Are you sure the switch connected to vr1 is configured with per-VLAN STP (this is probably not the switch default). Have you tried running tcpdump on vr1 and checked that you are seeing STP packets within the VLANs. >gateway_enable="YES" >firewall_enable="YES" >firewall_type="OPEN" gateway_enable="YES" will let the system route packets between bridge10 and bridge20 but shouldn't have any effect on bridging packets between (eg) vr1.10, vr2 & vr3. -- Peter Jeremy pgpDlRhZ6DTnz.pgp Description: PGP signature
Re: Bad routing performance on 500Mhz Geode LX with CURRENT, ipfw and mpd5 (was: ipfw, "ip|all" proto and PPPoE -- does PPPoE packets passed to ipfw?)
On 2012-Aug-31 00:17:11 +0400, Lev Serebryakov wrote: > Is it possible to use gprof with kernel? As here is no userland >processes involved: PPPoE is porcessed by netgrpah, routing & ipfw is >kernel stuff too... Since no-one else has mentioned it, see the '-p' option to config(8) and kgmon(8). There's also dtrace. -- Peter Jeremy pgp4Ejrvxyflt.pgp Description: PGP signature
Re: lagg failover issue
Adrian, On 2012-Aug-31 04:29:53 -0700, Adrian Chadd wrote: >You can't override set the outbound MAC address of a wireless station. >It associates with the MAC address of the card/vap/device. The AP >_will_ store that MAC address in its node table. Are you saying I can't portably do the following: # ifconfig ath0 ether 00:11:22:33:44:55 # ifconfig create wlan0 wlandev ath0 ssid my_net up My understanding was that the first line changes the MAC associated with ath0. The second line then creates a wlan device and allows ath0 to associate with an AP with ssid "my_net" - and this association will be performed using the updated MAC address. Which part of this doesn't work? >What you really want is for the same IP to exist but only both >interfaces and have the source interface/MAC seamlessly change. Actually, lagg(4) requires all associated interfaces to have the same MAC address - it doesn't change them during operation. Normally, it updates the MAC address when it does the "addm" but this doesn't work for "addm wlan0" (presumably for the reasons you describe) but manually changing the MAC address of the WiFi NIC before creating the wlan device avoids this. -- Peter Jeremy pgpSyXX5VtidH.pgp Description: PGP signature
Re: To SMP or not to SMP
On 2013-Jan-07 18:25:58 -0800, Barney Cordoba wrote: >I have a situation where I have to run 9.1 on an old single core >box. Does anyone have a handle on whether it's better to build a non >SMP kernel or to just use a standard SMP build with just the one >core? Another input for this decision is kern/173322. Currently on x86, atomic operations within kernel modules are implemented using calls to code in the kernel, which do or don't use lock prefixes depending on whethur the kernel was built as SMP. My proposed change changes kernel modules to inline atomic operations but always include lock prefixes (effectively reverting r4). I'm appreciate anyone who feels like testing the impact of this change. -- Peter Jeremy pgpA2uS_hItrK.pgp Description: PGP signature
Re: [JNPR] Proposal for changes to network device drivers and network stack (RFC)
On 2013-Jan-17 14:38:06 -0500, "Stephen J. Kiernan" wrote: >The patch also includes moving zlib.[ch] and zlibutil.h out of net and >into sys/libkern (for the .c) and sys/sys (for the .h). Good. >It really doesn't make much sense for that code to live in net, >especially when so many things which are not the network stack utilize >it. One thing that currently doesn't is ZFS - which has its own copy. It would be nice if ZFS could use the common copy. >Is that going to be a problem? Should simple stubs be added in the >original locations in net/ to include the one in sys/ now? IMHO, no. zlib wasn't an advertised API so nothing outside the base OS should be using it. If you've moved all the kernel code to use the new location, that should be enough. -- Peter Jeremy pgpPlJ_hyRXBS.pgp Description: PGP signature
Re: [Panic] Dummynet/IPFW related recurring crash.
On 2011-Feb-20 01:39:00 +0100, Pawel Tyll wrote: >Since nobody came up with any interest in having this properly >investigated, then I suppose I'm the only one that uses dummynet for >some larger-scale traffic shaping - maybe that's my mistake? I'm using dummpnet+pf (not ipfw) on (roughly) FreeBSD 7.2 quite extensively for traffic shaping. I have about 20 pipes varying from 600kbps to 100Mbps all with ~9msec delay. There's a background load of at least 10Mbps with peaks to several times that (and several 2Mbps pipes are virtually permanently saturated). The system has nearly 80 VLANs and uses CARP and lagg/LACP (1 bge and 1 em NIC) for redundancy. The system has an uptime of several months. I haven't responded before because I can't offer any solutions. All I can say is that I've been successfully using dummynet with ipfw or pf for about a decade without any stability issues. -- Peter Jeremy pgpPOChNt5SGB.pgp Description: PGP signature
Diskless booting issues
For various reasons, I occasionally boot my netbook as a diskless client of my main server (this is a quick/easy way to test upgrades without needing to install them). Since I still like to use it as a netbook in this mode (ie, wander around the house), I've run into a couple of issues that I haven't been able to resolve myself and would like some assistance with. I'm running FreeBSD-8.2 i386 from the beginning of March on an original Acer Aspire One. First problem: If it loses network connectivity (ie, I unplug the network cable) for more than a minute or so, it seems to lockup and need a hard reboot, even if the network is restored. I'm a bit vague on this because it's been running X on the occasions I've seen this and I just get a blank screen with no responsiveness from the keyboard and it isn't pingable, though the ethernet link light is on. Second problem: When running on the local SSD, I have lagg setup so it seamlessly switches between wired and wifi (this is really nice). Partially to resolve the above and partially to improve portability, I'd like to do the same when running diskless but can't work out how to make it work. The relevant bits of my native rc.conf look like: ifconfig_re0="up" ifconfig_ath0="ether XX:XX:XX:XX:XX:XX" wlans_ath0="wlan0" ifconfig_wlan0="WPA" cloned_interfaces="lagg0" ifconfig_lagg0="SYNCDHCP laggproto failover laggport re0 laggport wlan0" Gluing this in the diskless rc.conf gives me a hang during startup, as does changing 'SYNCDHCP' to 'inet MYHOST' and adding 'up'. Adding a 'set -x' to the startup shows that it executes: ifconfig lagg0 inet MYHOST laggproto failover laggport re0 laggport wlan0 up ifconfig lagg0 up and hangs at this point (though the kernel reports lagg0 up). ^T shows it in "connect" state. I've tried working through the commands manually and basically, any "disk" access after the first ifconfig above will hang. In diskless mode, re0 is "up" with the correct IP address when init(8) starts and I presume the kernel is getting upset at the IP address migrating from re0 to lagg0. I have considered trying to use lagg0 (made up only of re0) as the boot device but I can't work out how to achieve this (in particular, how to "up" re0 when that's not part of the diskless boot sequence). Does anyone have any suggestions? -- Peter Jeremy pgpssVxm4ejLN.pgp Description: PGP signature
Re: Diskless booting issues
I've managed to resolve one of the problems I raised.
On 2011-Apr-11 07:10:12 +1000, Peter Jeremy wrote:
>For various reasons, I occasionally boot my netbook as a diskless
>client of my main server (this is a quick/easy way to test upgrades
>without needing to install them).
Since I got a query about this, this is "diskless" in the old Sun
diskless workstation sense - the filesystem is mounted RW so the
netbook behaves normally except that the filesystem is remote rather
than the local SSD. This is different to the approach assumed by
/etc/rc.initdiskless where the remote filesystem is RO with some
magic directory trees that are copied to a local RW ramdisk.
>First problem: If it loses network connectivity (ie, I unplug the
>network cable) for more than a minute or so, it seems to lockup and
>need a hard reboot, even if the network is restored.
I haven't gotten anywhere with this.
>Second problem: When running on the local SSD, I have lagg setup so
>it seamlessly switches between wired and wifi (this is really nice).
>Partially to resolve the above and partially to improve portability,
>I'd like to do the same when running diskless but can't work out how
>to make it work.
>
>The relevant bits of my native rc.conf look like:
> ifconfig_re0="up"
> ifconfig_ath0="ether XX:XX:XX:XX:XX:XX"
> wlans_ath0="wlan0"
> ifconfig_wlan0="WPA"
> cloned_interfaces="lagg0"
> ifconfig_lagg0="SYNCDHCP laggproto failover laggport re0 laggport wlan0"
>
>Gluing this in the diskless rc.conf gives me a hang during startup, as
>does changing 'SYNCDHCP' to 'inet MYHOST' and adding 'up'.
Turns out that
> ifconfig lagg0 inet MYHOST laggproto failover laggport re0 laggport wlan0 up
results in MYHOST existing on both re0 and lagg0 and this causes the
network to completely stop - even if you later remove one of the IP
addresses. You need to remove the IP address from re0 before adding
it to lagg0. This presents a bit of a catch-22 since once I remove the
IP address from re0, I no longer have access to a filesystem to run
an ifconfig to add the IP adddress to lagg0.
My solution was to use a temporary ramdisk to hold a statically-linked
copy of ifconfig in a new rc.d script (see attached) to handle moving
the IP address from re0 to lagg0 and then let the existing netif handle
the wifi side with te following rc.conf entries (cf above):
ifconfig_ath0="ether XX:XX:XX:XX:XX:XX"
wlans_ath0="wlan0"
ifconfig_wlan0="WPA"
ifconfig_lagg0="laggport wlan0"
--
Peter Jeremy
#!/bin/sh
#
# Create lagg0 if necessary and flip current IP address from re0 to lagg0
# PROVIDE: lagg
# REQUIRE: FILESYSTEMS
# BEFORE: netif
# KEYWORD: nojail
. /etc/rc.subr
. /etc/network.subr
name="lagg"
start_cmd="lagg_start"
stop_cmd=":"
cmdifn=
: ${lagg_phys:=re0}
: ${lagg_dev:=lagg0}
: ${lagg_tmp:=/mnt}
lagg_start()
{
# Ensure that the lagg device exists
ifexists "$lagg_dev" || ifconfig "$lagg_dev" create
# Create a ramdisk to temporarily hold a copy of ifconfig
md_dev=$(/sbin/mdconfig -a -t swap -s 8m)
mdmfs -S -s 8m -o async $md_dev "$lagg_tmp"
# Copy /rescue (because it's statically linked)
tar -cf - -C /rescue . | tar -xf - -C "$lagg_tmp"
### Actually flip the interface
# Wanted IP address
addr=$(/mnt/ifconfig "$lagg_phys" | grep 'inet ')
# Delete address from existing interface
/mnt/ifconfig "$lagg_phys" delete
# Setup new interface
/mnt/ifconfig "$lagg_dev" $addr laggport "$lagg_phys" up
# Unwind ramdisk
umount /mnt
mdconfig -d -u ${md_dev#md}
}
load_rc_config $name
run_rc_command "$@"
pgpOJsz3z6W6w.pgp
Description: PGP signature
Statistics collection broken in "new" dummynet
I have been using dummynet(4) to do traffic shaping for simulated WANs for over a decade now and it has been very effective - thanks Luigi. I am currently looking at migrating the network simulator from 7.1 to 8.2 and have noticed that the statistics reported are now meaningless. Instead of reporting cumulative statistics, it now appears to reset them regularly - apparently whenever the pipe is empty. Sample results from 7.1 (currently inactive): 00224: 2.000 Mbit/s9 ms 64 KB 1 queues (1 buckets) droptail mask: 0x00 0x/0x -> 0x/0x BKT Prot ___Source IP/port Dest. IP/port Tot_pkt/bytes Pkt/Byte Drp 0 udp 192.168.224.183/0 192.168.216.179/0 5404902 598099622 00 0 Sample results from 8.2 (currently active simulator): 00224: 2.000 Mbit/s 18 ms burst 0 q131296 64 KB 0 flows (1 buckets) sched 65760 weight 0 lmax 0 pri 0 droptail sched 65760 type FIFO flags 0x0 0 buckets 1 active 0 ip 0.0.0.0/0 0.0.0.0/02 1785 00 0 (and most of the time, the last line doesn't appear). I have checked a recent 9.0-BETA1 and it is still broken. Looking at the dummynet.txt file, I cannot see this mentioned. I have looked through the source and it does appear that scheduler instances are marked inactive in serve_sched() once they have no packets queued and are then garbage-collected via drain_scheduler_cb(). Is this the intent? If so, how can statistics be collected? -- Peter Jeremy pgpzud9JhB4U3.pgp Description: PGP signature
Re: Statistics collection broken in "new" dummynet
On 2011-Aug-23 04:20:43 +0200, Luigi Rizzo wrote: >Deleting entries saves memory and speeds up lookups in the data >structures, but is extremely annoying if you want to collect per-flow >statistics. Which I do. >If i remember well there is a knob to enable/disable removal of >useless pipes/queues but i am not sure if there is a sysctl or >timer or other mechanism to control it. Thanks - that was enough of a pointer to find net.inet.ip.dummynet.expire -- Peter Jeremy pgpyI8uFcdMZc.pgp Description: PGP signature
Re: Patch to enable our tcpdump to handle CARP
On 2011-Oct-19 16:20:27 -0400, George Neville-Neil wrote: >I've been trying to debug CARP problems of late. I noticed that our >tcpdump didn't have CARP support. bin/124825 includes patches to cover both pfsync & CARP. I have patched 8.x but can't recall if the patches still apply to 9.x/10.x. -- Peter Jeremy pgp9nu4ltpF4S.pgp Description: PGP signature
Re: Re[2]: Call for testers: ng_netflow with v9 and IPv6 support
On 2009-Sep-07 11:54:55 +0400, Dennis Yusupoff wrote: >By the way, what's about this one: >--- > The ng_netflow node type does not fill in AS numbers. This is due to the ... >--- > >Is any chance to see it in, for example, 8.0? New feature cutoff for 8.0 was several months ago. Once the code exists, it may be a candidate for inclusion in a future 8.x release. -- Peter Jeremy pgp97m7g6QHHU.pgp Description: PGP signature
New tcpdump in 8.x
[Please excuse long lines] Who has used tcpdump on FreeBSD 8.x and likes it? Is it just me or is it now far harder to investigate network problems using it? Prior to 8.x, the default output includes SEQ number ranges for any TCP packets with data, so a 'tcpdump -n' looks like the following and it's immediately obvious that there's 2920 bytes of data missing: 08:48:32.137596 IP 134.159.99.234.60834 > 122.106.250.30.2202: . 221537:222997(1460) ack 2609 win 65535 08:48:32.138492 IP 134.159.99.234.60834 > 122.106.250.30.2202: . 222997:224457(1460) ack 2609 win 65535 08:48:32.139601 IP 122.106.250.30.2202 > 134.159.99.234.60834: . ack 224457 win 64240 08:48:32.145623 IP 134.159.99.234.60834 > 122.106.250.30.2202: . 227377:228837(1460) ack 2609 win 65535 08:48:32.146703 IP 122.106.250.30.2202 > 134.159.99.234.60834: . ack 224457 win 65535 The same output on 8.x looks like the following. Whilst the last ACK packet looks anomolous, there's no useful information to analyse further. 08:48:32.137596 IP 134.159.99.234.60834 > 122.106.250.30.2202: Flags [.], ack 2609, win 65535, length 1460 08:48:32.138492 IP 134.159.99.234.60834 > 122.106.250.30.2202: Flags [.], ack 2609, win 65535, length 1460 08:48:32.139601 IP 122.106.250.30.2202 > 134.159.99.234.60834: Flags [.], ack 224457, win 64240, length 0 08:48:32.145623 IP 134.159.99.234.60834 > 122.106.250.30.2202: Flags [.], ack 2609, win 65535, length 1460 08:48:32.146703 IP 122.106.250.30.2202 > 134.159.99.234.60834: Flags [.], ack 224457, win 65535, length 0 In order to see the SEQ numbers (which are essential to make sense of the capture), you need to add '-vv' - which turns the output into: 08:48:32.137596 IP (tos 0x0, ttl 52, id 32485, offset 0, flags [DF], proto TCP (6), length 1500) 134.159.99.234.60834 > 122.106.250.30.2202: Flags [.], seq 221537:222997, ack 2609, win 65535, length 1460 08:48:32.138492 IP (tos 0x0, ttl 52, id 32486, offset 0, flags [DF], proto TCP (6), length 1500) 134.159.99.234.60834 > 122.106.250.30.2202: Flags [.], seq 222997:224457, ack 2609, win 65535, length 1460 08:48:32.139601 IP (tos 0x8, ttl 63, id 46554, offset 0, flags [DF], proto TCP (6), length 40) 122.106.250.30.2202 > 134.159.99.234.60834: Flags [.], cksum 0xe759 (correct), seq 2609, ack 224457, win 64240, length 0 08:48:32.145623 IP (tos 0x0, ttl 52, id 32489, offset 0, flags [DF], proto TCP (6), length 1500) 134.159.99.234.60834 > 122.106.250.30.2202: Flags [.], seq 227377:228837, ack 2609, win 65535, length 1460 08:48:32.146703 IP (tos 0x8, ttl 63, id 46555, offset 0, flags [DF], proto TCP (6), length 40) 122.106.250.30.2202 > 134.159.99.234.60834: Flags [.], cksum 0xe24a (correct), seq 2609, ack 224457, win 65535, length 0 Whilst it's now possible to work out that there's 2920 bytes of data missing, this information is mixed up in so much other extraneous information that the dump is almost useless. In particular, it's no longer possible to scan a tcpdump output and easily see packet loss or out-of-order delivery. -- Peter Jeremy pgpnKFDXzBzl1.pgp Description: PGP signature
Re: dummynet dropping too many packets
On 2009-Oct-04 18:47:23 +0500, rihad wrote: >Hi, we have around 500-600 mbit/s traffic flowing through a 7.1R Dell >PowerEdge w/ 2 GigE bce cards. There are currently around 4 thousand ISP >users online limited by dummynet pipes of various speeds. According to >netstat -s output around 500-1000 packets are being dropped every second >(this accounts for wasting around 7-12 mbit/s worth of traffic according >to systat -ifstat): This has been a most interesting thread. A couple of comments: Traffic shaping only works cleanly on TCP flows - UDP has no feedback mechanism and so will not automatically throttle to fit into the available bandwidth, potentially leading to high packet drops within dummynet. Is it possible that some of your customers are heavily using UDP? Have you tried allowing just UDP traffic to bypass the pipes to see if this has any effect on drop rate? The pipe lists you posted showed that virtually all the packet drops are associated with one or two IP addresses. If this is really true, rather than a measurement artifact, you might find it useful to tcpdump those addresses and see if there's anything unusual in the data being passed. Also, if you monitor the pipe lists following a cold start, do those addresses appear early and just not show any packet loss until the total number of users builds up or do they not appear until later and immediately show packet loss? Looking at how 'output packets dropped due to no bufs, etc.' is counted (ipstat.ips_odropped), if you run 'netstat -id', do you see a large number of drops on bce1 (consistent with the "output packets dropped" counts) or not? This will help narrow down the codepath being followed by dropped packets. Since the problem only appears to manifest when table(0) exceeds 2000 entries, have you considered splitting (at least temporarily) that table (and possibly table(2)) into two (eg table(0) and table(4))? This would help rule out an (unlikely) problem with table sizes. Doin so would require the application to split the users across both tables (eg round-robin or based on one of the bits in the IP address) and then duplicating the relevant ipfw rules - eg: 01060 pipe tablearg ip from any to table(0) out recv bce0 xmit bce1 01061 pipe tablearg ip from any to table(4) out recv bce0 xmit bce1 01070 allow ip from any to table(0) out recv bce0 xmit bce1 01071 allow ip from any to table(4) out recv bce0 xmit bce1 (And I agree that re-arranging rules to reduce the number of repeated tests should improve ipfw efficiency). The symptoms keep making me think "lock contention" - but I'm not sure how to measure that cheaply (AFAIK, LOCK_PROFILING is comparatively expensive). Finally, are you running i386 or amd64? -- Peter Jeremy pgpGJqTOzuPXQ.pgp Description: PGP signature
Re: VLANs, routing, multicast and HP switches, oh my...
On 2010-Jun-14 13:17:06 -0700, Kurt Buff wrote: >We'll be simulating installations of our software and hardware for >customer installations that have WANs between sites, with several >complementary applications, including a multicast app that is critical >to the whole effort. While it's a bit much to expect us to be able to >simulate a WAN at this point, I want to be able to simulate at least >two subnets with routed multicast between them. I have been running FreeBSD-based WAN simulators at work for more than a decade. As with you, the driver has been to replicate customer configurations for testing purposes. My current system provides about 60 different subnets (using VLANs) and about 12 simulated WANs. It uses two FreeBSD boxes providing NAT between the corporate intranet and various test LANs, as well as routing and WAN simulation between LANs. Each box runs VLANs over LACP (via lagg(4)) through dual NICs to redundant switches. The boxes provide automatic failover via carp(4). The WAN simulation is done using dummynet(4) and the NAT and CARP via pf(4). By default, pf and dummynet don't work together but Ermal Luçi wrote some patches that I'm using together with some local adaption. Whilst I have run into some rough edges, the system has been very successful overall. >take your point about the packets traveling over the same wire. It >would be best if I could get a multiport router - perhaps a layer3 >switch (I'd love to get them an HP 3400cl) - but that costs much money >that I don't have to spend at the moment. My recommendation is that you just use managed switches that support VLANs and push all the traffic into the FreeBSD box via a trunk, then let the FreeBSD box handle all the routing. -- Peter Jeremy pgpG1zHz1ZhKG.pgp Description: PGP signature
Re: Server network interface problem?
On 2010-Sep-22 14:32:52 -0400, Carlos Kamtha wrote: >To solve this problem, i plugged out the network cable and plugged it back in. >... >a.) Could this be an issue with the driver on this release for em0? Possibly - there have been some issues with em(4) and some chipsets. Alternatively, it could equally well have been a glitch on the associated switchport. >b.) Why was I not able to ssh to the client servers while the NFS server was >down? Logging into a client entails filesystem accesses and if any of those filesystems are NFS mounted then those accesses will block if the NFS server is non-responding. Note that by default, sshd will search /lib, /usr/lib and /usr/local/lib (as well as subordinate compat libraries) to dlopen() nss modules - which means that a local root and /usr could still block if you have a NFS mounted /usr/local. -- Peter Jeremy pgphPQD1bqcxe.pgp Description: PGP signature
Re: SOLVED (was Re: Problem clarification (was: Problems with vlan + carp + alias))
On 2008-Jun-26 22:06:11 +0200, Giulio Ferro <[EMAIL PROTECTED]> wrote: > I guess what I could do was to "poison" their arp cache for each >address with a "is-at" message. Is there a way to force the sending >of these messages for all the addresses of an interface? The kernel should send out gratuitous ARP requests whenever you assign an address to an interface. You could confirm that this is happening by tcpdumping the interface whilst you add aliases. Rummaging around in ports, you might find net/arping or net/p5-Net-ARP useful if you want to manually generate gratuitous ARP requests. -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. pgpzclAQNBmMO.pgp Description: PGP signature
Re: SOLVED (was Re: Problem clarification (was: Problems with vlan + carp + alias))
On 2008-Jun-27 22:59:56 +0200, Giulio Ferro <[EMAIL PROTECTED]> wrote: >Peter Jeremy wrote: >> The kernel should send out gratuitous ARP requests whenever you assign >> an address to an interface. You could confirm that this is happening >> by tcpdumping the interface whilst you add aliases. >> >I have bad news for you all: this doesn't seem to happen for alias >interfaces. I've just tried to replicate what happened days >ago. I've verified that only the base (non alias) interface sends >proper is-at messages. The aliases don't I'm not seeing this on physical interfaces. I can't immediately verify this on VLAN interfaces but could at work next week. Adding 192.168.123.253 as an alias on FreeBSD 7.0-STABLE (mid May): 08:21:39.899113 00:0f:b0:74:9c:a3 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: arp who-has 192.168.123.253 tell 192.168.123.253 Adding 192.168.123.253 as an alias on FreeBSD 6.3-PRERELEASE: 08:24:21.077266 00:12:0e:20:2b:ad > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: arp who-has 192.168.123.253 tell 192.168.123.253 -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. pgpmwFmgmkYdF.pgp Description: PGP signature
arplookup x.x.x.x failed: host is not on local network
I'm occasionally seeing pairs of messages like the following on my NAT host: arplookup 192.168.181.114 failed: host is not on local network arpresolve: can't allocate route for 192.168.181.114 In my particular configuration, there are dual subnets between the NAT and target host. My initial assumption was that the request was arriving on the other subnet and I added if_xname to the arplookup printf() - but that shows that interface matches the IP address. I've looked back through the mailing lists but the previous reports of this problem don't match my scenario. I've seen this with FreeBSD 5.3, 6.2 and 7.0. The (in)frequency of the problem makes me wonder if it's actually a resource exhaustion problem. Has anyone got any suggestions? -- Peter Jeremy pgpxzJAMP0wQz.pgp Description: PGP signature
Re: arplookup x.x.x.x failed: host is not on local network
OK, my responses to the replies so far. One off-line reply requested a topology and netstat output. Since the toplogy may be relevant, below is an extremely simplified approximation (the real network has about 60 subnets and about 70 hosts, each appearing in between two and four subnets). Corp Network 192.168.10.0/24 | 192.168.12.0/24 +--+-+--| | |--+-+-+ .1| .2| .254| | |.254.3| .4| +---+ +---+ +---+ +---+ +---+ | | | | | | | | | | | host1 | | host2 | | NAT | | host3 | | host4 | | | | | | | | | | | +---+ +---+ +---+ +---+ +---+ .1| .2| .254| |.254.3| .4| +--+-+--| |--+-+-+ 192.168.11.0/24 192.168.13.0/24 The errors appear to be randomly spread across hosts and subnets. It does not appear consistently and seems to correlate with load (I am getting significant numbers at present and the NAT host is routing about 90Kpps and 100MBps if netstat can be believed). The problem also shows up on another interior routing host that has visibility across the internal networks so it isn't related to NAT or directly related to host load (that host is only seeing about 3.5Kpps - but is also a much slower host). I have managed to capture a tcpdump across the error. syslog reported: Jul 3 21:28:30 kernel: arplookup 192.168.169.26 failed: host is not on local network and the packets for that host during that second are: 21:28:30.320340 00:0b:cd:d6:66:26 > 00:03:ba:ab:6f:ef, ethertype 802.1Q (0x8100), length 64: vlan 169, p 0, ethertype IPv4, IP (tos 0x0, ttl 64, id 29304, offset 0, flags [none], length: 28) 192.168.169.26 > 192.168.169.111: icmp 8: echo request seq 35079 21:28:30.320429 00:d0:b7:20:8f:ee > 00:03:ba:ab:6f:ef, ethertype 802.1Q (0x8100), length 46: vlan 168, p 0, ethertype IPv4, IP (tos 0x0, ttl 63, id 29304, offset 0, flags [none], length: 28) 192.168.169.26 > 192.168.169.111: icmp 8: echo request seq 35079 21:28:30.320445 00:0b:cd:d6:66:26 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 169, p 0, ethertype ARP, arp who-has 192.168.169.250 tell 192.168.169.26 21:28:30.320459 00:0b:cd:d6:66:26 > 00:d0:b7:20:8f:ee, ethertype 802.1Q (0x8100), length 64: vlan 169, p 0, ethertype IPv4, IP (tos 0x0, ttl 64, id 29307, offset 0, flags [none], length: 28) 192.168.169.26 > 192.168.169.250: icmp 8: echo request seq 35079 21:28:30.320493 00:d0:b7:20:8f:ee > 00:0b:cd:d6:66:e4, ethertype 802.1Q (0x8100), length 46: vlan 168, p 0, ethertype IPv4, IP (tos 0x0, ttl 64, id 15305, offset 0, flags [none], length: 28) 192.168.169.250 > 192.168.169.26: icmp 8: echo reply seq 35079 21:28:30.320531 00:d0:b7:20:8f:ee > 00:0b:cd:d6:66:26, ethertype 802.1Q (0x8100), length 46: vlan 169, p 0, ethertype ARP, arp reply 192.168.169.250 is-at 00:d0:b7:20:8f:ee (this was captured MAC 00:d0:b7:20:8f:ee). Possibly, I'm seeing packet leakage from the switches and that is confusing FreeBSD - definitely the first packet above should not be visible. On 2008-Jul-03 09:05:15 +0200, Daniel Ponticello <[EMAIL PROTECTED]> wrote: >i'm having exactly the same problem, but without NAT configuration. Just >a simple host on network 192.168.170.xxx >that when tries to reach an host on 192.168.181.xxx: it gives the same error Except that in my case, the addresses _are_ local. On 2008-Jul-03 02:16:30 -0500, David DeSimone <[EMAIL PROTECTED]> wrote: >My theory is that this is a response to ARP requests. ARP requests are >broadcast, so the BSD box hears someone asking for this IP, but cannot >find it on any local interfaces, and so complains that it cannot >construct a proper reply. Except that the address it's complaining about is on a local subnet. Interestingly, in the above case, the host is spuriously seeing a packet and has re-routed it via vlan168 - which is the wrong subnet, though the destination host will still see it there. On 2008-Jul-03 10:48:22 +0300, Stefan Lambrev <[EMAIL PROTECTED]> wrote: >I bet 192.168.181.114 have a wrong network mask ;) You lose. -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. pgpWSmglYC3aZ.pgp Description: PGP signature
Re: Freebsd IP Forwarding performance (question, and some info) [7-stable, current, em, smp]
On 2008-Jul-07 13:25:13 -0700, Julian Elischer <[EMAIL PROTECTED]> wrote: >what you need is a speculative prefetch where you an tell teh >processor "We will probably need the following address so start >getting it while we go do other stuff". This looks like the PREFETCH instructions that exist in at least amd64 and SPARC. Unfortunately, their optimal use is very implementation- dependent and the AMD documentation suggests that incorrect use can degrade performance. -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. pgptHl9lUe7aI.pgp Description: PGP signature
Re: smbmount / smbclient : strangely varying transfer speeds
On 2008-Jul-07 16:15:40 +, Achim <[EMAIL PROTECTED]> wrote: >Performance with a single client is degraded when the client is smbmount and >downloading. >With a second transfer in any direction, performance becomes better, to about >3.5 resp. 8 MB/s depending on the second connection up- or downloading. >Unlike smbmount, single smbclient transfers yield acceptable results. Is this two transfers between a single server and single client or between a single server and two clients? In the former case, you might like to try a transfers involving two clients or two servers to try and identify which end is behaving oddly. -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. pgpmeZrUKgFAm.pgp Description: PGP signature
Re: too many open file descriptors messages since bind 9.4.2-P1 (port dns94)
On 2008-Jul-15 16:09:17 -0700, Bakul Shah <[EMAIL PROTECTED]> wrote: >IIRC, when poll() returns n, you only look at the first n >values in the pollfd array so it is a win when you expect a >very small number of fds to be ready. In the select case you >have to test the bit array until you see the last ready fd. No. Both poll(2) and select(2) return the number of FDs ready for I/O. You need to scan the pollfd or fd_set array until you find that many FDs ready. poll(2) is a win if you only need to test a small number of FDs compared to the number of FDs that the process has open. In the case of bind, you have a large number of FDs to test, of which you are only expecting a very small number to be ready - if you don't treat fd_set as opaque, select(2) allows you to quickly skip large (roughly wordsize) chunks of un-interesting FDs. Note that, based on sys_generic.c in 7.x and -CURRENT, poll(2) is limited to checking FD_SETSIZE descriptors, whilst select(2) has no upper limit. -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. pgpeMmtesf5SB.pgp Description: PGP signature
Re: "ping" with packets larger then 25152 bytes fails.
On 2008-Jul-16 10:41:57 +0300, Eitan Shefi <[EMAIL PROTECTED]> wrote: >When I run "ping" between 2 identical FreeBSD hosts, with packets larger >then 25152 bytes, "ping" fails. Intriguing. >Does someone has an idea what might cause this failure ? No, but a few more datapoints: - it only affects real network connections - localhost is unaffected - The problem also occurs when pinging FreeBSD 7.x from linux but not when the same linux system pings a Winbloze box. - Pinging either linux or winbloze from FreeBSD 7.x fails. -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. pgpmhSTDXKGbq.pgp Description: PGP signature
Re: "ping" with packets larger then 25152 bytes fails.
On 2008-Jul-16 12:37:59 -0700, Barney Cordoba <[EMAIL PROTECTED]> wrote: >> >When I run "ping" between 2 identical FreeBSD hosts, with packets larger >> >then 25152 bytes, "ping" fails. ... >Isn't this sort of like going to your auto dealer and complaining that you get >vibration at 240mph? I don't think so. There are no specific limits on the size of ICMP ECHO REQUEST or ICMP ECHO REPLY packets, therefore the only limit should be the IP packet limit (64KB). It does work with other IP stacks and with the loopback interface on FreeBSD. Poking around a bit more, the culprit looks like net.inet.ip.maxfragsperpacket - which is set to 16 by default. -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. pgpEyJ2bKFIKF.pgp Description: PGP signature
Re: lost routes
On 2008-Sep-23 10:00:50 +0200, Giulio Ferro <[EMAIL PROTECTED]> wrote: >I think this is a very old freebsd problem, dating back to freebsd5 >or even before. I don't recall seeing it, or previous references to this problem, so all I can offer is more questions. I presume you aren't running any sort of routing daemon or DHCP client. >Every now and again static routes are lost by freebsd. >In my fw/router/vpn box (average traffic about 10Mb/s) with a lot >of interfaces, physical, vlan and virtual, once every x weeks (x very >variable) one of the routes get lost. Is it a random route, or is it always the same route being lost? If it's different routes, is there anything in common between the routes that are lost? Are all your interfaces on disjoint subnets? -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. pgpDouhXIQYk7.pgp Description: PGP signature
Re: CARP performance tuning question.
Whilst I don't doubt that you have a problem, your comments don't correlate particularly well with the data you have provided and this makes it difficult to immediately suggest a solution. On 2008-Nov-05 16:40:32 +0300, pluknet <[EMAIL PROTECTED]> wrote: >AT work we use device carp(4) under high load: carp(4) is solely a failover mechanism. It either generates or receives somewhat under 1pps per carp interface and the state it maintains is basically 'master' or 'backup'. I suspect the 'load' is being caused by pf(4), possibly in conjunction with pfsync(4). >The problem is that the server experiences a bad interactivity (from >70k states and very bad from 120-150k) >i.e. when a network workload (and interrupts count) begin to increase. > >>From top(1): >CPU states: 0.0% user, 0.0% nice, 0.4% system, 76.3% interrupt, 23.3% idle > PID USERNAMETHR PRI NICE SIZERES STATETIME WCPU COMMAND > 13 root 1 -44 -163 0K 8K WAIT 407:43 57.86% swi1: net I agree that swi1 is using a significant amount of CPU but top is still reporting >23% idle so you shouldn't be getting poor interactive performance. >ATM pfctl -s info shows such numbers: > >State Table Total Rate > current entries 153972 > searches 6052078938 4800.8/s > inserts120373545 95.5/s > removals 120219573 95.4/s That shows the load on pf(4) but doesn't really reflect what the system is doing as a whole. >It works currently under UP, but could be rebuilt to work under SMP >(Xeon 5130) if that helps. Unfortunately, I don't know if this will help or not because I'm not sure what bottleneck you are hitting. >Can someone give hints to decrease interrupt count and to help with >the server stability at all? Well, you haven't actually reported what the interrupt count or what instability you are seeing so this is a bit difficult. Can you please provide some more information: - output from 'uname -a' - output from 'vmstat -i; sleep 10; vmstat -i' under load - output from 'netstat -i' - 10-15 seconds of output from 'netstat -i 1' under load - What is the box doing? Is it a straight filtering router? Does it handle NAT? Is it running apps itself (eg web, ftp, mail)? - What speed are the interface(s) running at? - What instability problems are you seeing? - Please provide more details on what you mean by 'bad interactivity'. - How complex is your pf ruleset? How many rules? Anything unusual? - What scheduler are you using? - What is the full output of 'pfctl -s info'? -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. pgpLULZODpu1a.pgp Description: PGP signature
Re: CARP and L2 src-MAC
On 2008-Nov-06 10:06:21 +0100, Jon Otterholm <[EMAIL PROTECTED]> wrote: >Is it possible to tweak CARP to use the virtual MAC in L2 header instead of >the physical interface MAC? Could this be implemented as a feature >controlled by a sysctl? In my testing, Max Laier's carpdep patches do this. See http://lists.freebsd.org/pipermail/freebsd-net/2008-March/017103.html -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. pgpZRD0UHjVFm.pgp Description: PGP signature
Re: Measuring processes' bandwidth usage
Hi Cihangir, On 2008-Nov-26 09:48:19 +0200, Cihangir Besiktas <[EMAIL PROTECTED]> wrote: >I am planning to develop a project, and in this project, there must be a >module that outputs all the processes' bandwidth usage. How can I handle a >process' bandwidth usage? I am looking forward to your advices. Can you explain further what you mean by a "processes' bandwidth usage". The process-related information collected by the kernel is listed in getrusage(2). You might also like to look at ktrace(1,2). I suspect you may need to modify the kernel to capture the information you are looking for. -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. pgpqNA5M12V2Y.pgp Description: PGP signature
Re: Weird TCP connect issue in FreeBSD 6
On 2008-Dec-02 15:10:11 -0500, Benjie Chen <[EMAIL PROTECTED]> wrote: >I have a weird issue to report, and I am not sure if it's a bug or >some other configuration problem. I would suggest it is a configuration problem. >Server is a dual NICed FreeBSD 6.2 system. For example, one NIC is em0 >= 192.168.0.1, and the other one is em1 = 192.168.0.2. This is not a supported configuration - you cannot have addresses within the same subnet on more than one interface. >I just switched to using IP aliasing on the same NIC, and so far I >have not been able to re-produce the same problem. This is the correct configuration. -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. pgpwps7asJF15.pgp Description: PGP signature
Re: Weird TCP connect issue in FreeBSD 6
On 2008-Dec-03 17:40:01 -0500, Benjie Chen <[EMAIL PROTECTED]> wrote: >When I had two IPs from two different subnets configured for the two >NICs, I had the same error. So while I did have a configuration issue, >the problem with replicated SYNs did occur even when the two NICs had >IP addresses on different networks. OK, that does sound wrong. Can you describe that setup please - what local addresses/netmasks and routes did you have and what was the remote IP address. -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. pgp3UB1j3vtWW.pgp Description: PGP signature
Re: Heads up --- Thinking about UDP and tunneling
On 2008-Dec-13 13:55:18 +1100, Ian Smith wrote: >I guess submitting patches for style(9) is considered a suicide method? Not necessarily but you need to have very good justification for any change. It's much easier to read a large corpus of code where the code is all written in one style. I suspect that no-one is happy with everything in style(9) but consistency is seen as more important. -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. pgpHpw1TWvrRq.pgp Description: PGP signature
Re: Re[2]: ath: is here full list of supported chipsets and chipsets comparsion?
On 2008-Dec-15 23:27:30 +0300, Lev Serebryakov wrote: > And using HEAD in production... Hmm. Is it good idea? That's really an individual decision. If you have the time, expertise and facilities to adequately regression test a HEAD snapshot using something similar to your production workload, and are willing to help resolve any problems you encounter, then there's no particular reason why you shouldn't run HEAD in production. Looking at it another way, the more people who stress 8-CURRENT in strange and varied ways (and help fix any problems they encounter), the better 8-RELEASE will be when it eventuates. -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. pgpyG7olk4c3N.pgp Description: PGP signature
Re: HEADSUP: arp-v2 has been committed
On 2008-Dec-27 14:54:34 -0800, Julian Elischer wrote: >Qing Li wrote: >> I believe examining the impacts of RTF_LLINFO on the ports >> was a good exercise even if we have to rejuvenate it. > >reintroduce it with value 0 And a comment indicating that the definition of RTF_LLINFO is solely for backward compatibility. (To make it clear why it's never referenced in the base system and not needed for new code). -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. pgpJOC5kHzF5N.pgp Description: PGP signature
Re: em driver problems? taskq em goes up to 100% CPU
On 2008-Dec-30 07:58:58 -0800, ibmed wrote: >There's two FreeBSD boxes that do ipfw nat. >Both worked with natd until some time ago, when it became clear that we need >a better solution. So I upgraded sources and recompiled to kernel to include >ipfw nat features. The boxes have onboard msk-net cards that worked fine >under natd. When I ran into similar load issues, I switched to ipfilter because the IPFW kernel NAT didn't exist at the time. If you are unable to find another solution, possibly you could try a different firewall. >options DUMMYNET >options IPDIVERT Are you using dummynet or ipdivert functionality? >fastforwarding is on, polling is off: >net.inet.ip.fastforwarding: 1 Have you tried disabling fastforwarding? What if your hardware configuration and how much traffic are you pushing through the system? -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. pgpYJNdeyPoGv.pgp Description: PGP signature
Re: FreeBSD Router Problem
On 2009-Mar-26 11:02:55 -0500, Pierre Lamy wrote: >A 1 day default timeout for established connections is retarded, since >virtually all client apps and OSs as well as intervening stateful >firewalls will lose state after 1 hour. With respect, this is nonsense. An app or OS should never "lose state" for an established TCP connection - if it does, it is broken. Note that the default TCP keepalive interval (in many OSs, not just FreeBSD) is 2 hours. Firewalls are a different case - far more variable and far more often tweaked to suit the owner. IPFW2 defaults to 4096 dynamic rules and defaults to a 5 minute timeout (it also supports its own keepalive generation). IPfilter defaults to a 120 hour timeout. Our corporate firewall at $work times out after about a minute. Again - none of these match your '1 hour' statement. > A session which is idle for more >than an hour can't be considered to be active. This depends on what you consider active. I manage one firewall-like device at work where access to services through the device is controlled be the presence of a specific TCP connection (ie, the user sets up a TCP connection to an app on the box and that app then allows that user to have access to other services mediated by that box whilst that connection remains established). In this case, once the initial authentication phase is complete, the control connection never carries any further application-level data but its continued presence is required (and monitored via TCP-level keepalives). -- Peter Jeremy pgpfioORNwsMU.pgp Description: PGP signature
Re: Network Card
On 2009-Apr-21 14:02:38 -0700, Barney Cordoba wrote: >On all of the MBs that I have, the slot NIC appears before the onboard >ports in the pciconf -l listing. Its certainly not for sure. As a datapoint to add to the uncertainty, the SunFire V440 has 4 motherboard NICs - two come before the PCI slots and two after (so adding a PCI-based Cassini nic moves ce2 from the MB to the plugin). Even slot numbering on larger boxes (with multiple physical PCI buses) can be non (or counter) intuitive. Also note that FreeBSD has also changed its PCI probe order at least once in the past (effectively re-numbering devices). -- Peter Jeremy pgpmwIOlUjC3E.pgp Description: PGP signature
Re: kern/137317: [tcp] logs full of syncache problems
rver]:22 tcpflags 0x10; syncache_expand: Segment failed SYNCOOKIE authentication, segment rejected (probably spoofed) Jul 29 10:37:28 aalp05 kernel: TCP: [client]:58128 to [server]:22 tcpflags 0x10; syncache_expand: Segment failed SYNCOOKIE authentication, segment rejected (probably spoofed) Note that the syslog message implies there is an incoming packet but tcpdump doesn't show one. -- Peter Jeremy pgpMdsvwNwvLk.pgp Description: PGP signature
Re: altq unfortunately queuing vlan traffic.
On 2007-Apr-12 11:20:29 +0100, "Bruce M. Simpson" <[EMAIL PROTECTED]> wrote: >I can't speak for ALTQ at the moment however I believe dummynet may work >on vlan devices. dummynet definitely does work on vlan devices. I use it extensively at work. -- Peter Jeremy pgph2X65LlVgG.pgp Description: PGP signature
Re: fake MAC addresses and ARP
On 2007-Apr-17 13:36:43 +1000, Alan Garfield <[EMAIL PROTECTED]> wrote: >I've got a little driver that communicates via a small buffer on the >motherboard of a Sun Fire V20z to a built-in "service processor" which >is running Linux. The driver on both sides makes the buffer look like a >Ethernet interface. I'd be interested in using this. >arplookup 169.254.101.2 failed: could not allocate llinfo >arpresolve: can't allocate route for 169.254.101.2 > >The Linux driver I'm porting simply grabbed any outgoing arp requests, >made up an appropriate response with the pre-defined fake MAC's, put it >into the input queue and ate the request packet. A quick-and-dirty work-around would seem to be arp -s 169.254.101.2 Fa:ke:ma:cA:dd:re:ss Otherwise, I think you would need to fiddle with the transmit packet code in your driver. -- Peter Jeremy pgp1DSC38AW7a.pgp Description: PGP signature
Re: rtentry and rtrequest
On 2007-Apr-19 23:50:00 +1000, Alan Garfield <[EMAIL PROTECTED]> wrote: >debug1: Local version string SSH-2.0-OpenSSH_3.4p1 >debug1: SSH2_MSG_KEXINIT sent >d475 078f 7eae aef6 >Disconnecting: Bad packet length -730527857. >debug1: Calling cleanup 0x1001fc68(0x0) >localhost $ 'Bad packet length' is coming from ssh (packet.c:packet_read_poll2()) and (as Yar suggested) is related to SSH's own packetisation, rather than TCP. The reported packet length is the 'd475 078f' immediately above. Note that at this stage, SSH has not negotiated encryption so working thru a tcpdump output is still practical. I suspect that there's a problem with the packet sizes. >> > Yeah it's what the Linux driver is called. Can be something else, got a >> > better name? :) >> >> Perhaps just "jn"? Some utilities still have trouble with long >> interface names[1], and they are a drag to type in. :-) So I'd >> rather keep the name as short as possible. > >Yeah 'jn' sounds ok to me. Although it's really not going to be that >common unless you have these SunFire or NewISys servers. :) All the utilities I've seen will just truncate the names. Since we already have 4-character interface names (eg vlan), and there will never be more than one of these, I'd prefer to leave it as jnet. There are a limited number of 2-letter combinations and 4 letters is more descriptive. (I would far prefer that "vlan" be truncated to something shorter so that my daily reports don't have 48 lines stating 'vlan1'). -- Peter Jeremy pgptPqZ2Apexk.pgp Description: PGP signature
Re: New Config of Jails & 4 port NIC with 6.2 stable
On 2007-Apr-19 19:24:37 -0700, [EMAIL PROTECTED] wrote: >A FreeBSD Grasshopper needs help. This is probably more -questions fodder but anyway... >like to configure the above with Jails >My aim is local DNS, DHCP, Apache1.3, MySQL 4, PHP4, etc, etc. >basic server stuff. Whilst you need an IP address for a jail, you don't need to dedicate an interface to a jail. Typically, you would create a number of aliases on one interface and assign them to jails. If you have lots of public addresses then you could use aliases on your public NIC. Alternatively, you can create aliases on lo0 and use firewall software (ipfw, IPfilter or pf) to redirect packets to the appropriate alias. If you really need distinct physical interfaces, you could use an IEEE 802.1Q VLAN trunk into your FreeBSD box and break it out into as many vlan interfaces as you want. -- Peter Jeremy pgpcqV6OwpEXF.pgp Description: PGP signature
Re: Corrupt packets in Jnet (Was: Re: rtentry and rtrequest)
On 2007-Apr-23 18:54:30 +0400, Yar Tikhiy <[EMAIL PROTECTED]> wrote: >Perhaps the bug is triggered when the outgoing packet consists of >multiple mbufs. Given that we are effectivly dealing with a shared memory block, how does the SP now when the server has finished writing and vice versa? Is jnet's handling of multiple mbufs making the SP think there are multiple packets? >I'd also test if the ssh from SP can work OK with a FreeBSD host >(the same FreeBSD version as on the platform side would be the best) >via the external Ethernet. It definitely can. I haven't used anything else to talk to my SP. >Your jnet_start() routine fills the tail of the buffer w/zeros >already, doesn't it? I would also suggest padding to 256 bytes with zeroes. -- Peter Jeremy pgp6n8joWvpaP.pgp Description: PGP signature
Re: Firewall
On 2007-Apr-28 07:08:18 -0500, Jack Barnett <[EMAIL PROTECTED]> wrote: >I plan on using NAT so both internal networks can get to the internets. > >In the FreeBSD documentation I see there are 3 firewalls, IPFIREWALL, >IPFILTER and PF (BF?). I just need to do basic filtering and just a few >port forwards. Nothing to fancy. Which one would be recommended? Basically any of them will do what you want. The major differences are: - IPFW (IPFIREWALL) is FreeBSD only. Note that the NAT is in userland. - IPfilter is the most portable. - PF runs on *BSD. Note that (AFAIK) all proxies (eg FTP) are in userland. Userland NAT or proxies incur significantly higher overheads than in-kernel equivalents (because the packets have to cross the kernel/userland barrier twice). This may be an issue if you have a very fast Internet connection and an underpowered firewall. -- Peter Jeremy pgpbSvXzIKzfB.pgp Description: PGP signature
Re: Firewall
On 2007-Apr-30 10:58:18 +0100, Robert Watson <[EMAIL PROTECTED]> wrote: >One of the big selling points of IPFW is integration with DUMMYNET, which >offers bandwidth management facilities not present in the other systems. I thought altq(4) could also do most of what dummynet(4) does but based on a closer look, it seems that it can't do the packet delay stuff, though it seems to have fairly similar bandwidth management facilities. >is the main selling point for ipfw on my servers -- being able to rate >limit arbitrary IP addresses, port numbers, etc, both in terms of inbound >and outbound traffic is invaluable. I extensively use dummynet at work to simulate WANs (bandwidth limited and significant delays) between different servers in our models. It has proved invaluable for relicating field problems. -- Peter Jeremy pgpnZc0lqJwO8.pgp Description: PGP signature
Re: Unix friendly network testbench for FreeBSD?
On 2007-May-02 14:40:35 -0700, [EMAIL PROTECTED] wrote: >Hmmm... ok, expanding on that what I was looking for was a means to >simulate semi-realtime delays across a virtual network with 4+ virtual >machines. Is it possible to use Dummynet in this case, or do I need to look >into something else? Dummynet can provide bandwidth restriction as well as msec-granularity delays on packets being pushed through a pipe. You can glue together multiple pipes (packets go through several pipes with different characteristics). I'm not sure what your virtual machines need to do so I can't comment whether FreeBSD would be useable. >Other conditions I planned on imposing are non-locking NFS (causes a lot of >issues here with files at work), Should be OK > and have SUSE 32-bit clients (host OS of choice at work) FreeBSD doesn't have SuSE clients but should be able to run them in its Linux emulation layer. -- Peter Jeremy pgpe0m2vtG3Br.pgp Description: PGP signature
Re: bridge query
On 2007-May-08 14:20:27 +0500, [EMAIL PROTECTED] wrote: >i am using freebox 5.4 as a bridge using dummynet. ... >When I add delay of 250ms and plr of 0.05 (5%), the packet transfer falls >to 80Kbit/s. How are you measuring packet transfer (single TCP socket, multiple TCP sockets or UDP) and what were you expecting? For a TCP connection, the window size needs to be able to handle at least 1 RTT (0.5 second in this case) of data. This translates to a total of 5Mb (~640KB) outstanding data to get 10Mbps throughput. With only a single cnnection, you would need a 640KB window size - which is far larger (an order of magnitude or so) than typical. TCP is also designed to work on a mostly lossless link. I am not sure how much a 5% packet loss will affect it but I would expect it to be significant. I'm not sure how to optimise throughput in this situation. -- Peter Jeremy pgp2aOhyNMpCf.pgp Description: PGP signature
Re: bridge query
On 2007-May-11 10:22:43 +0500, [EMAIL PROTECTED] wrote: >I am using TCP sockets to measure packet transfer. And I am also not >looking to optimise the link. I just want to know if this is the usual >behaviour of the freeBSD TCP or bridge when we apply delay and packet >loss. This is nothing to do with FreeBSD and is expected behaviour for TCP. The TCP sender has to buffer data until the receiver acknowledges it. The default buffer is 64KB. With a 250msec delay in each direction, this gives you a theoretical maximum thruput of 128KBps. >The throughtput falls from around 8 Mbps (8000 Kbps) to just 80 Kbps. >This is very significant. Increasing PLR above 0 will reduce the theoretical throughput: A lost ACK will block the sender until the next ACK is received. A lost data packet means the receiver won't ACK it. SACK makes things slightly better because only the lost packet will be re-transmitted but the very long RTT will still have a major impact on throughput. -- Peter Jeremy pgpWRreV4yDBJ.pgp Description: PGP signature
Re: VLANs and routing
On 2007-Jun-14 01:55:20 +0200, Ivan Voras <[EMAIL PROTECTED]> wrote: >But the (somewhat weird) requirements are that the vlan interface on >machine1 shouldn't have assigned IP address, but the second one should. ... >Is this kind of setup even supported? I don't see how it could be if machine1 is an IP endpoint: In order to transmit a packet, it needs to put a source IP address into the packet - which virtually always comes from the interface. -- Peter Jeremy pgpLYCASUZrpl.pgp Description: PGP signature
Re: Issue with huge numbers of connections
On 2007-Jun-17 13:02:38 -0600, "M. Warner Losh" <[EMAIL PROTECTED]> wrote: >Doing the math on 10^9 connections in a week translates to ~1650/s, so we'd >expect there are on the order of 100-200 connections steady state at any >time. I suspect that the peak load may be up to 100 times that, which is >still only 2 connections. The hangs don't seem to hang at a peak, but >randomly. Note that the TCP state machine includes a 2xMSL (128 second) timeout after the connection closes before the kernel releases the TCP control block. There may not be many connections open but at 1650 connections per second, there are about 200,000 control blocks in TCPS_TIME_WAIT - far more if the load is peaky. -- Peter Jeremy pgpZM1cYnVUNw.pgp Description: PGP signature
Re: localhost connections showing source address 0.0.0.0
On 2007-Sep-29 22:24:02 +0200, Kris Kennaway <[EMAIL PROTECTED]> wrote: >Going back at least as far as January 2007 some of the package build >machines have occasionally experienced a problem where a fetch(1) via a >localhost:3128 squid proxy are denied because squid sees the connection as >having a source address of 0.0.0.0 instead of 127.0.0.1. Can you capture source port as well (squid.conf says %>p will do this)? Is there any correlation with the source port or package being fetched? Is it consistent? -- Peter Jeremy pgplcBkHQKfdh.pgp Description: PGP signature
Re: Disable Exponential Backoff (retry) on Ethernet?
On Wed, Oct 17, 2007 at 08:51:34PM -0700, Len Gross wrote: >I'm doing some protocol development and it is convenient to start it on >Ethernet. I will need to send a packet to the Ethernet device and only have >it be sent once, even if there is a colision. I know we've still got some hubs lying around in a backroom at work but I don't know of anything that will let you disable the retry-on-CD. Have you considered simulating the network at a slightly higher lever: Use ipfw pipes or similar to simulate packet loss (either set a queue length of 1 or probabilistically). This could be done either as a bridge or by tunneling your protocol over IP or UDP. -- Peter pgpZxicx6nVFT.pgp Description: PGP signature
Re: proxy arp on 6.1
On Wed, Oct 24, 2007 at 02:17:37PM -0400, Stephen Clark wrote: >I must be doing something wrong. I can't seem to get proxy arp to work. Is >there some magic. I've been using proxy ARP on FreeBSD between 4.x and 6.2 without problems (though I think I skipped 6.1). >I have the following setup isp router 205.x.x.1 <-> 205.x.x.100/25 rl1 >freebsd vr0 205.x.x.129/25 ><-> 205.x.x.193/25 >arp -an >(205.x.x.1) at 00:13:7f:5a:b5:50 on rl1 [ethernet] >(205.x.x.193) at 00:30:18:a3:44:2d on vr0 permanent published (proxy only) >[ethernet] > >tcpdump >13:09:51.386793 arp who-has 205.x.x.193 tell 205.x.x.1 Which interface is being dumped and what does 'ifconfig vr0' show? If you are dumping the rl0 interface then my suspicion is that the subnet on 205.x.x.1 is wrong: 205.x.x.193 is not the same subnet as 205.x.x.1/25 so 205.x.x.1 should not be doing ARP requests for it, it should be accessing it via a gateway (router). -- As a computing professional, I believe it would be unethical for me to advise, recommend, or support the use (save possibly for personal amusement) of any product that is or depends on any Microsoft product. pgpjfnafTrJmZ.pgp Description: PGP signature
In Memoriam: Jun-ichiro Hagino
A recent posting in BUGTRAQ[1] has announced that Itojun has passed away. Itojun was a past FreeBSD committer and very active in KAME and the IPv6 world. No details of his passing were in the BUGTRAQ posting but some information in Japanese is available at http://www.hoge.org/~koyama/itojun.txt [1] http://www.securityfocus.com/archive/1/483015/30/0/threaded -- Peter pgpln7Xq7XbrB.pgp Description: PGP signature
Re: RFC: Evolution of the em driver
On Wed, Oct 31, 2007 at 01:16:39AM -0700, Jeremy Chadwick wrote: >For what it's worth, I agree with Scott. I'd rather see a new and >separate driver (presumably igb(4)) than a "hacked up" em(4) driver >trying to handle tons of IC revisions. A good example of the insanity >the latter causes is nve(4) vs. nfe(4). :-) A separate driver is probably cleaner. I'll just make the comment that if a separate driver is written, there needs to be a clear way for an end user to identify what driver is needed/preferred for his chipset. We already have cases like re(4)/rl(4) and sym(4)/ncr(4) where some chips are supported by two drivers - though generally only one driver fully supports the chip. This sort of thing is confusing for end users. -- Peter pgpOQNq8R1nOR.pgp Description: PGP signature
Re: Maximum number of vlans on a freebsd box ???
On Sat, Nov 03, 2007 at 08:23:20PM +0200, Ivo Vachkov wrote: >I'd like to ask if someone has information how many vlans a freebsd >box can 'run' ? There is no hard limit, so in theory 4096 VLANs per trunk. If you are using a very large number, defining VLAN_ARRAY should improve performance at the expense of kernel memory by removing a hash lookup. -- Peter pgpam3LAQ35Te.pgp Description: PGP signature
Re: Pipe queues
On Tue, Dec 11, 2007 at 12:31:00PM +0400, rihad wrote: >Peter Jeremy wrote: >> On Tue, Dec 11, 2007 at 09:21:17AM +0400, rihad wrote: >>> And if I _only_ want to shape IP traffic to given speed, without >>> prioritizing anything, do I still need queues? This was the whole point. >> No you don't. I'm using pipes without queues extensively to simulate >> WANs without bothering with any prioritisation. > >Great! One fine point remains, though: ># ipfw pipe 1 config bw 128Kbit/s >will use a queue of 50 slots by default. What good are they for, if I >didn't ask for queuing in the first place? 'queue' is used in two distinct ways within the ipfw/dummynet code: 1) There's a "queue" object created with 'ipfw queue NNN config ...' This is used to support WF2Q+ to allow a fixed bandwidth to be unevenly shared between different traffic types. 2) There is a "queue" option on the "pipe" object that defines a FIFO associated with the pipe. I had assumed you were talking about the former (and my response was related to this) but given your latest posting, and having re-read the thread, I suspect I may have been wrong. Whilst I don't use queue objects, I do use the queue option on my pipes. In your example, you have a pipe that can handle 128kbps (16kBps). If you write a 1600byte packet to it, then the packet will reappear 100msec later. Any further packets written to that pipe during that time will be dropped if they can't be placed on a queue. The practical throughput depends on the number of queue slots available and the number of writers. I suggest you do some reading on queueing theory for the gory details. -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. pgpY3vdp7Xd0y.pgp Description: PGP signature
Re: Pipe queues
On Tue, Dec 11, 2007 at 09:21:17AM +0400, rihad wrote: >And if I _only_ want to shape IP traffic to given speed, without >prioritizing anything, do I still need queues? This was the whole point. No you don't. I'm using pipes without queues extensively to simulate WANs without bothering with any prioritisation. -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. pgpFgenKBbrZf.pgp Description: PGP signature
Re: Packet loss every 30.999 seconds
On Wed, Dec 19, 2007 at 12:06:59PM -0500, Mark Fullmer wrote: >Thanks for the other info on timer resolution, I overlooked >clock_gettime(). If you have a UP system with a usable TSC (or equivalent) then using rdtsc() (or equivalent) is a much cheaper way to measure short durations with high resolution. -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. pgp1bnwEZSWxc.pgp Description: PGP signature
Re: simple, adaptive bandwidth throttling with ipfw/dummynet ?
On Fri, Feb 29, 2008 at 02:28:04PM -0800, Juri Mianovich wrote: >"after 30 minutes of maxed dummynet rule, add X mbps >to the rule for every active TCP session, with a max >ceiling of Y mbps" > >and: > >"after 30 minutes of less than max usage, subtract X >mbps from the rule every Y minutes, with a minimum >floor of Z" > >Make sense ? It doesn't really make sense to me but it's your firewall and you are free to implement whatever rules you like. >If I wanted to do this myself with a shell script, is >there any way to test a particular dummynet rule for >its current "fill rate" - OR - a simple way to test if >a particular dummynet rule is currently in enforcement >? The system doesn't maintain stats on the instantaneous "fill rate" of pipes/queues. All it will report is total counts of traffic through and in the pipe/queue. Since the format wasn't clear to me from a quick read of the man page, the following is a breakdown of the output, with added notes: fwall# ipfw pipe list 1: 6.400 Mbit/s0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x/0x -> 0x/0x BKT Prot ___Source IP/port Dest. IP/port Tot_pkt/bytes Pkt/Byte Drp 0 tcp 192.168.123.200/56599 150.101.135.3/61455 122097 6353558 00 397 |- dummynet accumulation bucket details -| Totals ---|Queued | 'dummynet accumulation bucket details' is the details of the most recent (I think) packet matching the specific bucket mask 'Totals' is total bytes and packets through that particular bucket 'Queued' refer to bytes and packets for that bucket currently queued 'Drp' is the number of packets dropped. You would need to calculate a rate by periodically sampling the counts. You can get a rough idea of if a particular dummynet rule is restricting traffic flow by looking for non-zero queued counts (though keep in mind that it is normal for a packet to occasionally be queued). Assuming you have the TCP sessions spread across distinct buckets (either with multiple pipes/queues or with masks to split them up), my suggestion would be a perl script that regularly does 'ipfw pipe list' or 'ipfw queue list' and use change_in_total_bytes/time to calculate average throughput per session. Then use a leaky bucket on the average throughput to trigger pipe/queue re-configurations as desired. -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. pgp7nKGcjIU3N.pgp Description: PGP signature
Re: bpf packet capture and SOCK_STREAM socket redirects...
On Thu, Mar 20, 2008 at 11:27:53AM +, Alireza Torabi wrote: >Imagine this: > > | (1) > packets > | | (4) >[nic1] [nic2] > bpf SOCK_STREAM > | (2)| > [FreeBSD] (3) > >1) all user traffic are being monitored >2) bpf on [nic] is capturing these packets >3) after processing we know a connection is about to be established from A to B > >NOW: >4) I want to deliver this packet to the socket on [nic2] >and as this is a tcp socket it'll take care of it from there >(my code here for this sockets sends and arbitary data to A making it >think it came from B) Have a look at divert(4). I suspect it comes closest to what you want. -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. pgpLFiei04Cq1.pgp Description: PGP signature
Re: read() returns ETIMEDOUT on steady TCP connection
On Sat, Apr 19, 2008 at 03:27:28PM +0100, Mark Hills wrote: >I'm are having a trouble with TCP connections being dropped with "read: >Operation timed out". What is unusual is that this is happening right in >the middle of sending a steady stream of data with no network congestion. Can you give some more detail about your hardware (speed, CPU, available RAM, UP or SMP) and the application (roughly what does the core of the code look like and is it single-threaded/multi-threaded and/or multi-process). >systat doesn't show problems inbound; all packets received are delivered to >the upper layer. But on outbound, there is consistent 'output drops': > >IP Output >7028 total packets sent >7028 - generated locally > 314 - output drops > >As the number of outbound connections increases, the 'output drops' >increases to around 10% of the total packets sent and maintains that ratio. >There's no problems with network capacity. 'output drops' (ips_odropped) means that the kernel is unable to buffer the write (no mbufs or send queue full). Userland should see ENOBUFS unless the error was triggered by a fragmentation request. I can't explain the problem but it definitely looks like a resource starvation issue within the kernel. -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. pgp497bYIDN9y.pgp Description: PGP signature
Re: minimum bandwidth per connection with dummynet ?
On 2008-May-23 02:47:30 -0700, Juri Mianovich <[EMAIL PROTECTED]> wrote: >- is there a simple setting that says "allocate >bandwidth evenly between all connections in a >saturated pipe" ? TCP does this automatically. >- alternatively, is there a minimum speed per >connection that I can establish for a dummynet pipe ? Not that I can see - you can use the 'mask' parameter to define a maximum per-connection rate. I don't believe there's any way to redirect "overflow" traffic though. You could probably write a divert(4) application to do the shaping you require. -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. pgppDLtVaaPAv.pgp Description: PGP signature
Re: HEAD UP: non-MPSAFE network drivers to be disabled (was: 8.0 network stack MPsafety goals (fwd))
On 2008-May-26 19:11:16 +, Poul-Henning Kamp <[EMAIL PROTECTED]> wrote: >We should summarily kill the concept of line disciplines as a >modular component and decide that TTYs can be used with termios(4) >or raw mode and leave it at that. streams anyone? -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. pgpfTlr83HmUm.pgp Description: PGP signature
Delaying traffic using altq(4)
I am currently using dummynet(4) to simulate WANs for testing purposes - eg connecting two hosts by a 50Mbps WAN with a 15msec RTT. In order to remove the need to run ipfw(8), I am looking at migrating to altq(4). Unfortunately, whilst altq(4) provides bandwidth management, there does not appear to be any provision for providing time delay on packets. Has anyone looked into implementing time delays in altq? -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. pgprReS0JHTFl.pgp Description: PGP signature
Re: Understanding the interplay of ipfw, vlan, and carp
On 2008-Mar-04 23:20:26 +0100, Max Laier <[EMAIL PROTECTED]> wrote: >You could try the attached patch. It adds carpdev support. You'll have >to recompile ifconfig to make use of it. I have just tried it and found that it does precisely the opposite of what I want :-( My situation: At work, I have a NAT box that is used to translate between our corporate intranet and my department's test models. There is (basically) 1:1 NAT and I use proxy-ARP on the intranet side (though I have gateway IPs on the internal side). I am trying to convert this to use CARP for failover. My external interface config currently looks like: ifconfig vlan10 10.10.10.1 vlandev fxp0 vlan 10 arp -s 10.10.10.2 auto pub arp -s 10.10.10.3 auto pub arp -s 10.10.10.4 auto pub arp -s 10.10.10.5 auto pub Ideally, I want to attach a carp device to vlan10 so I can do ifconfig vlan10 10.10.10.1 vlandev fxp0 vlan 10 ifconfig carp10 vhid 10 carpdev vlan10 arp -s 10.10.10.2 00:00:5e:00:01:0a pub arp -s 10.10.10.3 00:00:5e:00:01:0a pub arp -s 10.10.10.4 00:00:5e:00:01:0a pub arp -s 10.10.10.5 00:00:5e:00:01:0a pub ie the IP address remains with the specific box (the backup box has its own IP address). Unfortunately, the current carpdev code doesn't work this way: It lets me not assign an IP address to vlan10 but I still have to assign an IP address to carp10 (and it uses the latter address rather than the former address in the carp advertisements). Does what I want make sense to you and can you see any way it could be integrated into your carpdev patches. Note that one downside of your carpdev patches is that (AFAIK) it is no longer possible to identify which host sent the packet: The source and destination MAC addresses, as well as the destination IP address are all defined by CARP. Once you change the source IP address to be the shared address there's nothing to identify which host sent it. Finally, can anyone point me to a protocol specification for CARP. The only documentation I can find in either FreeBSD or OpenBSD is basically limited to "it's like VRRP but different to avoid the CISCO patent on HSRP". -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. pgpRTelyUBiIi.pgp Description: PGP signature
Re: network keep droping
On 2008-Jun-05 02:37:14 +0800, Izwan Mohd <[EMAIL PROTECTED]> wrote: >I have being encountering a weird problem on my freebsd 6 , one of my remote >machine being down frequently lately for no particular reason, when I go to >the remote site to check then machine it was in good running condition but >no network, it even can't ping the server on the same subnet, the only way >to restore it back is by running: > >route -n flush && /etc/netstart First question would be: What has changed? Are you able to identify when the problem occurs? This might let you associate the problem with an internal cronjob or network activity. What does ifconfig report? Does the interface look normal or is it reporting something strange? Is the switch reporting any events associated with your port? What do you see if you tcpdump the interface whilst its not working? Are you seeing normal subnet broadcast traffic? Unicast traffic directed to your box? Outgoing traffic from your box? Does physically unplugging and re-connecting the network cable correct the problem? Are you able to (temporarily) use a different swichport or NIC? Finally, more detail on your configuration might trigger someone's memory: What version of 6.x? What NIC/MII? How much memory? What network features (vlan, firewall, dummynet, netgraph, carp, ...) are you using? -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. pgpccuqA2lEP8.pgp Description: PGP signature
Re: Probable Bug in tcp.h
On 2008-Jun-06 09:30:28 +0200, Marc Lörner <[EMAIL PROTECTED]> wrote: >th_x2 and th_off are created as a bitfield. But C-Standard says that >bitfields are accessed as integers => 4-bytes > >On itanium integers are read with ld4-command but the address of >th_x2/th_off may not be aligned to 4-bytes => we get an unaligned >reference fault. If the C compiler chooses to implement bitfields as a subset of a 32-bit integers, it is up to it to load an aligned 32-bit integer and shift/mask the result appropriately to extract the fields. In this particular case, th_x2/th_off are immediately preceeded by a tcp_seq (u_int32_t) field and so will have 32-bit alignment. Note that the presence of 32-bit fields in the definition for struct tcphdr means that the struct must be aligned to at least 32 bits. >If we'd change to 1 byte-accesses => I won't get any misaligned faults >anymore. I gather from this comment that you have some code using struct tcphdr that is getting alignment errors. struct tcphdr is extensively used in the TCP stack within the kernel so it's likely that any layout or alignment problem with it would show up there. I suspect you are dereferencing a mis-aligned struct tcphdr. -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. pgp5pk6y5YJfo.pgp Description: PGP signature
Re: network keep droping
On 2008-Jun-05 12:27:19 +0800, Izwan Mohd <[EMAIL PROTECTED]> wrote: >The server using FreeBSD 6.0-RELEASE the NIC is intel i can't remember the >model but freebsd detect it as "em0" the server memory is 1GB, not special >network fetures it only running snort and nessus 6.0-RELEASE is very old and no longer supported. There have been lots of bug-fixes since then. I suggest you include an upgrade to 6.3/6.4 or 7.0/7.1 in your forward planning. The em(4) device is quite well supported and maintained (by an Intel employee). There have been major changes to em(4) included in 6.3 and 7.0 and these may correct the problem you are seeing. My initial recommendation would be that you try 6.3 (or 7.0). If that is impractical, you may be able to upgrade the em driver to whilst retaining the rest of your 6.0 system - I haven't tried that but I don't see anything in UPDATING that would rule it out. [The approach would be to checkout a RELENG_6_0_0_RELEASE kernel then update sys/dev/em to RELENG_6_3 and build a new kernel]. -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. pgpN36Q8bo6xA.pgp Description: PGP signature
Re: CARP + multiple addresses
On 2008-Jun-12 17:26:25 +0200, Oliver Fromme <[EMAIL PROTECTED]> wrote: >So far it seems to work fine with CARP, but now it turned >out that I need another address from a different subnet >which also needs to access the database. What's the best >way to do that? Add a second IP address to the existing >carp interface, or create a new carp interface? Are there >any pros and cons? I'm currently working towards something like this and intending to have one CARP interface for each VLAN. >And now I need to add an IP address from vlan202 which >also needs to access the same database. I'm inclined to >add 10.1.202.40/32 vhid 1 to the existing carp0 on both >servers. I assume that the CARP interface goes to BACKUP >when *any* of its IP addresses fail, right? Can anybody >confirm this, please? My reading of the various documentation says that you are on the right track but, by default, each CARP interface will fail over independently. If you want them all to fail over together then you should set net.inet.carp.preempt (see carp(4) and its first example) -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. pgpT9laWsRxp0.pgp Description: PGP signature
Re: Looking for networking solution.
On Wed, 2005-Jun-15 12:06:18 +0200, M.Jessa wrote: >I am looking for solution I could implement on a link with a huge latency >when ping replies can go up to a few hundred miliseconds, e.g sateliete >links. What is the problem you are trying to solve? Satellite links have a fairly constant round-trip delay and the RTT calculations built into TCP will happily compensate for this. As long as the TCP window size is larger than the delay*bandwidth and the packet loss probability is well below 1 packet per window, TCP should work fine. >What I was thinking about is some kind of virtual interface which could >translate tcp to udp in one of the pears of the link and push the data it >received from a 'normal' interface through the virtual interface without >bothering about ack-timing. How does the transmitter confirm that the receiver has received packets and can therefore drop them from its transmit buffer (or resend them if they are not received)? In particular, if there is no traffic for a period, the only way that the last packet (before the break) can be confirmed is via acknowledge timeouts. -- Peter Jeremy ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Raw Sockets: Two Questions
On 2018-Mar-21 13:50:26 -0700, "Ronald F. Guilmette" wrote: > >In message <5ab2c0b1.3020...@grosbein.net>, >Eugene Grosbein wrote: > >>It does not mean you need to stick with raw sockets API. >>libpcap can be used too, as I've shown in previous letter. > >Thank you. If zmap ends up not suiting my needs, I will >definitely look into libpcap. Since no-one else has mentioned it, another option would be divert(4), which is part of IPFW. -- Peter Jeremy signature.asc Description: PGP signature
Re: FCP-0101: Deprecating most 10/100 Ethernet drivers
On 2018-Oct-04 14:38:51 +0200, Andrea Venturoli via freebsd-net wrote: >Older models, up to the first RPi3 still have a 100Mb/s NIC. >I just happen to have an RPi3 and I'd really love to convert it to >FreeBSD once 12.x is stable enough. All the RPi variants have Ethernet to USB adapters. They are explicitly excluded from the proposed deprecation. >BTW, I also use fxp interfaces a lot, but that's just because I have Also explicitly excluded because of its popularity. -- Peter Jeremy signature.asc Description: PGP signature
Re: FCP-0101: Deprecating most 10/100 Ethernet drivers
On 2018-Oct-04 08:44:11 +, Alexey Dokuchaev wrote: >Looking at the commits they require near zero maintenance. What exactly >is the burden here? As various others have stated, this isn't true. All the code in FreeBSD has an ongoing maintenance cost and is an impediment to adding new features. There is no point in spending valuable developer effort to update drivers and test them with unusual/obsolete hardware unless those drivers are going to actually be used. >Another question: why the fuck FreeBSD likes to kill >non-broken, low-volatile and perfectly working stuff? That language is uncalled for. >We offer probably >the best NIC driver support on the block, yet you're proposing to shrink >one of the few areas where we shine. WTF?! Supporting NICs that no-one uses doesn't benefit anyone. No-one is talking about removing NICs that are in active use. >ae(4) was used in Asus EeePC 701/900 which are still popular among hackers. Those netbooks are more than a decade old now and I don't expect many are still functional. Will people still expect to use them with FreeBSD 13 in 5 years time? >As it can be seen this list tends to cover nearly all 100 cards, yet no >one (pardon me if I missed those) asks for 10. So how about making this >proposal cover only 10 cards, What is the purpose in keeping unused FastEthernet cards in the tree? >if you can't resist the itch to remove >something from the tree? Again, that language is uncalled for. -- Peter Jeremy signature.asc Description: PGP signature
Re: NFSROOT and lagg(4)
On 2017-Feb-04 13:44:21 -0700, Sean Bruno wrote: >"what I want" is to pxe/netboot and then switch over to using a lagg(4) >interface that includes the interface used in the pxe/netboot boot up. >I suspect, I have to switch to MDROOT to do this, but I thought I'd ask >if anyone is doing this type of configuration in their labs? I used to do something similar on my netbook - see https://www.bugs.au.freebsd.org/dokuwiki/laggdiskless I haven't tried it recently but it definitely worked early on in 10.x. -- Peter Jeremy signature.asc Description: PGP signature
