Re: urtw0: could not allocate USB transfers

[Bernhard Schmidt]

On Thursday, February 24, 2011 21:51:23 joseph wrote:
> Hello,
> 
> i decided to get my laptop wlan via usb because my internal device isn't 
> supported yet.
> The usb device is a logilink WL0006 unit its vendorid is 0x0bda and the 
> productid says 0x8187.
> My search results say that this device depends on a RTL8187 chipset.
> I tried both, load the kernel module at boot time and compile kernel 
> withe urtw, but i get the same output at dmesg
> 
> device_attach: urtw0 attach returned 6
> urtw0:  
> on usbus3
> urtw0: could not allocate USB transfers, err=USB_ERR_NO_PIPE
> device_attach: urtw0 attach returned 6
> 
> im running FreeBSD 8.1-RELEASE-p2 amd64.
> 
> What might be the reason for this error?
> Thanks for all hints.

Well, I have no clue about USB.. but this smells like one of the
endpoints is 'not there'. At least I can't find any reference to
it in the Linux driver. Wanna give attached patch a shot?

-- 
Bernhard
Index: if_urtw.c
===
--- if_urtw.c	(revision 218938)
+++ if_urtw.c	(working copy)
@@ -633,19 +635,6 @@ static const struct usb_config urtw_8187l_usbconfi
 		.callback = urtw_bulk_tx_callback,
 		.timeout = URTW_DATA_TIMEOUT
 	},
-	[URTW_8187L_BULK_TX_NORMAL] = {
-		.type = UE_BULK,
-		.endpoint = 0x3,
-		.direction = UE_DIR_OUT,
-		.bufsize = URTW_TX_MAXSIZE,
-		.flags = {
-			.ext_buffer = 1,
-			.force_short_xfer = 1,
-			.pipe_bof = 1,
-		},
-		.callback = urtw_bulk_tx_callback,
-		.timeout = URTW_DATA_TIMEOUT
-	},
 };
 
 static struct ieee80211vap *urtw_vap_create(struct ieee80211com *,
@@ -1813,9 +1802,7 @@ urtw_tx_start(struct urtw_softc *sc, struct ieee80
 			break;
 		}
 	} else
-		xfer = (prior == URTW_PRIORITY_LOW) ?
-		sc->sc_xfer[URTW_8187L_BULK_TX_LOW] :
-		sc->sc_xfer[URTW_8187L_BULK_TX_NORMAL];
+		xfer = sc->sc_xfer[URTW_8187L_BULK_TX_LOW];
 
 	STAILQ_INSERT_TAIL(&sc->sc_tx_pending, data, next);
 	usbd_transfer_start(xfer);
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: urtw0: could not allocate USB transfers

[Etienne Robillard]

On 25/02/11 04:11 AM, Bernhard Schmidt wrote:
> On Thursday, February 24, 2011 21:51:23 joseph wrote:
>   
>> Hello,
>>
>> i decided to get my laptop wlan via usb because my internal device isn't 
>> supported yet.
>> The usb device is a logilink WL0006 unit its vendorid is 0x0bda and the 
>> productid says 0x8187.
>> My search results say that this device depends on a RTL8187 chipset.
>> I tried both, load the kernel module at boot time and compile kernel 
>> withe urtw, but i get the same output at dmesg
>>
>> device_attach: urtw0 attach returned 6
>> urtw0:  
>> on usbus3
>> urtw0: could not allocate USB transfers, err=USB_ERR_NO_PIPE
>> device_attach: urtw0 attach returned 6
>>
>> im running FreeBSD 8.1-RELEASE-p2 amd64.
>>
>> What might be the reason for this error?
>> Thanks for all hints.
>> 
> Well, I have no clue about USB.. but this smells like one of the
> endpoints is 'not there'. At least I can't find any reference to
> it in the Linux driver. Wanna give attached patch a shot?
>   

Hi Bernard,

For rt287x based cards, you can try using rt28700 chipset instead of
urtw0 on
FreeBSD 8.

The former is not in the stable src tree, but could be retrieved from here:

https://gthc.org/distfiles/freebsd/rt2870_fbsd8.tar.gz

Any takers to make module rt28700 (if_rt2870) officially part of the
FreeBSD src tree?


Thanks,

Etienne

-- 
Etienne Robillard

Company: Green Tea Hackers Club
Occupation: Software Developer (and CEO)
E-mail: e...@gthcfoundation.org
Work phone: 450-936-2123
Website (Company):  https://gthc.org/
Website (Blog): https://gthc.org/blog/
PGP public key fingerprint:F2A9 32EA 8E7C 460F 1728  A1A7 649C 7F17 A086 
DDEC

During times of universal deceit, telling the truth becomes a revolutionary 
act. -- George Orwell 

If a free society cannot help the many who are poor, it cannot save the few who 
are rich. -- John F. Kennedy

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

Re: How to bind a static ether address to bridge?

