Found while reading the code and testing ifconfig(8)'s `tunneldomain' in
order to document MPLS ioctls (see other thread on tech@).
mpe(4) consistently uses the softc's rdomain which is tracked
consistently across the various ioctls.
mpip(4) always adds and deletes routes in rdomain 0 regardless
In "vmctl status", VMs that are being stopped but are still running
will simply show up as "running".
The diff below gives preference to showing the stopping state akin to
how a paused VM is handled.
Index: usr.sbin/vmctl/vmctl.c
===
On 13 Mar at 09:17, Otto Moerbeek wrote:
> On Sat, Mar 13, 2021 at 12:08:52AM -0800, Mike Larkin wrote:
> > On Wed, Mar 10, 2021 at 08:30:32PM +0100, Mischa wrote:
> > > On 10 Mar at 18:59, Mike Larkin wrote:
> > > > On Wed, Mar 10, 2021 at 03:08:21PM +0100, Mischa wrote:
> > > > > Hi All,
> > >
On Sat, Mar 13, 2021 at 11:31:05PM +0100, Klemens Nanni wrote:
> 3. bug?: mpe(4) does not delete the label upon SIOCDELLABEL:
>
> # ifconfig mpe
> mpe: no such interface
> # ifconfig mpe0 create
> # ifconfig mpe0
> mpe0: flags=10 mtu 1500
> index 39 pri
Split off init_ifaces from update_iface. init_ifaces discovers the
state of the machine on startup using ioctl(2) and getifaddrs(3).
We can then update this state with information provided by route
messages. We still need getifaddrs(3) to check if the layer 2 address
has changed.
This simplifies e
Stefan Sperling [s...@stsp.name] wrote:
>
> Sending BA req frames with the firmware node which represents the AP seems to
> fix the problem. I have not yet managed to trigger it again with this patch.
> My best explanation is that this allows the firmware to retry block ack
> requests properly, an
On 3/16/21 2:38 PM, Stefan Sperling wrote:
> However, the second frame was sent at 24 Mbit/s, which
> indicates that the firmware could be retrying the BA request (frames sent
> at a different Tx rate than specified by the driver are generally retries).
My guess would be that a CRC fails causing a
While testing my RA patches, I've seen iwn "hang" even though the AP and
iwn client were still exchanging packets at the wifi layer, but the upper
layers IP/UDP/TCP etc. were stuck. I could easily trigger this by running
tcpbench and moving towards the edge of the range of my AP.
Traffic would reco
On Tue, Mar 16, 2021 at 07:56:26AM -0600, Todd C. Miller wrote:
> I think it makes more sense to have the information in the MTU/MSS
> ISSUES section where people are more likely to look for it.
Fine with me, no need to bikeshed this.
OK kn with the typofix.
On 2021/03/16 13:59, Klemens Nanni wrote:
> On Tue, Mar 16, 2021 at 06:08:00AM -0600, Todd C. Miller wrote:
> > I think it is helpful to tell the user what happens if the remote
> > endpoint doesn't support RFC 4638.
> The manual section basically says that already (last sentence):
>
> MTU/MSS ISS
Hi,
I am running ntpd as a client with three upstream servers. Some
of them are not synchonized and report a time that is off by several
seconds.
The ntpd client code corrects both T1 and T4 with the current offset
returned by adjtime(2) from the kernel. T1 is local time when the
NTP packet is
On Tue, 16 Mar 2021 13:59:20 +0100, Klemens Nanni wrote:
> It doesn't hurt however to mention the specific message such that users
> can tell *when* that happens; perhaps add it under DIAGNOSTICS as the
> various wifi driver manuals, e.g. athn(4) do?
I think it makes more sense to have the infor
On Tue, Mar 16, 2021 at 06:08:00AM -0600, Todd C. Miller wrote:
> I think it is helpful to tell the user what happens if the remote
> endpoint doesn't support RFC 4638.
The manual section basically says that already (last sentence):
MTU/MSS ISSUES
Problems can arise on machines with private I
I think it is helpful to tell the user what happens if the remote
endpoint doesn't support RFC 4638.
OK?
- todd
Index: share/man/man4/pppoe.4
===
RCS file: /cvs/src/share/man/man4/pppoe.4,v
retrieving revision 1.34
diff -u -p -u -r
On Tue, Mar 16, 2021 at 08:55:43AM +0100, Claudio Jeker wrote:
> > .Sh HISTORY
> > -The
> > +The ,
>
> Why did you add this ',' that looks strange to me.
>
> > .Nm
> > device first appeared in
> > .Ox 4.4 .
Fat fingers; fixed now.
Index: share/man/man4/mpe.4
==
On Tue, Mar 16, 2021 at 12:23:31AM +0100, Klemens Nanni wrote:
> On Sat, Mar 13, 2021 at 11:45:30PM +0100, Claudio Jeker wrote:
> > On Sat, Mar 13, 2021 at 11:31:05PM +0100, Klemens Nanni wrote:
> > > First off: I've never used mpe(4), mpw(4) or mpip(4); this occured to
> > > me while looking at i
16 matches
Mail list logo
