Re: kernel: in6_delayed_cksum: delayed m_pullup
В Thu, 10 May 2018 16:56:38 +0200 "Dries Michiels" <driesm.michi...@gmail.com> пишет: > I had updated the day after to see if it was just a regression but > the error message was not gone: May 1 22:19:51 vados kernel: > in6_delayed_cksum: delayed m_pullup, m->len: 48 plen 68 off 56 > csum_flags=400 May 1 22:27:57 vados last message > repeated 29 times May 1 22:36:53 vados last message repeated 17 > times May 1 22:49:41 vados last message repeated 6 times May 1 > 23:00:09 vados last message repeated 8 times May 1 23:01:06 vados > last message repeated 7 times May 1 23:18:05 vados last message > repeated 12 times For this reason I had disabled IPV6 for my LAN > clients (disabled rtadvd). My server was still ipv6 reachable and > error messages where gone. I've observed such messages when ipv6 packets was passed via ipv4 NAT. After changing ipfw rule from (for example) nat 1 ip from any to me in via re1 to nat 1 ipv4 from any to me in via re1 this messages has gone. -- Alexander Zagrebin ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: local_unbound, resolvconf, vpn
Hi! Also I have to notice that there is another issue with the default local_unbound setup: by default unbound uses syslog for logging, but usually the local_unbound service starts before syslogd and so logging doesn't work until local_unbound will be reloaded. So it's looks reasonable to use logging to file by default. As unbound runs in chroot, the log file has to be inside of the /var/unbound directory, but now this directory contains a config files. I suggest to change the /var/unbound structure to be more hier(7) friendly. For example, /var /unbound /etc - unbound configuration files /conf.d - additional configuration files /var /log- unbound log files -- Alexander Zagrebin ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: local_unbound, resolvconf, vpn
В Wed, 8 Nov 2017 13:38:28 +0200
Andriy Gapon <a...@freebsd.org> пишет:
> I've just enabled local_unbound on a machine and everything seems to
> work fine. But there are a few minor quirks that I would like to
> report.
> Last. Every time I connect to a VPN (via vpnc or openvpn, for
> exmaple) the unbound daemon is restarted. That's expected because
> its configuration is changed. But there is a slightly annoying
> message that appears to be harmless: unbound: [7457:0] error: cannot
> chdir to directory: (No such file or directory)
>
> I wonder what causes this messages and if it's possible to shut it up.
This message appears because you are using chroot.
You have to edit /var/unbound/unbound.conf and add a trailing slash to
value of the 'directory' parameter:
server:
...
chroot: /var/unbound
directory: /var/unbound/
...
When unbound uses chroot, it determines the directory name, that it will
be use for chdir call, taking in account the value of 'chroot'
parameter. If 'chroot' equals 'directory' the unbound will call
chdir(''), which will cause an error.
--
Alexander Zagrebin
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Help provisioning a Samba AD in a jail on ZFS
В Mon, 6 Nov 2017 08:26:05 +0100 Andrea Venturoli <m...@netfence.it> wrote: > > To setup a new samba46-based domain controller on ZFS in jail (I'm > > using it with the VIMAGE) you can try following: > > I'm not using VIMAGE (at least not yet). > > > 1. Rebuild the net/samba46 port with the attached patches > > (patch-librpc__idl__xattr.idl, > > patch-python__samba__provisioninit__.py) > > > > 2. Initialize new domain with the following command (the last two > > parameters makes magic): > > samba-tool domain provision --use-rfc2307 \ > > --host-name= \ > > --realm= \ > > --domain= \ > > --adminpass= \ > > --option="vfs objects = acl_xattr" \ > > --option="acl_xattr:ignore system acls = yes" > > > > 3. After successful provisioning, edit /usr/local/etc/smb4.conf: > > - remove or comment out > > vfs objects = acl_xattr > > acl_xattr:ignore system acls = yes > > - add the following: > > vfs objects = zfsacl > > nfs4:mode = special > > nfs4:acedup = merge > > nfs4:chown = yes > > > > 4. Execute `samba-tool ntacl sysvolreset` > > > > 5. Start samba > > Looks like it worked. > Hope I don't get any suprise in the deployment phase... There is an issue, when GPOs are situated on the ZFS: sometimes (when a new file appended?) the GPO's files gets a wrong permissions. So if you will have problems with a group policy, run `samba-tool ntacl sysvolreset` at first... -- Alexander Zagrebin ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Help provisioning a Samba AD in a jail on ZFS
В Wed, 1 Nov 2017 16:01:18 +0100
Andrea Venturoli <m...@netfence.it> пишет:
It seems it's offtopic here, but I'll try to answer.
To setup a new samba46-based domain controller on ZFS in jail (I'm
using it with the VIMAGE) you can try following:
1. Rebuild the net/samba46 port with the attached patches
(patch-librpc__idl__xattr.idl, patch-python__samba__provisioninit__.py)
2. Initialize new domain with the following command (the last two
parameters makes magic):
samba-tool domain provision --use-rfc2307 \
--host-name= \
--realm= \
--domain= \
--adminpass= \
--option="vfs objects = acl_xattr" \
--option="acl_xattr:ignore system acls = yes"
3. After successful provisioning, edit /usr/local/etc/smb4.conf:
- remove or comment out
vfs objects = acl_xattr
acl_xattr:ignore system acls = yes
- add the following:
vfs objects = zfsacl
nfs4:mode = special
nfs4:acedup = merge
nfs4:chown = yes
4. Execute `samba-tool ntacl sysvolreset`
5. Start samba
It is not ideal solution, but it seems to be working,
despite there are another resolvable issues (with BIND9_DLZ
and so on)...
I've sent patches to the port maintainer, but have no answer.
> As per subject, I'm building a new box which must host a jail running
> a Samba AD, but I have trouble provisioning it.
> Currently I'm trying samba44.
>
> I read a lot of material and I think I understand the problem: it
> seems the "samba-tool provision" script is incompatible with NFSv4ACL
> used by ZFS. AFAICT this issue has been raised, the Samba team has
> acknowledged a patch should be made, but so far nothing happened.
>
> So I'm looking into workarounds:
>
> a) someone suggest installing samba43, provision, then upgrade to
> samba44. In fact this is some path I went through a couple of times
> in the past (on UFS, however). Alas samba43 is no longer there.
>
> b) I think I might get around this by provisioning with the
> deprecated NTVFS, then switch to S3FS.
> Unfortunately samba44 does not build NTVFS anymore, unless the
> DEVELOPER option is used; but if the DEVELOPER option is used
> compilation (on Poudriere) fails with:
> > ../source4/lib/socket/socket_ip.c:864:12: error: comparison of
> > array 'addr.__u6_addr.__u6_addr8' equal to a null pointer is always
> > false [-Werror,-Wtautological-pointer-compare] if (addr.s6_addr ==
> > 0) { ~^~~~ /usr/include/netinet6/in6.h:103:29: note:
> > expanded from macro 's6_addr' #define s6_addr __u6_addr.__u6_addr8
> > ^
> > 1 error generated.
>
> c) I tried creating a ZVOL, formatting it with UFS, mounting it with
> ACLs inside the jail, but still provisioning says I have no ACL
> support.
>
> d) I know samba46 is incompatible with jails (at least as AD DC), but
> didn't try samba45. AFAICT, however, nothing should have improved WRT
> to my problem.
>
> So, after spending a couple of days on this and before spending
> another week trying every path, I tought I'd ask...
>
> Should I temporarily revive samba43?
> Can samba44 with NTVFS compilation error be fixed?
> Should I try samba45 or is it just a waste of time?
> Would creating a jail on another (UFS) box and then moving
> /var/db/samba4 and smb4.conf here work?
>
> I'm open to any other suggestion as long as the objective (AD in a
> jail on ZFS) is met in the end.
--
Alexander Zagrebin
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: if_run in hostap mode: issue with stations in the power save mode
Hi!
On 07.02.2011 09:11:02 +0100, Bernhard Schmidt wrote:
For example, if you call 'ifconfig wlan0 ssid newssid' the new ssid is
passed over using a IOCTL. It would be interesting to know what function
in net80211 are called regarding beacon updates and which of those call
into the run driver. Ultimately it's about figuring out if special
handling for such cases are required and if so, how to do it.
I've added a debug output on allocation, changing and deallocation of a
beacon into if_run.c and tried to change SSID while the net.wlan.0.debug is -1.
Here is the log contents:
kernel: wlan0: ieee80211_init
kernel: wlan0: start running, 1 vaps running
kernel: wlan0: ieee80211_new_state_locked: RUN - SCAN (nrunning 0 nscanning 0)
kernel: wlan0: ieee80211_newstate_cb: RUN - INIT arg 0
kernel: wlan0: hostap_newstate: RUN - INIT (0)
kernel: wlan0: node_reclaim: remove 0xff8003bd70:14:d1:a8:66:1d from
station table, refcnt 1
kernel: wlan0: ieee80211_alloc_node 0xff8004eae0:14:d1:a8:66:1d in
station table
kernel: wlan0: [00:14:d1:a8:66:1d] ieee80211_alloc_node: inact_reload 2
kernel: wlan0: ieee80211_newstate_cb: INIT - SCAN arg 0
kernel: wlan0: hostap_newstate: INIT - SCAN (0)
kernel: wlan0: ieee80211_create_ibss: creating HOSTAP on channel 6
kernel: wlan0: ieee80211_alloc_node 0xff8003bd70:14:d1:a8:66:1d in
station table
kernel:
kernel: wlan0: [00:14:d1:a8:66:1d] ieee80211_alloc_node: inact_reload 2
kernel: wlan0: set WME_AC_BE (chan) [acm 0 aifsn 3 logcwmin 4 logcwmax 6 txop 0]
kernel: wlan0: set WME_AC_BE (bss ) [acm 0 aifsn 3 logcwmin 4 logcwmax 10 txop
0]
kernel: wlan0: set WME_AC_BK (chan) [acm 0 aifsn 7 logcwmin 4 logcwmax 10 txop
0]
kernel: wlan0: set WME_AC_BK (bss ) [acm 0 aifsn 7 logcwmin 4 logcwmax 10 txop
0]
kernel: wlan0: set WME_AC_VI (chan) [acm 0 aifsn 1 logcwmin 3 logcwmax 4 txop
94]
kernel: wlan0: set WME_AC_VI (bss ) [acm 0 aifsn 2 logcwmin 3 logcwmax 4 txop
94]
kernel: wlan0: set WME_AC_VO (chan) [acm 0 aifsn 1 logcwmin 2 logcwmax 3 txop
47]
kernel: wlan0: set WME_AC_VO (bss ) [acm 0 aifsn 2 logcwmin 2 logcwmax 3 txop
47]
kernel: wlan0: ieee80211_wme_updateparams_locked: WME params updated, cap_info
0x6
kernel: wlan0: ieee80211_new_state_locked: SCAN - RUN (nrunning 0 nscanning 0)
kernel: wlan0: ieee80211_newstate_cb: SCAN - RUN arg -1
kernel: run0: run_update_beacon_cb: updating beacon
kernel: wlan0: ieee80211_beacon_update: traffic 0, enable aggressive mode
kernel: wlan0: update WME_AC_BE (chan+bss) [acm 0 aifsn 2 logcwmin 4 logcwmax
10 txop 0]
kernel: wlan0: update WME_AC_BE (chan+bss) logcwmin 3
kernel: wlan0: ieee80211_wme_updateparams_locked: WME params updated, cap_info
0x7
kernel: wlan0: hostap_newstate: SCAN - RUN (-1)
kernel: wlan0: synchronized with 00:14:d1:a8:66:1d ssid test channel 6 start
0Mb
kernel: wlan0: [00:14:d1:a8:66:1d] ieee80211_node_authorize: inact_reload 20
As you can see, run_update_beacon_cb() is invoked, but at this time the
beacon is already allocated. As the beacon is allocated, run_update_beacon_cb()
invokes ieee80211_beacon_update(). As we know, the ieee80211_beacon_update()
doesn't update the SSID, so the SSID remains untouched.
Nevertheless the changing or hiding/unhiding a SSID seems to be working.
It is possible to explain: the station uses an active scan.
The ieee80211_send_proberesp()/ieee80211_alloc_proberesp() returns the frame,
containing an updated SSID, but AP continues to broadcast beacon with the
outdated data.
The possible solution is to deallocate a beacon on a state change.
I've decided to deallocate a beacon on 'to RUN' state transition.
The additional patch is attached.
I'll do an additional tests later today...
--
Alexander Zagrebin
--- /sys/dev/usb/wlan/if_run.c.orig 2011-02-08 09:52:18.994743647 +0300
+++ /sys/dev/usb/wlan/if_run.c 2011-02-08 11:04:17.114484851 +0300
@@ -1793,6 +1793,12 @@ run_newstate(struct ieee80211vap *vap, e
sc-runbmap |= bid;
}
+ if (rvp-beacon_mbuf) {
+ m_freem(rvp-beacon_mbuf);
+ rvp-beacon_mbuf = NULL;
+ }
+
switch (vap-iv_opmode) {
case IEEE80211_M_HOSTAP:
case IEEE80211_M_MBSS:
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: if_run in hostap mode: issue with stations in the power save mode
Hi! On 08.02.2011 10:52:53 +0100, Bernhard Schmidt wrote: I've combined both patches (see attachment), if I get an ACK from both of you I'll try get this into the tree ASAP. The resulted patch works fine for me. Big thanks for your help! Waiting for the 802.11n support... :) -- Alexander Zagrebin ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: if_run in hostap mode: issue with stations in the power save mode
Hi! On 06.02.2011 11:32:40 +0100, Bernhard Schmidt wrote: I had the doubts about ability to change or hide/unhide the SSID, but it works too. It seems that after `ifconfig wlan0 ssid ...` or `ifconfig wlan0 (hidessid|-hidessid)` the following occurs: 1. run_newstate() is called 2. run_newstate() invokes run_update_beacon_cb() 3. run_update_beacon_cb() invokes ieee80211_beacon_update() But I couldn't understand where ieee80211_beacon_update() can change a SSID... As I see it, it can't. Only a call to ieee80211_beacon_construct() would do that. Can I talk you into figuring out what's going on here? Getting a definitive statement about SSID changes are correctly handled (by means of a trace) would help alot. Yes, sure! What kind of information you need? -- Alexander Zagrebin ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: if_run in hostap mode: issue with stations in the power save mode
Hi! On 04.02.2011 09:51:34 +0100, Bernhard Schmidt wrote: On Friday 04 February 2011 07:08:08 Alexander Zagrebin wrote: I'm using an Ralink RT2870 based adapter (run(4) driver) in the hostap mode. and I've noticed that if_run doesn't support stations working in the power save mode (PSM). The reason is in lack of the TIM in beacons. The attached patch adds this functionality and completely fixes this issue. Despite the fact that patch is working, it seems that it needs an additional work. For example, now the result of ieee80211_beacon_update is ignored with a corresponding message, but may be necessary to process it... Can somebody review it? That looks about right, good catch! Handling ieee80211_beacon_update()'s return value doesn't seem to be necessary, the mbuf's length is handled in the next few lines of code anyways, doesn't matter if it changed or not. Though, I have a some doubts about just restoring bo_flags is enough (Can't prove that with some obvious code, still..). It feels saner to me if we just reuse the whole mbuf, similar to what ath(4) does. Can you look at attached patch? Completely untested, so I'm not sure what does happen on e.g. changing the SSID. I've thought about such solution, and it looks more right, but I've decided just to add ieee80211_beacon_update() to make the patch clear. I'll try your patch a bit later, but I already have a question: on the first invocation of the run_update_beacon_cb() only ieee80211_beacon_alloc() will be called. So dynamic beacon contents will not updated. Is it a problem? Also I have to note, that it seems that other wlan drivers can has this problem too: only ral's and ath's code uses ieee80211_beacon_update(). Also, I've found a kern/124753. One of replies contains a log's fragment with many records, like following: kernel: ath0: [00:18:41:c0:06:54] power save mode on, 1 sta's in ps mode kernel: ath0: [00:18:41:c0:06:54] save frame with age 0, 1 now queued kernel: ath0: [00:18:41:c0:06:54] save frame with age 0, 2 now queued kernel: ath0: [00:18:41:c0:06:54] power save mode off, 0 sta's in ps mode kernel: ath0: [00:18:41:c0:06:54] flush ps queue, 2 packets queue But there are no records, which have to be for a PSM enabled stations: When a beacon is properly updated, then we have to see records about 1. TIM updating, like ieee80211_beacon_update: TIM updated, pending 1, off 0, len 1 2. poll messages from a stations, like wlan0: [18:86:ac:10:4b:88] recv ps-poll, send packet, queue empty Thanks for your cooperation! -- Alexander Zagrebin ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: if_run in hostap mode: issue with stations in the power save mode
Hi!
On 04.02.2011 09:51:34 +0100, Bernhard Schmidt wrote:
On Friday 04 February 2011 07:08:08 Alexander Zagrebin wrote:
I'm using an Ralink RT2870 based adapter (run(4) driver) in the
hostap mode. and I've noticed that if_run doesn't support stations
working in the power save mode (PSM). The reason is in lack of the
TIM in beacons. The attached patch adds this functionality and
completely fixes this issue. Despite the fact that patch is working,
it seems that it needs an additional work. For example, now the
result of ieee80211_beacon_update is ignored with a corresponding
message, but may be necessary to process it...
Can somebody review it?
That looks about right, good catch!
Handling ieee80211_beacon_update()'s return value doesn't seem to be
necessary, the mbuf's length is handled in the next few lines of code
anyways, doesn't matter if it changed or not.
Though, I have a some doubts about just restoring bo_flags is enough
(Can't prove that with some obvious code, still..). It feels saner to me
if we just reuse the whole mbuf, similar to what ath(4) does. Can you
look at attached patch? Completely untested, so I'm not sure what does
happen on e.g. changing the SSID.
I've tried the slightly modified version of your patch (see attached files),
and found that it is working too. Moreover, it looks more safe.
For example, suppose we need update the beacon due to a new TIM.
Immediately after updating, but before the beacon with a TIM will be
transmitted, we need update the beacon again for any other reason. With
the first version of the patch the beacon will completely recreated, so
a TIM will be lost. But if we are using the second version of the patch,
then TIM will be preserved.
I had the doubts about ability to change or hide/unhide the SSID, but it
works too. It seems that after `ifconfig wlan0 ssid ...` or `ifconfig wlan0
(hidessid|-hidessid)` the following occurs:
1. run_newstate() is called
2. run_newstate() invokes run_update_beacon_cb()
3. run_update_beacon_cb() invokes ieee80211_beacon_update()
But I couldn't understand where ieee80211_beacon_update() can change a SSID...
--
Alexander Zagrebin
--- sys/dev/usb/wlan/if_run.c.orig 2011-01-21 08:28:14.0 +0300
+++ sys/dev/usb/wlan/if_run.c 2011-02-04 21:01:38.659409262 +0300
@@ -856,6 +856,8 @@
RUN_LOCK(sc);
+ m_freem(rvp-beacon_mbuf);
+
rvp_id = rvp-rvp_id;
sc-ratectl_run = ~(1 rvp_id);
sc-rvp_bmap = ~(1 rvp_id);
@@ -3903,6 +3905,7 @@
struct run_softc *sc = ic-ic_ifp-if_softc;
uint32_t i;
+ setbit(RUN_VAP(vap)-bo.bo_flags, item);
i = RUN_CMDQ_GET(sc-cmdq_store);
DPRINTF(cmdq_store=%d\n, i);
sc-cmdq[i].func = run_update_beacon_cb;
@@ -3916,6 +3919,7 @@
run_update_beacon_cb(void *arg)
{
struct ieee80211vap *vap = arg;
+ struct run_vap *rvp = RUN_VAP(vap);
struct ieee80211com *ic = vap-iv_ic;
struct run_softc *sc = ic-ic_ifp-if_softc;
struct rt2860_txwi txwi;
@@ -3925,8 +3929,14 @@
if (vap-iv_bss-ni_chan == IEEE80211_CHAN_ANYC)
return;
- if ((m = ieee80211_beacon_alloc(vap-iv_bss, RUN_VAP(vap)-bo)) == NULL)
- return;
+ if (rvp-beacon_mbuf == NULL) {
+ m = ieee80211_beacon_alloc(vap-iv_bss, rvp-bo);
+ if (m == NULL) return;
+ rvp-beacon_mbuf = m;
+ } else {
+ m = rvp-beacon_mbuf;
+ ieee80211_beacon_update(vap-iv_bss, rvp-bo, m, 1);
+ }
memset(txwi, 0, sizeof txwi);
txwi.wcid = 0xff;
@@ -3941,13 +3951,11 @@
txwi.flags = RT2860_TX_TS;
txwi.xflags = RT2860_TX_NSEQ;
- run_write_region_1(sc, RT2860_BCN_BASE(RUN_VAP(vap)-rvp_id),
+ run_write_region_1(sc, RT2860_BCN_BASE(rvp-rvp_id),
(uint8_t *)txwi, sizeof txwi);
- run_write_region_1(sc, RT2860_BCN_BASE(RUN_VAP(vap)-rvp_id) + sizeof txwi,
+ run_write_region_1(sc, RT2860_BCN_BASE(rvp-rvp_id) + sizeof txwi,
mtod(m, uint8_t *), (m-m_pkthdr.len + 1) ~1); /* roundup len */
- m_freem(m);
-
return;
}
--- sys/dev/usb/wlan/if_runvar.h.orig 2010-11-20 10:22:53.446928634 +0300
+++ sys/dev/usb/wlan/if_runvar.h 2011-02-04 20:03:08.090731320 +0300
@@ -121,6 +121,7 @@
struct run_vap {
struct ieee80211vap vap;
struct ieee80211_beacon_offsets bo;
+ struct mbuf *beacon_mbuf;
int (*newstate)(struct ieee80211vap *,
enum ieee80211_state, int);
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: if_run in hostap mode: issue with stations in the power save mode
Hi! On 04.02.2011 13:14:17 +0100, Bernhard Schmidt wrote: Also I have to note, that it seems that other wlan drivers can has this problem too: only ral's and ath's code uses ieee80211_beacon_update(). Yeah, true. Also, I've found a kern/124753. One of replies contains a log's fragment with many records, like following: kernel: ath0: [00:18:41:c0:06:54] power save mode on, 1 sta's in ps mode kernel: ath0: [00:18:41:c0:06:54] save frame with age 0, 1 now queued kernel: ath0: [00:18:41:c0:06:54] save frame with age 0, 2 now queued kernel: ath0: [00:18:41:c0:06:54] power save mode off, 0 sta's in ps mode kernel: ath0: [00:18:41:c0:06:54] flush ps queue, 2 packets queue But there are no records, which have to be for a PSM enabled stations: When a beacon is properly updated, then we have to see records about 1. TIM updating, like ieee80211_beacon_update: TIM updated, pending 1, off 0, len 1 2. poll messages from a stations, like wlan0: [18:86:ac:10:4b:88] recv ps-poll, send packet, queue empty Thanks for your cooperation! You mean there are missing debug messages in net80211/run? I meant, that when stations in the PSM are handled correctly, then the log contains a records like this: kernel: wlan0: [18:86:ac:10:4b:88] power save mode on, 1 sta's in ps mode kernel: wlan0: [18:86:ac:10:4b:88] save frame with age 8, 1 now queued kernel: wlan0: ieee80211_beacon_update: TIM updated, pending 1, off 0, len 1 kernel: wlan0: [18:86:ac:10:4b:88] recv ps-poll, send packet, queue empty kernel: wlan0: ieee80211_beacon_update: TIM updated, pending 0, off 0, len 1 But the log's fragment from the kern/124753 doesn't contain records with the text ...TIM updated... and ...recv ps-poll I had the very similar records in the log with the unpatched if_run.c. -- Alexander Zagrebin ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
if_run in hostap mode: issue with stations in the power save mode
I'm using an Ralink RT2870 based adapter (run(4) driver) in the hostap mode. and I've noticed that if_run doesn't support stations working in the power save mode (PSM). The reason is in lack of the TIM in beacons. The attached patch adds this functionality and completely fixes this issue. Despite the fact that patch is working, it seems that it needs an additional work. For example, now the result of ieee80211_beacon_update is ignored with a corresponding message, but may be necessary to process it... Can somebody review it? -- Alexander Zagrebin --- sys/dev/usb/wlan/if_run.c.orig 2011-01-21 08:28:14.0 +0300 +++ sys/dev/usb/wlan/if_run.c 2011-02-03 20:46:16.80991 +0300 @@ -3903,6 +3903,7 @@ struct run_softc *sc = ic-ic_ifp-if_softc; uint32_t i; + setbit(RUN_VAP(vap)-bo.bo_flags, item); i = RUN_CMDQ_GET(sc-cmdq_store); DPRINTF(cmdq_store=%d\n, i); sc-cmdq[i].func = run_update_beacon_cb; @@ -3921,13 +3922,25 @@ struct rt2860_txwi txwi; struct mbuf *m; uint8_t ridx; + uint8_t flags[4]; if (vap-iv_bss-ni_chan == IEEE80211_CHAN_ANYC) return; + /* + * ieee80211_beacon_construct called from ieee80211_beacon_alloc + * will clear bo_flags, so we need store it for later use + */ + memcpy(flags, RUN_VAP(vap)-bo.bo_flags, sizeof(flags)); + if ((m = ieee80211_beacon_alloc(vap-iv_bss, RUN_VAP(vap)-bo)) == NULL) return; + /* Now we may restore bo_flags and update the dynamic beacon contents */ + memcpy(RUN_VAP(vap)-bo.bo_flags, flags, sizeof(flags)); + if (ieee80211_beacon_update(vap-iv_bss, RUN_VAP(vap)-bo, m, 1)) + device_printf(sc-sc_dev, ieee80211_beacon_update failed\n); + memset(txwi, 0, sizeof txwi); txwi.wcid = 0xff; txwi.len = htole16(m-m_pkthdr.len); ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
8.2-PRERELEASE: if_bridge ARP and broadcasts issues
Hi! I've found some issues with the if_bridge on 8.2-PRERELEASE. 1. An ARP issue Suppose we have a box with the 4 interfaces: nic0, nic1, nic2, nic3. The interfaces are linked pairwise using 2 bridge(4) interfaces: bridge0 and bridge1. Only nic0 has an IP address assigned (for example, 192.168.0.1/24). So we have configuration like this: 192.168.0.1 ---nic0---+ +---nic2--- | | bridge0 bridge1 | | ---nic1---+ +---nic3--- The problem: when ARP query about MAC address of 192.168.0.1 is received on the nic2 or nic3, then system responds with the MAC address of the nic0, though networks on the bridge0 and bridge1 are completely independent. IMHO, it isn't correct. The reason is in ARP handling code: it looks for an address of the interface belonging to a bridge, but there is not check that a bridge is the same. Attached patch (patch-if_ether.c) fixes the issue. 2. Broadcasts issue I have a box with two NICs: re0 and wlan0. re0 and wlan0 are members of the bridge0. re0 has IP address 192.168.1.1; wlan0 hasn't an address configured. I have the samba installed. The smbd and nmbd listens on the 192.168.1.1. There are no problems with the clients connected to the re0, but the samba clients connected to the wlan0 has problems with the network browsing and domain logons. I've found that nmbd doesn't receive udp broadcasts received on the wlan0, though bridge0 successfully retransmits this broadcast out of re0. I've looked in the sources, and it seems that in this case subnet broadcasts have to be handled in ether_output(), but this doesn't work anyway... Can anybody help to fix this issue? -- Alexander Zagrebin ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: 8.2-PRERELEASE: if_bridge ARP and broadcasts issues
Hi!
On 25.01.2011 16:32:26 +0300, Alexander Zagrebin wrote:
Attached patch (patch-if_ether.c) fixes the issue.
It seems the attached file has disappeared.
I'll try again...
--
Alexander Zagrebin
--- sys/netinet/if_ether.c.orig 2011-01-16 21:01:41.0 +0300
+++ sys/netinet/if_ether.c 2011-01-25 13:48:47.859914728 +0300
@@ -551,7 +551,7 @@
*/
IN_IFADDR_RLOCK();
LIST_FOREACH(ia, INADDR_HASH(itaddr.s_addr), ia_hash) {
- if (((bridged ia-ia_ifp-if_bridge != NULL) ||
+ if (((bridged ia-ia_ifp-if_bridge == ifp-if_bridge) ||
ia-ia_ifp == ifp)
itaddr.s_addr == ia-ia_addr.sin_addr.s_addr) {
ifa_ref(ia-ia_ifa);
@@ -568,7 +568,7 @@
}
}
LIST_FOREACH(ia, INADDR_HASH(isaddr.s_addr), ia_hash)
- if (((bridged ia-ia_ifp-if_bridge != NULL) ||
+ if (((bridged ia-ia_ifp-if_bridge == ifp-if_bridge) ||
ia-ia_ifp == ifp)
isaddr.s_addr == ia-ia_addr.sin_addr.s_addr) {
ifa_ref(ia-ia_ifa);
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: 8.2-PRERELEASE: if_bridge ARP and broadcasts issues
Hi! On 25.01.2011 18:25:10 +0200, Nikos Vassiliadis wrote: The reason is in ARP handling code: it looks for an address of the interface belonging to a bridge, but there is not check that a bridge is the same. Attached patch (patch-if_ether.c) fixes the issue. I tried your patch and it works for me. Thanks for confirmation! 2. Broadcasts issue I have a box with two NICs: re0 and wlan0. re0 and wlan0 are members of the bridge0. re0 has IP address 192.168.1.1; wlan0 hasn't an address configured. I have the samba installed. The smbd and nmbd listens on the 192.168.1.1. There are no problems with the clients connected to the re0, but the samba clients connected to the wlan0 has problems with the network browsing and domain logons. I've found that nmbd doesn't receive udp broadcasts received on the wlan0, though bridge0 successfully retransmits this broadcast out of re0. I've looked in the sources, and it seems that in this case subnet broadcasts have to be handled in ether_output(), but this doesn't work anyway... Can anybody help to fix this issue? As far as I recall, the recommended setup is to assign IP addresses to the bridge interface, not the member interfaces. Could you try this? Yes, when ip address is assigned to bridge0 or inbound interface (wlan0 in this case) then there are no problems. This may be used as workaround, but... As there is no direct interdiction to use addresses bound to a member interfaces, it seems it's a bug. -- Alexander Zagrebin ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: NAT-T/UDPENCAP patch from stable/7
Hi! On 23.01.2011 16:13:48 +, Bjoern A. Zeeb wrote: here is a version of the NAT-T/UDPENCAP patch as in 8 and 9 for today's stable/7 for anyone who might want/need it. I would expect it will equally apply to 7.4-RELEASE once that happened. http://people.freebsd.org/~bz/20110123-01-stable7-natt.diff You will need to figure out the right version of ipsec-tools or other IKE clients yourself though. Until now (at least on the 8.2-PRERELEASE) the setkey from the base distribution doesn't dump the SAD entries (`setkey -D`) if NAT-T is used. It reports: Invalid extension type. Will be this fixed? -- Alexander Zagrebin ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: if_run and wlan_amrr: kernel panics on 8.2-PRERELEASE amd64
Hi!
On 19.01.2011 17:57:00 +0100, Bernhard Schmidt wrote:
So there is the one issue only: the panic if runfw.ko and
wlan_amrr.ko both loaded via loader.conf.
Have you any ideas?
No yet, I'll dig around there later today.
Hmm, I'm not able to reproduce this, works as expected. Is this still the
same
backtrace as the previous error?
It seems that no. I've recompiled a kernel with the KDB support and got this:
kernel trap 12 with interrupts disabled
Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address = 0x308
fault code = supervisor read data, page not present
instruction pointer = 0x20:0x8030161a
stack pointer = 0x28:0x80b7ec30
frame pointer = 0x28:0x80b7ec60
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= resume, IOPL = 0
current process = 0 (swapper)
trap number = 12
panic: page fault
cpuid = 0
KDB: stack backtrace:
#0 0x8033408e at kdb_backtrace+0x5e
#1 0x80303037 at panic+0x187
#2 0x804cbbd0 at trap_fatal+0x290
#3 0x804cbfaf at trap_pfault+0x28f
#4 0x804cc48f at trap+0x3df
#5 0x804b4594 at calltrap+0x8
#6 0x8041a4e0 at LibAliasAttachHandlers+0x160
#7 0x80b71024 at mod_handler+0x14
#8 0x802f2318 at module_register_init+0xb8
#9 0x802bdc77 at mi_startup+0x77
#10 0x80162b3c at btext+0x2c
Uptime: 1s
Automatic reboot in 15 seconds - press a key on the console to abort
-- Press a key on the console to reboot,
-- or switch off the system now.
I have an 'alias_pptp_load=YES' in the loader.conf, so I've disabled
alias_pptp.ko instead of if_run.ko, runfw.ko or wlan_amrr.ko,
and the system was successfully booted.
It's very strange...
# kgdb kernel.debug
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for details.
This GDB was configured as amd64-marcel-freebsd...
(kgdb) list *LibAliasAttachHandlers+0x160
0x8041a4e0 is in LibAliasAttachHandlers
(../../../netinet/libalias/alias_mod.c:84).
79 }
80
81 static __inline void
82 LIBALIAS_WLOCK(void)
83 {
84 rw_wlock(handler_rw);
85 }
86
87 static __inline void
88 LIBALIAS_WUNLOCK(void)
(kgdb)
I understand, that it isn't wlan problem now, but may be you have any thoughts?
--
Alexander Zagrebin
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: if_run and wlan_amrr: kernel panics on 8.2-PRERELEASE amd64
Hi! On 19.01.2011 09:37:12 +0100, Bernhard Schmidt wrote: Case 2: wlan_amrr.ko loaded manually _after_ if_run.ko but before creation of the wlan interface stable/8: panic on rate control rev217511: no panic, but rate control doesn't work; tx rate is fixed on 1 Mbit/s That sounds rather weird to me, I can't imagine how the module loading order should make any difference. Well, at least, before creating the VAP, because that is the point where that stuff gets initialized/used. It seems you're right. I couldn't reproduce it again. May be I have missed anything. Sorry... Do you have anything configured in rc.conf maybe? That would create the VAP right after loading if_run.ko even before you are able to load wlan_amrr.ko. Yes, I have wlans_run0=wlan0 and create_args_wlan0=... in the rc.conf, but while testing I've used `ifconfig wlan0 destroy` after `kldload if_run`. May be it was mistyping... Also I've noticed that messages like ieee80211_load_module: load the wlan_amrr module by hand for now. has disappeared from the log. Is it normal? So there is the one issue only: the panic if runfw.ko and wlan_amrr.ko both loaded via loader.conf. Have you any ideas? Will be rev. 217511 MFC'd on the 20 january? -- Alexander Zagrebin ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: if_run and wlan_amrr: kernel panics on 8.2-PRERELEASE amd64
Hi! On 19.01.2011 01:23:18 -0800, PseudoCylon wrote: mostly works (there is an issue with the devices with the 'power save mode' enabled), If device, connected to the freebsd based AP, is in 'power save mode', then there are: - very large dispersion of the ping time; like this 64 bytes from 192.168.1.12: icmp_seq=0 ttl=68 time=228.479 ms 64 bytes from 192.168.1.12: icmp_seq=1 ttl=68 time=2695.647 ms 64 bytes from 192.168.1.12: icmp_seq=2 ttl=68 time=1674.081 ms 64 bytes from 192.168.1.12: icmp_seq=3 ttl=68 time=653.757 ms 64 bytes from 192.168.1.12: icmp_seq=4 ttl=68 time=3785.051 ms 64 bytes from 192.168.1.12: icmp_seq=5 ttl=68 time=2764.311 ms 64 bytes from 192.168.1.12: icmp_seq=6 ttl=68 time=1742.506 ms 64 bytes from 192.168.1.12: icmp_seq=7 ttl=68 time=720.719 ms 64 bytes from 192.168.1.12: icmp_seq=10 ttl=68 time=568.465 ms 64 bytes from 192.168.1.12: icmp_seq=11 ttl=68 time=3.489 ms 64 bytes from 192.168.1.12: icmp_seq=12 ttl=68 time=8469.515 ms 64 bytes from 192.168.1.12: icmp_seq=13 ttl=68 time=7447.776 ms 64 bytes from 192.168.1.12: icmp_seq=14 ttl=68 time=6428.403 ms 64 bytes from 192.168.1.12: icmp_seq=15 ttl=68 time=5407.636 ms 64 bytes from 192.168.1.12: icmp_seq=16 ttl=68 time=4385.875 ms 64 bytes from 192.168.1.12: icmp_seq=17 ttl=68 time=3364.814 ms 64 bytes from 192.168.1.12: icmp_seq=18 ttl=68 time=2343.062 ms 64 bytes from 192.168.1.12: icmp_seq=19 ttl=68 time=1322.413 ms 64 bytes from 192.168.1.12: icmp_seq=20 ttl=68 time=300.670 ms 64 bytes from 192.168.1.12: icmp_seq=25 ttl=68 time=206.728 ms - periodical loss of packets, designated to device (like keepalive, icmp etc.), isn't it? Yes, there is. Due to lack of documents, I haven't figured out how to add support, how to set tim, etc. Due to lack of documents, related to the Ralink chipsets? enabled), but transmission rate is limited with 1 Mbit/s. Can you try attached patch and see if tx rate goes up. It seems the commit r217511 have fixed issue. Have you any thoughts about kernel panic when if_run, runfw and wlan_amrr are loaded via loader.conf? -- Alexander Zagrebin ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: if_run and wlan_amrr: kernel panics on 8.2-PRERELEASE amd64
Hi! On 19.01.2011 17:57:00 +0100, Bernhard Schmidt wrote: So there is the one issue only: the panic if runfw.ko and wlan_amrr.ko both loaded via loader.conf. Have you any ideas? No yet, I'll dig around there later today. Hmm, I'm not able to reproduce this, works as expected. Is this still the same backtrace as the previous error? The panic occurs on very early stage, so there is no dump created. I'll try to recompile kernel with the kdb support tomorrow. May be it will help to get backtrace. -- Alexander Zagrebin ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
if_run and wlan_amrr: kernel panics on 8.2-PRERELEASE amd64
/kern_shutdown.c:592 #3 0x804cb9ad in trap_fatal (frame=0x80727ec0, eva=Variable eva is not available. ) at ../../../amd64/amd64/trap.c:783 #4 0x804cbd6f in trap_pfault (frame=0xff807811d9a0, usermode=0) at ../../../amd64/amd64/trap.c:699 #5 0x804cc16f in trap (frame=0xff807811d9a0) at ../../../amd64/amd64/trap.c:449 #6 0x804b43c4 in calltrap () at ../../../amd64/amd64/exception.S:224 #7 0x80c5204b in amrr_rate (ni=0xff800dcfc000, arg=0x0, iarg=0) at /usr/src/sys/modules/wlan_amrr/../../net80211/ieee80211_amrr.c:231 #8 0x80ab81bb in run_iter_func (arg=0xff8000baf000, ni=0xff800dcfc000) at ieee80211_ratectl.h:92 #9 0x80ad77e4 in ieee80211_iterate_nodes (nt=0xff8000bbb7b0, f=0x80ab8160 run_iter_func, arg=0xff8000baf000) at /usr/src/sys/modules/wlan/../../net80211/ieee80211_node.c:2147 #10 0x80abadaf in run_ratectl_cb (arg=Variable arg is not available. ) at /usr/src/sys/modules/usb/run/../../../dev/usb/wlan/if_run.c:2212 #11 0x8033f035 in taskqueue_run_locked (queue=0xff0001a2d800) at ../../../kern/subr_taskqueue.c:250 #12 0x8033f1ce in taskqueue_thread_loop (arg=Variable arg is not available. ) at ../../../kern/subr_taskqueue.c:387 #13 0x802da6e8 in fork_exit (callout=0x8033f180 taskqueue_thread_loop, arg=0xff8000bba0b8, frame=0xff807811dc40) at ../../../kern/kern_fork.c:845 #14 0x804b488e in fork_trampoline () at ../../../amd64/amd64/exception.S:565 #15 0x in ?? () #16 0x in ?? () #17 0x in ?? () #18 0x in ?? () #19 0x in ?? () #20 0x in ?? () #21 0x in ?? () #22 0x in ?? () #23 0x in ?? () #24 0x in ?? () #25 0x in ?? () #26 0x in ?? () #27 0x in ?? () #28 0x in ?? () #29 0x in ?? () #30 0x in ?? () #31 0x in ?? () #32 0x in ?? () #33 0x in ?? () #34 0x in ?? () #35 0x in ?? () #36 0x in ?? () #37 0x in ?? () #38 0x in ?? () #39 0x80732980 in affinity () #40 0x in ?? () #41 0x in ?? () #42 0xff000198d000 in ?? () #43 0xff807811d600 in ?? () #44 0xff807811d5a8 in ?? () #45 0xff00014d0460 in ?? () #46 0x80328009 in sched_switch (td=0x8033f180, newtd=0xff8000bba0b8, flags=Variable flags is not available. ) at ../../../kern/sched_ule.c:1852 Previous frame inner to this frame (corrupt stack?) (kgdb) Any help is appreciated. -- Alexander Zagrebin ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: if_run and wlan_amrr: kernel panics on 8.2-PRERELEASE amd64
Hi! On 18.01.2011 12:31:20 +0100, Bernhard Schmidt wrote: I'm trying to use the RT2872-based USB adapter in the hostap mode on the latest RELENG_8 (8.2-PRERELEASE) for amd64. [..] Pull that http://svn.freebsd.org/viewvc/base?view=revisionrevision=217511 and let me know if that fixes the issue. I've retrieved the ieee80211_node.c and if_run.c and recompiled wlan.ko and if_run.ko. Here results: Case 1: both if_run.ko and wlan_amrr.ko are loaded via loader.conf stable/8: panic rev217511: panic Case 2: wlan_amrr.ko loaded manually _after_ if_run.ko but before creation of the wlan interface stable/8: panic on rate control rev217511: no panic, but rate control doesn't work; tx rate is fixed on 1 Mbit/s Case 3: wlan_amrr.ko loaded _before_ if_run.ko stable/8: panic on rate control rev217511: no panic, rate control works as expected So rev217511 partially fixes the issue. -- Alexander Zagrebin ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
8.1-RC2: bug in ng_ipfw (ng_ipfw doesn't return a packet back to ipfw)
After upgrading from RELENG_8_0 to RELENG_8_1 (8.1-RC2) I have noticed that ng_ipfw doesn't return a packet back to ipfw after `ipfw add ... netgraph ...` due to the bug in the sys/netgraph/ng_ipfw.c The attached patch solves the problem. -- Alexander patch-sys-netgraph-ng_ipfw.c Description: Binary data ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