[Daniel O'Connor]

On 25/02/2011, at 17:26, Zhihao Yuan wrote:
> (since I need to forward some ports to this server). So I set
> net.link.bridge.inherit_mac=1, which makes bridge0 to use bge0's MAC
> address, always. But this causes another problem: the packets sent to
> bridge0 is also sent to bge0, -- the packets are duplicated! The
> kernel have to drop half of them. So how can I bind a distinct MAC
> address to a bridge?

Does bge0 have an address? It shouldn't.

You can set the MAC address of the bridge with..
ifconfig bridge0 lladdr aa:bb:dd:ee:ff:gg

--
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
"The nice thing about standards is that there
are so many of them to choose from."
  -- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C






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

Re: urtw0: could not allocate USB transfers

[Bernhard Schmidt]

On Friday, February 25, 2011 11:03:04 Etienne Robillard wrote:
> On 25/02/11 04:11 AM, Bernhard Schmidt wrote:
> > On Thursday, February 24, 2011 21:51:23 joseph wrote:
> >   
> >> Hello,
> >>
> >> i decided to get my laptop wlan via usb because my internal device isn't 
> >> supported yet.
> >> The usb device is a logilink WL0006 unit its vendorid is 0x0bda and the 
> >> productid says 0x8187.
> >> My search results say that this device depends on a RTL8187 chipset.
> >> I tried both, load the kernel module at boot time and compile kernel 
> >> withe urtw, but i get the same output at dmesg
> >>
> >> device_attach: urtw0 attach returned 6
> >> urtw0:  
> >> on usbus3
> >> urtw0: could not allocate USB transfers, err=USB_ERR_NO_PIPE
> >> device_attach: urtw0 attach returned 6
> >>
> >> im running FreeBSD 8.1-RELEASE-p2 amd64.
> >>
> >> What might be the reason for this error?
> >> Thanks for all hints.
> >> 
> > Well, I have no clue about USB.. but this smells like one of the
> > endpoints is 'not there'. At least I can't find any reference to
> > it in the Linux driver. Wanna give attached patch a shot?
> >   
> 
> Hi Bernard,
> 
> For rt287x based cards, you can try using rt28700 chipset instead of
> urtw0 on
> FreeBSD 8.
> 
> The former is not in the stable src tree, but could be retrieved from here:
> 
> https://gthc.org/distfiles/freebsd/rt2870_fbsd8.tar.gz
> 
> Any takers to make module rt28700 (if_rt2870) officially part of the
> FreeBSD src tree?

I'm a bit confused now, shouldn't the rt2870 be supported by run(4)? On
a site-note, this is Ralink chipset not a Realtek one.

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

Re: urtw0: could not allocate USB transfers

[Etienne Robillard]

On 25/02/11 06:18 AM, Bernhard Schmidt wrote:
> On Friday, February 25, 2011 11:03:04 Etienne Robillard wrote:
>   
>> On 25/02/11 04:11 AM, Bernhard Schmidt wrote:
>> 
>>> On Thursday, February 24, 2011 21:51:23 joseph wrote:
>>>   
>>>   
 Hello,

 i decided to get my laptop wlan via usb because my internal device isn't 
 supported yet.
 The usb device is a logilink WL0006 unit its vendorid is 0x0bda and the 
 productid says 0x8187.
 My search results say that this device depends on a RTL8187 chipset.
 I tried both, load the kernel module at boot time and compile kernel 
 withe urtw, but i get the same output at dmesg

 device_attach: urtw0 attach returned 6
 urtw0:  
 on usbus3
 urtw0: could not allocate USB transfers, err=USB_ERR_NO_PIPE
 device_attach: urtw0 attach returned 6

 im running FreeBSD 8.1-RELEASE-p2 amd64.

 What might be the reason for this error?
 Thanks for all hints.
 
 
>>> Well, I have no clue about USB.. but this smells like one of the
>>> endpoints is 'not there'. At least I can't find any reference to
>>> it in the Linux driver. Wanna give attached patch a shot?
>>>   
>>>   
>> Hi Bernard,
>>
>> For rt287x based cards, you can try using rt28700 chipset instead of
>> urtw0 on
>> FreeBSD 8.
>>
>> The former is not in the stable src tree, but could be retrieved from here:
>>
>> https://gthc.org/distfiles/freebsd/rt2870_fbsd8.tar.gz
>>
>> Any takers to make module rt28700 (if_rt2870) officially part of the
>> FreeBSD src tree?
>> 
> I'm a bit confused now, shouldn't the rt2870 be supported by run(4)? On
> a site-note, this is Ralink chipset not a Realtek one.
>
>   

I believe this is a different implementation for RT8187 usb network
adapters than
run(4). However in my view I found urtw0 buggy, but would certainly take
a look at run(4) to
compare the results with wireless networking agaisnt the other driver
(rt28700).

Thanks,
 

-- 
Etienne Robillard

Company: Green Tea Hackers Club
Occupation: Software Developer (and CEO)
E-mail: e...@gthcfoundation.org
Work phone: 450-936-2123
Website (Company):  https://gthc.org/
Website (Blog): https://gthc.org/blog/
PGP public key fingerprint:F2A9 32EA 8E7C 460F 1728  A1A7 649C 7F17 A086 
DDEC

During times of universal deceit, telling the truth becomes a revolutionary 
act. -- George Orwell 

If a free society cannot help the many who are poor, it cannot save the few who 
are rich. -- John F. Kennedy

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

Re: urtw0: could not allocate USB transfers

[Bernhard Schmidt]

On Friday, February 25, 2011 12:47:12 Etienne Robillard wrote:
> On 25/02/11 06:18 AM, Bernhard Schmidt wrote:
> > On Friday, February 25, 2011 11:03:04 Etienne Robillard wrote:
> >   
> >> On 25/02/11 04:11 AM, Bernhard Schmidt wrote:
> >> 
> >>> On Thursday, February 24, 2011 21:51:23 joseph wrote:
> >>>   
> >>>   
>  Hello,
> 
>  i decided to get my laptop wlan via usb because my internal device isn't 
>  supported yet.
>  The usb device is a logilink WL0006 unit its vendorid is 0x0bda and the 
>  productid says 0x8187.
>  My search results say that this device depends on a RTL8187 chipset.
>  I tried both, load the kernel module at boot time and compile kernel 
>  withe urtw, but i get the same output at dmesg
> 
>  device_attach: urtw0 attach returned 6
>  urtw0:  
>  on usbus3
>  urtw0: could not allocate USB transfers, err=USB_ERR_NO_PIPE
>  device_attach: urtw0 attach returned 6
> 
>  im running FreeBSD 8.1-RELEASE-p2 amd64.
> 
>  What might be the reason for this error?
>  Thanks for all hints.
>  
>  
> >>> Well, I have no clue about USB.. but this smells like one of the
> >>> endpoints is 'not there'. At least I can't find any reference to
> >>> it in the Linux driver. Wanna give attached patch a shot?
> >>>   
> >>>   
> >> Hi Bernard,
> >>
> >> For rt287x based cards, you can try using rt28700 chipset instead of
> >> urtw0 on
> >> FreeBSD 8.
> >>
> >> The former is not in the stable src tree, but could be retrieved from here:
> >>
> >> https://gthc.org/distfiles/freebsd/rt2870_fbsd8.tar.gz
> >>
> >> Any takers to make module rt28700 (if_rt2870) officially part of the
> >> FreeBSD src tree?
> >> 
> > I'm a bit confused now, shouldn't the rt2870 be supported by run(4)? On
> > a site-note, this is Ralink chipset not a Realtek one.
> >
> >   
> 
> I believe this is a different implementation for RT8187 usb network
> adapters than
> run(4). However in my view I found urtw0 buggy, but would certainly take
> a look at run(4) to
> compare the results with wireless networking agaisnt the other driver
> (rt28700).

Yeah, urtw(4) has a few flaws..

- urtw(4): Realtek RTL8187B/RTL8187L
- rum(4): Ralink RT2501/RT2601
- run(4): Ralink RT2700/RT2800/RT3000

So it seems the driver you've posted conflicts with run(4). From a
quick glance at it, it seems to support 11n? If so, can I talk you
into working on getting those bits merged?
Thanks!

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

Re: 8.2/7.4-RELEASEs Announced...

[Michael Cardell Widerkrantz]

Ken Smith, 2011-02-24 22:26 (+0100):

> Just a quick note for those of you who are not subscribed to the
> freebsd-announce mail list...
>
> 8.2-RELEASE and 7.4-RELEASE have been announced.  The announcement
> messages are available here:
>
>   http://www.freebsd.org/releases/8.2R/announce.html
>   http://www.freebsd.org/releases/7.4R/announce.html
>
> Enjoy.  :-)

Great news.

However, a freebsd-update from a straight binary installed 8.1-RELEASE
gives me a dialogue to merge a lot of files in /etc/ with just the $Id$
tag being different. That is, I get:

  The following changes, which occurred between FreeBSD 8.1-RELEASE and
  FreeBSD 8.2-RELEASE have been merged into /etc/manpath.config:
  --- current version
  +++ new version
  @@ -1,6 +1,6 @@
  -# $FreeBSD: src/gnu/usr.bin/man/manpath/manpath.config,v 1.26.2.1.4.1
  2010/06/14 02:09:06 kensmith Exp $
  +# $FreeBSD: src/gnu/usr.bin/man/manpath/manpath.config,v 1.26.2.1.6.1
  2010/12/21 17:09:25 kensmith Exp $
   #
   # This file is read by manpath(1) to configure the mandatory manpath,
   # optional manpath and to map each path element to a manpath element.
   # The format is:
   #
  Does this look reasonable (y/n)? 

I'm afraid this will go on for all files in /etc.

What just happened? How can I avoid it?

I had this problem before and then in my frustration just commented out
this line in freebsd-update.conf:

  #MergeChanges /etc/ /var/named/etc/ /boot/device.hints

I got lucky that time, but is this really safe? What if, say, a new
daemon has been installed in the upgrade and needs a new user.

Any suggestions?

-- 
http://hack.org/mc/
Use plain text e-mail, please. OpenPGP welcome, 0xE4C92FA5.

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

Re: 8.2/7.4-RELEASEs Announced...

[Marco van Tol]

On Fri, Feb 25, 2011 at 11:56:46AM +0100, Michael Cardell Widerkrantz wrote:
> Ken Smith, 2011-02-24 22:26 (+0100):
> 
> > Just a quick note for those of you who are not subscribed to the
> > freebsd-announce mail list...
> >
> > 8.2-RELEASE and 7.4-RELEASE have been announced.  The announcement
> > messages are available here:
> >
> >   http://www.freebsd.org/releases/8.2R/announce.html
> >   http://www.freebsd.org/releases/7.4R/announce.html
> >
> > Enjoy.  :-)
> 
> Great news.
> 
> However, a freebsd-update from a straight binary installed 8.1-RELEASE
> gives me a dialogue to merge a lot of files in /etc/ with just the $Id$
> tag being different. That is, I get:
> 
>   The following changes, which occurred between FreeBSD 8.1-RELEASE and
>   FreeBSD 8.2-RELEASE have been merged into /etc/manpath.config:
>   --- current version
>   +++ new version
>   @@ -1,6 +1,6 @@
>   -# $FreeBSD: src/gnu/usr.bin/man/manpath/manpath.config,v 1.26.2.1.4.1
>   2010/06/14 02:09:06 kensmith Exp $
>   +# $FreeBSD: src/gnu/usr.bin/man/manpath/manpath.config,v 1.26.2.1.6.1
>   2010/12/21 17:09:25 kensmith Exp $
>#
># This file is read by manpath(1) to configure the mandatory manpath,
># optional manpath and to map each path element to a manpath element.
># The format is:
>#
>   Does this look reasonable (y/n)? 
> 
> I'm afraid this will go on for all files in /etc.
> 
> What just happened? How can I avoid it?
> 
> I had this problem before and then in my frustration just commented out
> this line in freebsd-update.conf:
> 
>   #MergeChanges /etc/ /var/named/etc/ /boot/device.hints
> 
> I got lucky that time, but is this really safe? What if, say, a new
> daemon has been installed in the upgrade and needs a new user.
> 
> Any suggestions?

Read up on the mergemaster manual for options "-F" and "-i" :-)

Marco

-- 
Micro$oft likes to discard vulnerabilities by `no standard client
would do this.'  No, and no `standard visitor' would apply a crowbar
to your patio door, either." - H. Peter Anvin in linux-kernel.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: 8.2/7.4-RELEASEs Announced...

[Marek 'Buki' Kozlovský]

[snip]
> > I had this problem before and then in my frustration just commented out
> > this line in freebsd-update.conf:
> > 
> >   #MergeChanges /etc/ /var/named/etc/ /boot/device.hints
> > 
> > I got lucky that time, but is this really safe? What if, say, a new
> > daemon has been installed in the upgrade and needs a new user.
> > 
> > Any suggestions?
> 
> Read up on the mergemaster manual for options "-F" and "-i" :-)

perhaps you mean "-Ui" ?
problem is, he might have no src tree when using freebsd-update, so
mergemaster is a no-go :(

> Marco
> 

Buki


pgpbAqMAPsaty.pgp
Description: PGP signature

Re: 8.2/7.4-RELEASEs Announced...

[Marco van Tol]

On Fri, Feb 25, 2011 at 02:47:44PM +0100, Marek 'Buki' Kozlovský wrote:
> [snip]
> > > I had this problem before and then in my frustration just commented out
> > > this line in freebsd-update.conf:
> > > 
> > >   #MergeChanges /etc/ /var/named/etc/ /boot/device.hints
> > > 
> > > I got lucky that time, but is this really safe? What if, say, a new
> > > daemon has been installed in the upgrade and needs a new user.
> > > 
> > > Any suggestions?
> > 
> > Read up on the mergemaster manual for options "-F" and "-i" :-)
> 
> perhaps you mean "-Ui" ?
> problem is, he might have no src tree when using freebsd-update, so
> mergemaster is a no-go :(

My apologies.  I went ahead to fast and replied with source-upgrade in
mind.

Sorry,

-- 
Marco van Tol


pgp2ZaT44x7jD.pgp
Description: PGP signature

Re: 8.2/7.4-RELEASEs Announced...

[Clifton Royston]

On Fri, Feb 25, 2011 at 02:42:25PM +0100, Marco van Tol wrote:
> 
> Read up on the mergemaster manual for options "-F" and "-i" :-)

  freebsd-update does not use mergemaster, though probably it should. 
We had this discussion a month or two ago.

  Currently there is no way around verifying the changes for each file
with a changed $ID$ field, frustrating as it is.

  (Also, if you realize you've made a mistake and say "N" at the end
when it asks if all the merges are OK, it kicks you out of the update
process instead of going through the merges again.)
  -- Clifton


-- 
Clifton Royston  --  clift...@iandicomputing.com / clift...@lava.net
   President  - I and I Computing * http://www.iandicomputing.com/
 Custom programming, network design, systems and network consulting services
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

8.2-RELEASE pf rules not loading

[Vincent Hoffman]

Hi All,
Just upgraded my home machine to 8.2-RELEASE via
freebsd-update remotely (spare time at work.) and on reboot my pf
ruleset isnt being loaded. running '/etc/rc.d/pf start' once its booted
does start it fine though. Any suggestions on debugging or shall i just
try a verbose boot and watch the console when I get home?
I still have

pf_enable="YES"  # Set to YES to enable packet filter (pf)
pflog_enable="YES"   # Set to YES to enable packet filter
logging

in /etc/rc.conf


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

FreeBSD 8.2-RELEASE amd64 Gnome and KDE Slowness

[Mehmet Erol Sanliturk]

I have installed FreeBSD 8.2-RELEASE amd64 on an Intel DG965WH mainboard
with 6 GB RAM , 500GB Seagate HDD .

When GNOME or KDE is used , their start times are very long as spanning many
minutes , and opening of menus in applications such as Firefox , Dolphin ,
and their other programs  are taking many minutes to just open the menu .
Clicking any item , is also waiting many minutes to be activated .

In that structure , it is not possible to use those desktop environments .

After that , I have installed FreeBSD 8.2-RELEASE i386  on the same computer
. The same actions are performed instantly .

After that , I have installed PC-BSD 8.2-RELEASE amd64 . It is just like
FreeBSD 8.2-RELEASE amd64 : Extremely slow .

On FreeBSD 8.2-RELEASE amd64 , I have installed FluxBox . Its menus and
their items are executed very fast .
When a Gnome or KDE ( Dolphin , Ark , K3B ) program is executed from FluxBox
, their menus are again very slow ,
whereas Firefox , Midnight Commander executions are very fast .

This case is just related to FreeBSD 8.2-RELEASE amd64 . The other 64-bit
operating systems are working very well .

I have tested memory chips : There is no any error .
I have used another 500 GB Seagate HDD : Effects are the same .


I could neither be able to understand why this is happening , nor find a
cure to this problem .

Thank you very much .

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

Re: 8.2/7.4-RELEASEs Announced...

[jhelfman]

> On Fri, Feb 25, 2011 at 02:42:25PM +0100, Marco van Tol wrote:
>>
>> Read up on the mergemaster manual for options "-F" and "-i" :-)
> 
>   freebsd-update does not use mergemaster, though probably it should.

My understanding is that freebsd-update was introduced prior to releases 
being branched, so this issue surfaced at that time. The patch I believe 
would be a fix to the freebsd-update client to better handle the tag. I
can't see mergemaster as being an easier solution, as the actual binary
would need to be verified against a known good index that would exist on the
update server.

But then, again, I may be wrong.


> We had this discussion a month or two ago.

Do you have a link to this thread?

> 
>   Currently there is no way around verifying the changes for each file
> with a changed $ID$ field, frustrating as it is.
> 
>   (Also, if you realize you've made a mistake and say "N" at the end
> when it asks if all the merges are OK, it kicks you out of the update
> process instead of going through the merges again.)
>   -- Clifton
> 
> 
> --
> Clifton Royston  --  clift...@iandicomputing.com / clift...@lava.net
>President  - I and I Computing * http://www.iandicomputing.com/
>  Custom programming, network design, systems and network consulting
> services
> ___
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
> 
> 
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: 8.2-RELEASE pf rules not loading

[Joshua Boyd]

My pf related lines in rc.conf look like the following:

pf_enable="YES"
pf_rules="/etc/pf.conf"
pflog_enable="YES"
pflog_logfile="/var/log/pflog"
pflog_flags=""

I do have a problem from time to time where the rules won't load, but
that's usually because a DHCP interface has failed to come up and my
rules aren't written exactly properly to allow for that.

On Fri, Feb 25, 2011 at 12:11 PM, Vincent Hoffman  wrote:
> Hi All,
>            Just upgraded my home machine to 8.2-RELEASE via
> freebsd-update remotely (spare time at work.) and on reboot my pf
> ruleset isnt being loaded. running '/etc/rc.d/pf start' once its booted
> does start it fine though. Any suggestions on debugging or shall i just
> try a verbose boot and watch the console when I get home?
> I still have
>
> pf_enable="YES"                  # Set to YES to enable packet filter (pf)
> pflog_enable="YES"               # Set to YES to enable packet filter
> logging
>
> in /etc/rc.conf
>
>
> Regards,
> Vince
> ___
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
>



-- 
Joshua Boyd
JBipNet

E-mail: boy...@jbip.net

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

Re: 8.2-RELEASE pf rules not loading

[Josh Carroll]

> Hi All,
>            Just upgraded my home machine to 8.2-RELEASE via
> freebsd-update remotely (spare time at work.) and on reboot my pf
> ruleset isnt being loaded. running '/etc/rc.d/pf start' once its booted
> does start it fine though. Any suggestions on debugging or shall i just
> try a verbose boot and watch the console when I get home?
> I still have
>
> pf_enable="YES"                  # Set to YES to enable packet filter (pf)
> pflog_enable="YES"               # Set to YES to enable packet filter
> logging
>
> in /etc/rc.conf

Is your interface dynamic (e.g. using DHCP)? If so, you might try changing:

ifconfig_="DHCP"

to

ifconfig_="SYNCDHCP"

It's possible the network hasn't come up properly yet or there is no
IP assigned.

Failing that, you can set:

rc_debug="YES"

in rc.conf then watch at boot time if there are any odd messages when
it attempts to start pf.

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

Re: 8.2/7.4-RELEASEs Announced...

[Clifton Royston]

On Fri, Feb 25, 2011 at 10:00:19AM -0800, jhelf...@e-e.com wrote:
> > On Fri, Feb 25, 2011 at 02:42:25PM +0100, Marco van Tol wrote:
> >>
> >> Read up on the mergemaster manual for options "-F" and "-i" :-)
> > 
> >   freebsd-update does not use mergemaster, though probably it should.
> 
> My understanding is that freebsd-update was introduced prior to releases 
> being branched, so this issue surfaced at that time. The patch I believe 
> would be a fix to the freebsd-update client to better handle the tag. I
> can't see mergemaster as being an easier solution, as the actual binary
> would need to be verified against a known good index that would exist on the
> update server.
> 
> But then, again, I may be wrong.

  You may well be right; I haven't investigated how the two calculate the
differences.

> > We had this discussion a month or two ago.
> 
> Do you have a link to this thread?

Thread title is: "Accidentally aborted upgrade via freebsd-update - how
to recover?"

Relevant discussion starts here, on Dec 27 2010:
 

  -- Clifton

-- 
Clifton Royston  --  clift...@iandicomputing.com / clift...@lava.net
   President  - I and I Computing * http://www.iandicomputing.com/
 Custom programming, network design, systems and network consulting services
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: urtw0: could not allocate USB transfers

[Etienne Robillard]

On 25/02/11 07:31 AM, Bernhard Schmidt wrote:
> On Friday, February 25, 2011 12:47:12 Etienne Robillard wrote:
>   
>> On 25/02/11 06:18 AM, Bernhard Schmidt wrote:
>> 
>>> On Friday, February 25, 2011 11:03:04 Etienne Robillard wrote:
>>>   
>>>   
 On 25/02/11 04:11 AM, Bernhard Schmidt wrote:
 
 
> On Thursday, February 24, 2011 21:51:23 joseph wrote:
>   
>   
>   
>> Hello,
>>
>> i decided to get my laptop wlan via usb because my internal device isn't 
>> supported yet.
>> The usb device is a logilink WL0006 unit its vendorid is 0x0bda and the 
>> productid says 0x8187.
>> My search results say that this device depends on a RTL8187 chipset.
>> I tried both, load the kernel module at boot time and compile kernel 
>> withe urtw, but i get the same output at dmesg
>>
>> device_attach: urtw0 attach returned 6
>> urtw0:  
>> on usbus3
>> urtw0: could not allocate USB transfers, err=USB_ERR_NO_PIPE
>> device_attach: urtw0 attach returned 6
>>
>> im running FreeBSD 8.1-RELEASE-p2 amd64.
>>
>> What might be the reason for this error?
>> Thanks for all hints.
>> 
>> 
>> 
> Well, I have no clue about USB.. but this smells like one of the
> endpoints is 'not there'. At least I can't find any reference to
> it in the Linux driver. Wanna give attached patch a shot?
>   
>   
>   
 Hi Bernard,

 For rt287x based cards, you can try using rt28700 chipset instead of
 urtw0 on
 FreeBSD 8.

 The former is not in the stable src tree, but could be retrieved from here:

 https://gthc.org/distfiles/freebsd/rt2870_fbsd8.tar.gz

 Any takers to make module rt28700 (if_rt2870) officially part of the
 FreeBSD src tree?
 
 
>>> I'm a bit confused now, shouldn't the rt2870 be supported by run(4)? On
>>> a site-note, this is Ralink chipset not a Realtek one.
>>>
>>>   
>>>   
>> I believe this is a different implementation for RT8187 usb network
>> adapters than
>> run(4). However in my view I found urtw0 buggy, but would certainly take
>> a look at run(4) to
>> compare the results with wireless networking agaisnt the other driver
>> (rt28700).
>> 
> Yeah, urtw(4) has a few flaws..
>
> - urtw(4): Realtek RTL8187B/RTL8187L
> - rum(4): Ralink RT2501/RT2601
> - run(4): Ralink RT2700/RT2800/RT3000
>
> So it seems the driver you've posted conflicts with run(4). From a
> quick glance at it, it seems to support 11n? If so, can I talk you
> into working on getting those bits merged?
> Thanks!
>
> --
> Bernhard
> ___
>   
Thanks but I'm not sure I'd be helpful there as I have very moderate
knowledge
in USB and Wifi programming... Also why is "l1n" a important feature
missing from the rt2870 driver ? I achieved very good rates with this card
without it :)

Etienne

-- 
Etienne Robillard

Company: Green Tea Hackers Club
Occupation: Software Developer (and CEO)
E-mail: e...@gthcfoundation.org
Work phone: 450-936-2123
Website (Company):  https://gthc.org/
Website (Blog): https://gthc.org/blog/
PGP public key fingerprint:F2A9 32EA 8E7C 460F 1728  A1A7 649C 7F17 A086 
DDEC

During times of universal deceit, telling the truth becomes a revolutionary 
act. -- George Orwell 

If a free society cannot help the many who are poor, it cannot save the few who 
are rich. -- John F. Kennedy

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

Re: 8.2/7.4-RELEASEs Announced...

[John Baldwin]

On Friday, February 25, 2011 1:00:19 pm jhelf...@e-e.com wrote:
> > On Fri, Feb 25, 2011 at 02:42:25PM +0100, Marco van Tol wrote:
> >>
> >> Read up on the mergemaster manual for options "-F" and "-i" :-)
> > 
> >   freebsd-update does not use mergemaster, though probably it should.
> 
> My understanding is that freebsd-update was introduced prior to releases 
> being branched, so this issue surfaced at that time. The patch I believe 
> would be a fix to the freebsd-update client to better handle the tag. I
> can't see mergemaster as being an easier solution, as the actual binary
> would need to be verified against a known good index that would exist on the
> update server.

No, release branches long pre-date freebsd-update.  However, before we 
switched to svn for source, new branches did not bump all the $FreeBSD$ tags.  
That is a side effect of the way that the SVN -> CVS exporter works (and 
arguably a bug).

BTW, I did design etcupdate to support this sort of use case (you can build a
tarball from a given release tree and use that as the basis for comparisons
assuming you were bootstrapped to use etcupdate).  Currently freebsd-update
doesn't use etcupdate and the author doesn't have any interest in changing it
to do so.

At some point if I have some time to hack on freebsd-update to be more useful
for modified versions of FreeBSD (e.g. building snaps from tags in an SVN
repository instead of a directory of patches against a CVS checkout), I will
probably hack it to support using etcupdate to manage /etc updates as well.

(etcupdate uses something akin to 'svn up' to update files in /etc, so things
like $FreeBSD$ changes just auto-update assuming they don't result in merge
conficts.)

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

Re: urtw0: could not allocate USB transfers

[joseph]

0n 25.02.2011 8:51 PM, Etienne Robillard wrote:

On 25/02/11 07:31 AM, Bernhard Schmidt wrote:

On Friday, February 25, 2011 12:47:12 Etienne Robillard wrote:


On 25/02/11 06:18 AM, Bernhard Schmidt wrote:


On Friday, February 25, 2011 11:03:04 Etienne Robillard wrote:



On 25/02/11 04:11 AM, Bernhard Schmidt wrote:



On Thursday, February 24, 2011 21:51:23 joseph wrote:




Hello,

i decided to get my laptop wlan via usb because my internal device isn't
supported yet.
The usb device is a logilink WL0006 unit its vendorid is 0x0bda and the
productid says 0x8187.
My search results say that this device depends on a RTL8187 chipset.
I tried both, load the kernel module at boot time and compile kernel
withe urtw, but i get the same output at dmesg

device_attach: urtw0 attach returned 6
urtw0:
on usbus3
urtw0: could not allocate USB transfers, err=USB_ERR_NO_PIPE
device_attach: urtw0 attach returned 6

im running FreeBSD 8.1-RELEASE-p2 amd64.

What might be the reason for this error?
Thanks for all hints.




Well, I have no clue about USB.. but this smells like one of the
endpoints is 'not there'. At least I can't find any reference to
it in the Linux driver. Wanna give attached patch a shot?




Hi Bernard,

For rt287x based cards, you can try using rt28700 chipset instead of
urtw0 on
FreeBSD 8.

The former is not in the stable src tree, but could be retrieved from here:

https://gthc.org/distfiles/freebsd/rt2870_fbsd8.tar.gz

Any takers to make module rt28700 (if_rt2870) officially part of the
FreeBSD src tree?



I'm a bit confused now, shouldn't the rt2870 be supported by run(4)? On
a site-note, this is Ralink chipset not a Realtek one.




I believe this is a different implementation for RT8187 usb network
adapters than
run(4). However in my view I found urtw0 buggy, but would certainly take
a look at run(4) to
compare the results with wireless networking agaisnt the other driver
(rt28700).


Yeah, urtw(4) has a few flaws..

- urtw(4): Realtek RTL8187B/RTL8187L
- rum(4): Ralink RT2501/RT2601
- run(4): Ralink RT2700/RT2800/RT3000

So it seems the driver you've posted conflicts with run(4). From a
quick glance at it, it seems to support 11n? If so, can I talk you
into working on getting those bits merged?
Thanks!

--
Bernhard
___


Thanks but I'm not sure I'd be helpful there as I have very moderate
knowledge
in USB and Wifi programming... Also why is "l1n" a important feature
missing from the rt2870 driver ? I achieved very good rates with this card
without it :)

Etienne


Thanks for your fast answers!
I tryed your suggestions but only the urtw driver shows interrest in my 
usb wlan device.

The patched urtw still gives the same error massage.
Could a update to 8.2 fix this issue?

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

Re: 8.2-RELEASE pf rules not loading

[Vincent Hoffman]

On 25/02/2011 17:35, Josh Carroll wrote:
>> Hi All,
>>Just upgraded my home machine to 8.2-RELEASE via
>> freebsd-update remotely (spare time at work.) and on reboot my pf
>> ruleset isnt being loaded. running '/etc/rc.d/pf start' once its booted
>> does start it fine though. Any suggestions on debugging or shall i just
>> try a verbose boot and watch the console when I get home?
>> I still have
>>
>> pf_enable="YES"  # Set to YES to enable packet filter (pf)
>> pflog_enable="YES"   # Set to YES to enable packet filter
>> logging
>>
>> in /etc/rc.conf
> Is your interface dynamic (e.g. using DHCP)? If so, you might try changing:
>
> ifconfig_="DHCP"
>
> to
>
> ifconfig_="SYNCDHCP"
>
> It's possible the network hasn't come up properly yet or there is no
> IP assigned.
>
> Failing that, you can set:
>
> rc_debug="YES"
>
> in rc.conf then watch at boot time if there are any odd messages when
> it attempts to start pf.
>
It turns out that its sort of related to this. I have an IPv6 tunnel
from H.E. (tunnelbroker.net) and from looking at the boot output, it
looks like the IPv6 addresses (for any of my imterfaces) aren't applied
until after pf starts. I'd say this is a bug, Oddly this didnt happen
for the release candidate I tried, although I think I may have modified
my rules and not rebooted until I upgraded.
the rules in question are:

pass in quick on $gif_if inet6 proto udp to $ext_if port $udp_services
keep state
and
pass in quick on $gif_if inet6 proto tcp to $ext_if port $tcp_services
$sf_tcp
(ext_if = "ue0")

I'll try changing $ext_if to the ipv6 address and see if that helps.


Vince



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

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

Re: 8.2-RELEASE pf rules not loading

[Jeremy Chadwick]

On Fri, Feb 25, 2011 at 10:23:58PM +, Vincent Hoffman wrote:
> On 25/02/2011 17:35, Josh Carroll wrote:
> >> Hi All,
> >>Just upgraded my home machine to 8.2-RELEASE via
> >> freebsd-update remotely (spare time at work.) and on reboot my pf
> >> ruleset isnt being loaded. running '/etc/rc.d/pf start' once its booted
> >> does start it fine though. Any suggestions on debugging or shall i just
> >> try a verbose boot and watch the console when I get home?
> >> I still have
> >>
> >> pf_enable="YES"  # Set to YES to enable packet filter (pf)
> >> pflog_enable="YES"   # Set to YES to enable packet filter
> >> logging
> >>
> >> in /etc/rc.conf
> > Is your interface dynamic (e.g. using DHCP)? If so, you might try changing:
> >
> > ifconfig_="DHCP"
> >
> > to
> >
> > ifconfig_="SYNCDHCP"
> >
> > It's possible the network hasn't come up properly yet or there is no
> > IP assigned.
> >
> > Failing that, you can set:
> >
> > rc_debug="YES"
> >
> > in rc.conf then watch at boot time if there are any odd messages when
> > it attempts to start pf.
> >
> It turns out that its sort of related to this. I have an IPv6 tunnel
> from H.E. (tunnelbroker.net) and from looking at the boot output, it
> looks like the IPv6 addresses (for any of my imterfaces) aren't applied
> until after pf starts. I'd say this is a bug, Oddly this didnt happen
> for the release candidate I tried, although I think I may have modified
> my rules and not rebooted until I upgraded.
> the rules in question are:
> 
> pass in quick on $gif_if inet6 proto udp to $ext_if port $udp_services
> keep state
> and
> pass in quick on $gif_if inet6 proto tcp to $ext_if port $tcp_services
> $sf_tcp
> (ext_if = "ue0")
> 
> I'll try changing $ext_if to the ipv6 address and see if that helps.

Please look at pf.conf(5) and search for the word "parentheses" (should
be under the "from x to x" section.  This might resolve your problem.

-- 
| Jeremy Chadwick   j...@parodius.com |
| Parodius Networking   http://www.parodius.com/ |
| UNIX Systems Administrator  Mountain View, CA, USA |
| Making life hard for others since 1977.   PGP 4BD6C0CB |

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

Re: 8.2-RELEASE pf rules not loading

[Vincent Hoffman]

On 25/02/2011 22:31, Jeremy Chadwick wrote:
> On Fri, Feb 25, 2011 at 10:23:58PM +, Vincent Hoffman wrote:
>> On 25/02/2011 17:35, Josh Carroll wrote:
 Hi All,
Just upgraded my home machine to 8.2-RELEASE via
 freebsd-update remotely (spare time at work.) and on reboot my pf
 ruleset isnt being loaded. running '/etc/rc.d/pf start' once its booted
 does start it fine though. Any suggestions on debugging or shall i just
 try a verbose boot and watch the console when I get home?
 I still have

 pf_enable="YES"  # Set to YES to enable packet filter (pf)
 pflog_enable="YES"   # Set to YES to enable packet filter
 logging

 in /etc/rc.conf
>>> Is your interface dynamic (e.g. using DHCP)? If so, you might try changing:
>>>
>>> ifconfig_="DHCP"
>>>
>>> to
>>>
>>> ifconfig_="SYNCDHCP"
>>>
>>> It's possible the network hasn't come up properly yet or there is no
>>> IP assigned.
>>>
>>> Failing that, you can set:
>>>
>>> rc_debug="YES"
>>>
>>> in rc.conf then watch at boot time if there are any odd messages when
>>> it attempts to start pf.
>>>
>> It turns out that its sort of related to this. I have an IPv6 tunnel
>> from H.E. (tunnelbroker.net) and from looking at the boot output, it
>> looks like the IPv6 addresses (for any of my imterfaces) aren't applied
>> until after pf starts. I'd say this is a bug, Oddly this didnt happen
>> for the release candidate I tried, although I think I may have modified
>> my rules and not rebooted until I upgraded.
>> the rules in question are:
>>
>> pass in quick on $gif_if inet6 proto udp to $ext_if port $udp_services
>> keep state
>> and
>> pass in quick on $gif_if inet6 proto tcp to $ext_if port $tcp_services
>> $sf_tcp
>> (ext_if = "ue0")
>>
>> I'll try changing $ext_if to the ipv6 address and see if that helps.
> Please look at pf.conf(5) and search for the word "parentheses" (should
> be under the "from x to x" section.  This might resolve your problem.
That seems looks reasonable, if unexpected since its all statically configured. 
I'll give it a try when I can reboot it next. 

It does seems a little odd that the rcorder doesnt start network_ipv6 (REQUIRE: 
routing) until after pf (BEFORE:  routing) , but I assume there was a reason 
for this.


Vince


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

Re: How to bind a static ether address to bridge?

[Matthew Dillon]

If you can swing a routed network that will definitely have the fewest
complications.

For a switched network if_bridge and ARP have to be integrated, something
I just finished doing in DragonFly, so that all member interfaces of the
bridge use *only* the bridge's MAC for all transactions, including ARP
transactions, whether they require forwarding through the bridge or not.

The bridge has its own internal forwarding table and a great deal of
confusion occurs if the normal ARP code is trying to tie into individual
interfaces instead of just the bridge interface, for *ANY* member of
the bridge, not just the first member of the bridge.

Some of the problems you are likely to hit using if_bridge:

* ARP response flows in on member interface A with an ether destination
  of member interface B.  OS decides to record the ARP route as coming
  from interface B (when it's actually coming from interface A),
  while the bridge internally records the proper forwarding (A).
  Fireworks ensue.

* ARP responses targetting member interfaces which are part of the
  spanning tree protocol (when you have redundant links), and then
  wind up in the blocking state by the spanning tree protocol.

  The if_bridge code in FreeBSD sets the bridge's MAC to be the
  same as the first added interface, which is usually your LAN
  ethernet port.  This will help a bit, just make sure that it *IS*
  your LAN ethernet port and that the spanning tree protocol is *NOT*
  turned on for that port.

  However, other member interfaces (usually TAPs if you are using
  something like OpenVPN) will have different MAC addresses and that
  will cause confusion.

  It might be possible to work around both issues by setting the MAC for
  *ALL* member interfaces to be the same as the bridge MAC, but I don't
  know.  I gave up trying to do that in DFly and instead modified the ARP
  code to always use the bridge MAC for any interface which is a member of
  a bridge.  That appears to have worked quite well.

  My home network (using DragonFly) is using if_bridge to a colocated box,
  ether bridging a class C over three WANs via OpenVPN, with the related
  TAP interfaces and the LAN interface as members of the bridge.  The
  bridge is set up with the spanning tree protocol turned on for the three
  TAP interfaces and with bonding turned on for two of the TAP interfaces.
  But that's with DFly (and I just finished the work two days ago).
  If something similar cannot be done w/FreeBSD then I recommend porting
  the changes from DFly over to FreeBSD's bridging and ARP modules.

  It was a big headache but once I cleared up the ARP confusion things just
  started magically working.

  Other caveats:

* TAP and BRIDGE interfaces are assigned a nearly random MAC address
  when they are created (in FreeBSD the bridge sets its MAC to the
  first member interface so that is at least ok if you always add your
  LAN as the first member interface, however the other member interfaces
  aren't so lucky).  Rebooting the machine containing the bridge or
  destroying and rebuilding the bridge can create total and absolute
  havoc on your network because the rest of your switching
  infrastructure and machines will have the old MACs cached.

  The partial solution is taking on the MAC address of the LAN interface,
  which FreeBSD's bridging code does, and it might be possible to also
  set the other member interfaces to that same MAC (but I don't know if
  that will work).  If not then this is almost a non-solvable problem
  short of making the ARP module more aware of the bridge.

* If using redundant links without bonding support in the bridge code
  the bridge itself will get confused when the topology changes, though
  if it is a simple topology the bridge should be able to start forwarding
  to the backup link even though its internal forwarding table is messed
  up.

  The concept of a 'backup' link is a bit of a hack in the STP code
  (just as the concept of 'bonding' is a bit of a hack), so how well it
  works will depend on a lot of different factors.  The idea of a
  'backup' link is to be able to continue to switch packets when only
  one path is available even if that path has not been completely
  resolved through the STP protocol.

* ARP only works because *EVERYONE* uses the same timeout.  Futzing
  around with member associations on the bridge will cause the bridge
  to forget.  The bridge should theoretically broadcast unicast packets
  for which it doesn't have a forwarding entry but... well, it is still
  possible for machines to get confused.

  When working on your setup you may have to 'arp -d -a' on one or
  more machines multiple times to force them to re-arp and cause all
  your intermediate ethernet switches to r

Re: 8.2-RELEASE pf rules not loading

[jhell]

On Fri, 25 Feb 2011 17:31, freebsd@ wrote:

On Fri, Feb 25, 2011 at 10:23:58PM +, Vincent Hoffman wrote:

On 25/02/2011 17:35, Josh Carroll wrote:

Hi All,
   Just upgraded my home machine to 8.2-RELEASE via
freebsd-update remotely (spare time at work.) and on reboot my pf
ruleset isnt being loaded. running '/etc/rc.d/pf start' once its booted
does start it fine though. Any suggestions on debugging or shall i just
try a verbose boot and watch the console when I get home?
I still have

pf_enable="YES"  # Set to YES to enable packet filter (pf)
pflog_enable="YES"   # Set to YES to enable packet filter
logging

in /etc/rc.conf

Is your interface dynamic (e.g. using DHCP)? If so, you might try changing:

ifconfig_="DHCP"

to

ifconfig_="SYNCDHCP"

It's possible the network hasn't come up properly yet or there is no
IP assigned.

Failing that, you can set:

rc_debug="YES"

in rc.conf then watch at boot time if there are any odd messages when
it attempts to start pf.


It turns out that its sort of related to this. I have an IPv6 tunnel
from H.E. (tunnelbroker.net) and from looking at the boot output, it
looks like the IPv6 addresses (for any of my imterfaces) aren't applied
until after pf starts. I'd say this is a bug, Oddly this didnt happen
for the release candidate I tried, although I think I may have modified
my rules and not rebooted until I upgraded.
the rules in question are:

pass in quick on $gif_if inet6 proto udp to $ext_if port $udp_services
keep state
and
pass in quick on $gif_if inet6 proto tcp to $ext_if port $tcp_services
$sf_tcp
(ext_if = "ue0")

I'll try changing $ext_if to the ipv6 address and see if that helps.


Please look at pf.conf(5) and search for the word "parentheses" (should
be under the "from x to x" section.  This might resolve your problem.




Adding to this and as someone else has already advised in a different way 
is to use synchronous_dhclient="YES" in rc.conf(5) will most likely result 
in your rules loading properly.



--

 jhell

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

FreeBSD 8.1 regression in x86bios.c

[Craig Boston]

Hi all,

My laptop (Toshiba Portege R100) stopped working with an early boot hang 
at some point between 8.0 and 8.1. After it broke last year I had ended 
up just reverting to an earlier kernel, but finally found the time to do 
a binary search and narrow it down.


The offending commit is:
http://svn.freebsd.org/viewvc/base?view=revision&revision=205647 



Fix stupid typos.  Some VESA BIOSes directly call BIOS interrupt handlers
within the VBE interrupt handler.  Unfortunately it was causing real mode
page faults because we were fetching instructions from bogus addresses.
Pass me the pointyhat, please.

PR: kern/144654
MFC after:  3 days

With this commit in place, the system hangs almost immediately on boot, 
right after probing kdbmux. With debug.x86bios.{call,int} enabled from 
the loader, the final lines before the hang are:


avail memory = 1299705856 (1239 MB)
kbd1 at kbdmux0
Calling int 0x10 (ax=0x4f00 bx=0x cx=0x dx=0x es=0x9e00 
di=0x)
Exiting int 0x10 (ax=0x004f bx=0x cx=0x dx=0x es=0x9e00 
di=0x)
Calling int 0x10 (ax=0x4f01 bx=0x cx=0x0144 dx=0x es=0x0200 
di=0x)


Then a hard hang. With the 2 lines in x86bios.c reverted, the system 
boots fine (even on a fresh 8.2 build with just that commit backed out). 
The debug output from a successful boot looks like this:


kbd1 at kbdmux0
Calling int 0x10 (ax=0x4f00 bx=0x cx=0x dx=0x es=0x9e00 
di=0x)
Exiting int 0x10 (ax=0x004f bx=0x cx=0x dx=0x es=0x9e00 
di=0x)
Calling int 0x10 (ax=0x4f01 bx=0x cx=0x0144 dx=0x es=0x0200 
di=0x)
Exiting int 0x10 (ax=0xb13e bx=0x2065 cx=0x9e32 dx=0x1023 es=0x0200 
di=0x0028)
Calling int 0x10 (ax=0x4f01 bx=0x cx=0x0143 dx=0x es=0x9c00 
di=0x)
Exiting int 0x10 (ax=0xb13e bx=0x1065 cx=0x9e32 dx=0x1023 es=0x9c00 
di=0x0028)
Calling int 0x10 (ax=0x4f01 bx=0x cx=0x0141 dx=0x es=0x0200 
di=0x)
Exiting int 0x10 (ax=0xb13e bx=0x0865 cx=0x9e32 dx=0x1023 es=0x0200 
di=0x0028)

(many more lines)

In any event, I'm not sure if this is a true bug, or just a broken BIOS, 
but either way I thought you might want to know about it.


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