**** BEGIN LOGGING AT Thu Feb 18 02:59:57 2010 Feb 18 03:13:43 seems strace is broken again, http://openwrt.pastebin.com/m58259c2f Feb 18 03:14:38 strace and tcpdump b0rked :( Feb 18 03:15:02 rhk`: not much of an upstream considering the source link is dead and mii-tool looks to be obsoleted by ethtool anyways Feb 18 03:15:41 solca: strace actually needs an PKG_INSTALL:=1 Feb 18 03:22:09 swalker_: good to know thx! Feb 18 03:36:07 swalker * r19698 /packages/utils/strace/Makefile: [packages] strace: call the install target, re-remove the obsolete 2.6.21 test, remove the duplicated configure variable Feb 18 03:42:38 thepeople * r19699 /trunk/target/linux/generic-2.6/config-2.6.30: add missing symbol Feb 18 04:38:24 swalker * r19700 /packages/net/tor/Makefile: [packages] tor: update to 0.2.1.23 Feb 18 04:47:58 cshore: can you file luci tickets on its trac? Feb 18 04:48:18 sure Feb 18 04:49:17 can you add a link the LuCI track from OpenWRT trac to make it easier for everybody to do the same? Feb 18 04:52:43 I was just thinking about that Feb 18 04:53:05 don't think I have wiki privs though Feb 18 05:21:40 swalker * r19701 /packages/net/pure-ftpd/Makefile: [packages] pure-ftpd: update to 1.0.28 Feb 18 05:57:10 swalker * r19702 /packages/net/mii-tool/Makefile: [packages] mii-tool: correct the dead urls Feb 18 06:23:04 swalker * r19703 /packages/net/vnstat/patches/ (002-no_install_strip.patch 003-no_install_uname.patch): [packages] vnstat: fix compilation on non-linux hosts (#6656) Feb 18 06:54:48 build #11 of iop32x is complete: Failure [failed compile_10] Build details are at http://tksite.gotdns.org:8010/builders/iop32x/builds/11 Feb 18 06:55:01 ping xMff Feb 18 09:00:42 is this documentation still valid ? http://kamikaze.openwrt.org/docs/openwrt.html Feb 18 09:05:42 <[florian]> a little old, might want to check this one instead: http://downloads.openwrt.org/snapshots/trunk/docs/openwrt.html Feb 18 09:06:24 [florian]: I fixed the reboot problem for the wdt Feb 18 09:06:28 [florian]: are vlans supposed to reduce the available mtu size or is that a bug Feb 18 09:06:34 [florian]: should I post a new patch? Feb 18 09:06:46 <[florian]> rtz: yes please do, can you actually send it to the mailing-list too? Feb 18 09:06:56 <[florian]> cshore: due to the extra 802.1q header, yes Feb 18 09:07:16 [florian]: can do Feb 18 09:07:23 [florian]: ok...just making sure I don't need report a bug Feb 18 09:07:31 <[florian]> rtz: thanks! Feb 18 09:08:18 [florian]: and I would really appreciative it, if this could get commited in a reasonable timeframe Feb 18 09:09:15 <[florian]> rtz: allright, I will make my best Feb 18 09:09:39 [florian]: ok Feb 18 09:09:58 [florian]: should I also post a patches that removes the old wdt driver? Feb 18 09:10:15 <[florian]> no that'd be fine, I will remove it myself when committing your patch Feb 18 09:10:53 ok Feb 18 09:11:52 thx [florian] as always Feb 18 09:22:34 i have a simple problem Feb 18 09:22:43 i have a lua interpreter in /usr/bin/lua Feb 18 09:22:52 i write my test.lua script and it starts with shebangs line Feb 18 09:22:58 #!/usr/bin/lua Feb 18 09:23:08 but if i run ./test.lua i get file not found Feb 18 09:23:24 doesn't busybox honors the hashline? Feb 18 09:24:46 it does Feb 18 09:24:58 is the file executable? Feb 18 09:25:18 yes Feb 18 09:25:19 it is Feb 18 09:26:01 -rwxr-xr-x 1 root root 31 Feb 18 09:22 test.lua Feb 18 09:29:44 it has now started working without explanation Feb 18 09:29:45 mistery! Feb 18 09:42:04 pong cshore Feb 18 09:43:07 xMff: I figured out what's the source of the blank screens...we didn't fix it before, I did a configuration change that didn't use the problematic scenario Feb 18 09:43:29 xMff: the VLANs all have identical MAC addresses by default Feb 18 09:43:46 so it is a layer 3 issue? Feb 18 09:43:57 general network problems Feb 18 09:44:04 xMff: that is my though Feb 18 09:44:08 ok Feb 18 09:44:49 xMff: when I used bridging, then even though I set the mac address in the /etc/config/network the mac address is applied to the bridge not the the VLAN iface Feb 18 09:45:00 but on wrt54gl for example it is normal to have the same mac for every vlan Feb 18 09:45:45 it is the same interface after all Feb 18 09:45:58 xMff: all I know is that when I remove the bridge and am able to set the MAC addresses that the problem goes away Feb 18 09:46:38 it might not the MAC, but the bridge that is the problem Feb 18 09:46:53 but, that's not a problem for regular iface Feb 18 09:47:45 strange Feb 18 09:47:59 actually I have one more test...I'll not set the mac addresses and leave it as ifaces not bridges Feb 18 09:51:09 actually I'm setting the mtu too, come to think of it...maybe the problem is a bridge tries to set the mtu of the bridge but not the underlying iface Feb 18 09:51:18 how could i check if my problem with lua scripts is due to newline/cr problems? Feb 18 09:51:23 is there a power diff on the board? Feb 18 09:52:04 diff is there Feb 18 09:52:42 what can i see from here? http://pastebin.com/m645bbd54 Feb 18 09:52:48 supertest works while test does not work Feb 18 09:53:15 well if every line is detected as changed, then it is most likely \r\n vs. \n Feb 18 09:54:19 dos2unix ? =) Feb 18 09:55:37 sed -i -e s/$'\r'//g file.lua Feb 18 09:55:57 xMff: ok, I just tried with the mac addresses the same but no bridge and it worked Feb 18 09:56:05 xMff: I think it's the mtu Feb 18 09:56:27 xMff: how do you set the mtu of the underlying device when doing a bridged interface? Feb 18 09:56:30 thx xMff Feb 18 09:57:17 cshore: the network config concept lacks options to configure bridge port interfaces, mtu, mac etc. Feb 18 09:57:25 xMff: I noticed that when I had a bridged interface the mtu wasn't reduced Feb 18 09:58:20 xMff: do you mean it is *supposed* to set the base interface? Feb 18 09:58:47 no, it is supposed to operate on iface, which is in the case of bridges, the bridge itself Feb 18 09:58:47 xMff: because it's setting the br-lan but not the eth1.0 interface Feb 18 09:58:55 there is no way to change the member ifaces Feb 18 09:59:41 xMff: that's a bit of a problem Feb 18 10:00:06 well solving this would require restructuring the network config Feb 18 10:02:45 xMff: Florian said that it's normal for the mtu to be reduced on a vlanned device because of the 802.1q header Feb 18 10:04:28 xMff: would it be possible to set the mtu as part of the switch config instead? Feb 18 10:04:46 xMff: since that's the cause of the problem Feb 18 10:05:02 I think it would be possible but it should be made device specific Feb 18 10:05:21 on the wrt54gl the vlan interfaces run with mtu 1500 just fine Feb 18 10:05:28 xMff: I'm just thinking of having a config option to do it Feb 18 10:05:54 xMff: then the user can set the mtu as they wish Feb 18 10:06:15 xMff: vlans are option on brcm63xx Feb 18 10:06:30 xMff: the WAN port is a separate interface Feb 18 10:06:45 so you need to lower your mtu to 1496 to make it work? Feb 18 10:07:26 xMff: I didn't experiment: I just did 1472 as a guess...I'm not sure how big the 802.1q header is Feb 18 10:08:33 4byte iirc Feb 18 10:08:55 xMff: good to know; I can increase my mtu Feb 18 10:10:28 I am no expert but it seems that he ethernet driver must allow an mtu of 1504 when it implements vlans Feb 18 10:10:43 hmmm... Feb 18 10:10:51 I'll have to ask Florian Feb 18 10:11:42 xMff: it would also have to be supported by switches and stuff Feb 18 10:11:48 xMff: not sure, if that's the case Feb 18 10:12:24 rtz: yes, I wonder how it works with b44/roboswitch Feb 18 10:13:00 does the hardware internal fragmentation then? is the frame on the wire really 4 bytes bigger, ... Feb 18 10:14:42 xMff: well, I think it must remove the 802.1q frame when the packets are untagged Feb 18 10:14:49 this is clear Feb 18 10:15:29 xMff: and internally it uses 1504, maybe? Feb 18 10:17:12 the 802.1q standard extended the maximum ethernet frame size by 4 bytes to 1522 Feb 18 10:17:47 so every network hardware that claims to be vlan aware should accept this Feb 18 10:21:19 lowering the mtu is a workaround, it prevents that the ethernet frames exceed 1518 bytes Feb 18 10:22:00 hmmm.....ok, I'll have to file a bug once Trac is back up Feb 18 10:25:56 cshore: but your vlans are untagged, right? Feb 18 10:27:27 leaving the router, yes Feb 18 10:27:49 or least they should be Feb 18 10:28:06 perhaps the switch/phy has an internal mtu field which needs to set to 1522? Feb 18 10:28:13 the bcm63xx enet driver has this defined: #define BCMENET_MAX_MTU 2046 Feb 18 10:28:17 +register Feb 18 10:28:36 or mac Feb 18 10:29:26 xMff: is ethernet working on bcm6345 now? Feb 18 10:29:48 danage: I don't know, you'd have to ask [florian] Feb 18 10:30:13 what about the roboswitch? Feb 18 10:30:25 xMff: okie, thanks Feb 18 10:32:08 hello every one Feb 18 10:33:05 I want to know what mean this errors Create index file './feeds/luaxwrt.index' Feb 18 10:33:07 ERROR: please fix feeds/luaxwrt/webif-iw-lua-openvpn/Makefile Feb 18 10:33:08 ERROR: please fix feeds/luaxwrt/webif-iw-lua-ng/Makefile Feb 18 10:33:10 Collecting package info: done Feb 18 10:33:12 And How I can fix it Feb 18 10:33:36 this means that your makefiles have errors in them Feb 18 10:33:49 missing variables or syntax issues Feb 18 10:33:54 for example tab vs. space Feb 18 10:35:00 ok thanks xMff, must be spaces Feb 18 10:35:04 KanjiMonster: you mean some register that needs to be poked? Maybe yes... Feb 18 10:35:57 might be very well that there is an mtu-register which has a default value of 1518, and the mac rejects any frames bigger than that Feb 18 10:36:37 hmm ... there is a function compute_hw_mtu() which always adds VLAN_ETH_HLEN to the user provided mtu... looks about right to me Feb 18 10:38:46 at least the emac-cores of bcm47xx have a xmtmaxlength-register with a default value of 1518 Feb 18 10:39:29 0 Feb 18 10:39:43 I see, looks like you know more about that than me :) Feb 18 10:40:41 only regarding 47xx Feb 18 10:40:54 cshore: can your verify that it works with mtu set 1496 ? Feb 18 10:41:02 ok Feb 18 10:44:07 yes it does Feb 18 10:48:35 then there's a limit somewhere Feb 18 10:48:56 just a sec...the interface works fine at 1500 without a bridge Feb 18 10:49:03 ah, wait, 1518 already is enough for 1500 + ethernet header + vlan Feb 18 10:49:11 the driver seems to be written with vlan overhead in mind so it might be some bug or a missing hardware setup like KanjiMonster pointed out Feb 18 10:49:53 looking at the driver, it seems to be setup correctly (internal mtu as mtu + 18) Feb 18 10:50:10 hm Feb 18 10:50:26 cshore: is bridge firewalling off? Feb 18 10:50:59 sysctl net.bridge.bridge-nf-call-iptables Feb 18 10:51:00 I currently don't have a firewall on that route...I'll be using shorewall-lite Feb 18 10:51:04 ok Feb 18 10:52:18 hmmm....it might be working now...let me do some tests. This may have been a case of the router needs a power cycle after enable vlan Feb 18 10:53:21 hunting ghosts then ;) Feb 18 10:54:48 I'm hoping so...as aggravating as spending the time chasing them is, it easier than trying to find an elusive bug Feb 18 10:54:56 if it works now Feb 18 10:56:10 I have to run, bbl Feb 18 11:03:07 cshore or use shorewall the old one included in openwrt Feb 18 11:03:26 it work with ash and u dant have to "compile" the firewall on a full blown pc Feb 18 11:03:33 work/works Feb 18 11:03:38 dant/dont Feb 18 11:03:57 There some features like bridge that I want that require the perl compiler Feb 18 11:04:12 okay Feb 18 11:04:22 i liked to shell based shorewall more Feb 18 11:04:32 it sucks that the new version only works with perl Feb 18 11:04:34 imho Feb 18 11:14:55 I agree Feb 18 11:15:13 I'd prefer the new features with the shell version Feb 18 11:20:36 ok, it doesn't work at 1500; that was because I only did a network restart not a reboot Feb 18 11:20:46 it does work at 1496 Feb 18 11:35:40 cshore: yeah me too . but the dev ment this wont happen Feb 18 12:04:24 this guide http://downloads.openwrt.org/snapshots/trunk/docs/openwrt.html Feb 18 12:04:42 explains a lot about networking config eh :) Feb 18 12:05:40 http://wiki.openwrt.org/doc/uci might also help you Feb 18 12:10:15 kaloz * r19704 /trunk/package/grub/patches/010-fixes-1.patch: refresh grub patches Feb 18 12:27:53 hi Feb 18 13:10:24 lars * r19705 /packages/ (166 files in 166 dirs): [packages] Use default templates instead of custom reimplementations where applicable Feb 18 13:10:50 whoa :) Feb 18 13:11:13 spring cleaning Feb 18 13:11:50 dont you wish it was springtime already? Feb 18 13:12:36 yea Feb 18 13:12:48 hi jow Feb 18 13:13:18 hi Feb 18 13:15:23 I figured out that mtu 1500 doesn't work...it only appeared to because I only restarted the network not the router. 1496 works, 1500 doesn't, with vlans Feb 18 13:16:25 cshore: I suspect you will also get problems with other machines in the network Feb 18 13:16:53 you mean with 1496? Feb 18 13:19:21 cshore: with 1500, even if the router supports it in some way Feb 18 13:19:41 rtz2: ah, because the frames would be bigger? Feb 18 13:20:18 well if the frames leaving the device are untagged, why would they be bigger? Feb 18 13:20:43 jow: I agree Feb 18 13:25:16 cshore: not sure, what exactly you are doing, but I mean if the final mtu is > 1500 Feb 18 13:26:17 rtz2: the packets leaving the router should be standard size because the router should be removing the vlan header as they leave Feb 18 13:26:46 ok, then Feb 18 13:27:53 what should I look for in wireshark on the host computer to determine if that is actually the case? Feb 18 13:29:14 cshore: http://en.wikipedia.org/wiki/IEEE_802.1Q Feb 18 13:40:05 does MSS=1460 from the host to router tell me anything useful? Feb 18 13:43:47 I have a frame of 1514 bytes from host to router, which is listed as a TCP segment of a reassembled PDU, and which fails to be be accepted. Feb 18 14:06:30 1514 shouldn't be problem even if the router only could handle 1518 after tagging, right? Feb 18 14:06:51 nbd: are you there? Feb 18 14:07:04 cshore: you may get problems with switches or something in between Feb 18 14:07:38 this is the host computer to the router, 1514 is the ethernet frame Feb 18 14:09:42 ip packet is total 1500, including header of 20 bytes Feb 18 14:11:36 KanjiMonster: yes Feb 18 14:11:47 ah, great Feb 18 14:11:58 I have some questions regarding the ar8216 driver Feb 18 14:13:27 nbd: is query ok? I don't want to spam the channel Feb 18 14:14:37 why not use the channel? maybe it's interesting for more people Feb 18 14:14:58 ok Feb 18 14:15:12 nbd: regarding the default settings when enable_vlan is 0 Feb 18 14:16:19 I am currently working on making the ar8216 driver work for the ar8316, and noticed that it doesn't work until I create vlan table entries for all ports and their port vids Feb 18 14:17:35 makes sense, it needs a forwarding table Feb 18 14:19:24 nbd: that's why I am wondering whether this ever worked on the ar8216 Feb 18 14:21:10 well, we typically install a default config for the switch in /etc/config/network Feb 18 14:22:50 <_trine> is there a problem with the 5GHz radio on the WNDR3700 because it won't come up here? Feb 18 14:23:58 <_trine> Could not select hw_mode and channel. (-1); wlan1: Unable to setup interface.; Failed to start hostapd for phy1 Feb 18 14:30:04 what I also wondered: isn't the atu flushing in the get_status method superflous since aging for address table entires is enabled per switch default (at least on the ar8316)? Feb 18 14:33:19 it looks like the problem with the brcm63xx vlan mtu is a bug...outgoing packets are find at 1514 ethernet frame size, but going into the router 1514 is too big (TCP packet 1500) Feb 18 14:50:47 how does work for openwrt the inclusion of a new target in the tree? Feb 18 14:51:05 is there someone here who could explain me the process a little bit? Feb 18 14:51:49 Lallino: do you have openwrt running on your device? Feb 18 14:53:47 yes i have Feb 18 14:53:54 but i'm almost starting a new project now Feb 18 14:54:13 and I would like to understand more about embedded development Feb 18 14:54:35 I have not yet understood at which point openwrt stops to support specific hardware components Feb 18 14:54:53 for example if i have a generic target with a marvell ethernet switch Feb 18 14:55:04 Lallino: well, I would suggest starting with copying an existing target Feb 18 14:55:21 would the switch be supported in the linux kernel or i need to write a specific adaptation layer for it? Feb 18 14:55:47 Lallino: switches should work without a special driver, but you will need one for vlan support Feb 18 15:05:13 isn't vlan supported by linux kernel? Feb 18 15:06:27 yes but if the hardware has vlan capabilities you need a driver to setup the hardware Feb 18 15:06:40 Lallino: the kernel does, but for example if you have only a single ethernet interface Feb 18 15:06:45 for example to assign vlans to switch ports Feb 18 15:06:57 Lallino: a lot of designs configure the switch to vlans to prove lan and wan Feb 18 15:07:14 Lallino: what platform are you working on? Feb 18 15:07:43 i have not chosen a platform yet Feb 18 15:07:57 at the moment i'm working on an infineon evaluation board which i dislike a lot Feb 18 15:08:27 i'm trying to understand how the things work together Feb 18 15:08:54 if i choose a platform with a switch of 4 ethernet ports Feb 18 15:09:03 with a driver supported in the linux kernel Feb 18 15:09:15 if you have a new platform working, you submit patches for it -- and maybe maintian it later on Feb 18 15:09:31 i would like to understand if there is some additional work to do Feb 18 15:09:52 Lallino: for the switch - probably not Feb 18 15:09:55 okay Kaloz but maybe i can just go and choose a platform among the ones already available Feb 18 15:10:04 but for example if i choose one specific supported platform Feb 18 15:10:29 there are chances that some hw components on my platform won't work just out of the box Feb 18 15:10:53 for example i don't think there is any supported platform by openwrt which provides FXS ports for analog telephones on it Feb 18 15:11:05 then you have to fix that one up, sure Feb 18 15:11:53 but the driver/software i would develop for the fxs ports would go in openwrt or is it something considered used space software or such? Feb 18 15:12:23 you mean user space? Feb 18 15:12:33 depends on your software Feb 18 15:12:43 hi Feb 18 15:12:46 ping nbd Feb 18 15:12:56 a device driver Feb 18 15:13:02 Lallino: and openwrt is more then the kernel, it's also user space Feb 18 15:13:04 is in the kernel or in openwrt? Feb 18 15:13:07 is someone here how knows how to add an option for kernel modules? Feb 18 15:13:11 in package/kernel Feb 18 15:13:26 tripolar_: module insmod option? Feb 18 15:13:27 Lallino: you seem to be a bit confused about that Feb 18 15:13:32 jow_laptop yeah Feb 18 15:13:34 yes i am Feb 18 15:13:41 yeah please tell me how Feb 18 15:13:44 i think i should read the linux device driver book by daniele rubini Feb 18 15:13:50 Lallino: openwrt is similiar to a distribution like debian or fedora or something Feb 18 15:14:13 Lallino: there are many packages in it and also the linux kernel Feb 18 15:14:46 jow_laptop and can u commit the patch for nfsd i yesterday send to the mailing list? Feb 18 15:15:21 rtz2: but if i develop a specif driver for a specific hardware that would be a kind of kernel module I suppose Feb 18 15:15:43 should i commit it into the linux kernel tree (lol) or in openwrt or both? or neither? :D Feb 18 15:15:58 Lallino: usually it is a kernel module Feb 18 15:16:25 tripolar_: I'll look into the nfsd patch later, as for the module option - you can't do that within the current framework Feb 18 15:16:32 Lallino: and you should start with openwrt, if it's accepted there, it will find it's way into the mainline kernel Feb 18 15:16:56 jow_laptop so what would be another way to do it? sed the file in /etc? Feb 18 15:17:32 tripolar_: what kind of option do you need? Feb 18 15:17:38 for lockd Feb 18 15:17:41 tripolar_: and why do you need it? Feb 18 15:17:58 id like to bind it to a specific port to make nfsd ready for firewall usage Feb 18 15:18:14 by now it will bind to a random port when the module is inserted Feb 18 15:18:35 and therefor it is not possible to firewall a host and use nfsd in lan Feb 18 15:19:11 option would be nlm_udpport=32768 nlm_tcpport=3276[D[D[D[D[D[D[D[D8 Feb 18 15:19:21 option would be nlm_udpport=32768 nlm_tcpport=3276 Feb 18 15:20:41 maybe a kernel patch would be more appropriate? Feb 18 15:20:42 thx guys Feb 18 15:20:58 I can't really think of a solution right now, you could try to inject a postinstall script Feb 18 15:20:58 statd and mountd also use random ports but the options can be given to them inside the init script Feb 18 15:21:11 yeah i was thinking about the same idea Feb 18 15:21:36 i think a value that can be changed by the user would be a better idea then a hard coded one in the kernel module Feb 18 15:21:42 or do not autoload at all and defer insmod until the nfs init script runs Feb 18 15:22:34 lockd is only used for nfsd and no other programs? Feb 18 15:22:53 maybe Feb 18 15:23:45 yes, seems to be part of the nfs toolbox Feb 18 15:24:01 and made specifically for nfs Feb 18 15:25:44 okay Feb 18 15:26:08 yeah someone (like you) would have to remove the outload function from the fs.mk file Feb 18 15:26:28 i can change nfsd on my own Feb 18 15:30:15 jow_laptop: can u do this? Feb 18 15:30:51 no this wont work Feb 18 15:30:56 lockd 58640 2 nfsd,nfs Feb 18 15:31:10 so all nfs modules would have to loaded by the init script Feb 18 15:32:30 and thats no good idea Feb 18 15:34:32 tripolar_: /proc/sys/fs/nfs/nlm_tcpport and /proc/sys/fs/nfs/nlm_udpport - use these in the init script to fix the port number Feb 18 15:34:53 hmm can this be done afterwards? Feb 18 15:34:58 yes Feb 18 15:37:11 cool you are right Feb 18 15:37:11 you can even use sysctl Feb 18 15:37:54 yeah fs.nfs.nlm_tcpport Feb 18 15:38:35 sysctl -w fs.nfs.nlm_tcpport=32776 Feb 18 15:38:37 works Feb 18 15:38:38 nice Feb 18 15:43:07 has anyone already made a package with sources in a bazaar repository? Feb 18 15:51:19 jow_laptop are u still here? Feb 18 15:53:38 ping thepeople Feb 18 16:05:24 jow_laptop: is thepeople the only one maintaining the svn accounts? Feb 18 16:05:37 tripolar_: pong Feb 18 16:05:57 thepeople my write access on svn doesnt work... Feb 18 16:06:07 tripolar_: I am the person that is sitting in the middle of the package maintainers so stuff doesn't fall through the cracks Feb 18 16:06:12 tripolar_: ok what package? Feb 18 16:06:18 nfs-kernel-server Feb 18 16:06:20 in packages Feb 18 16:07:34 tripolar_: you never mentioned wanting to maintain that package Feb 18 16:07:44 i told u this an the irc Feb 18 16:07:50 and u ment u can add this program Feb 18 16:07:58 an=on Feb 18 16:08:35 tripolar_: then it is my mistake, I will get you added and let you know when it goes live Feb 18 16:10:04 thepeople okay Feb 18 16:16:25 tripolar_: should be working now Feb 18 16:17:19 thanks Kaloz Feb 18 16:18:42 tripolar * r19706 /packages/net/nfs-kernel-server/files/nfsd.init: nfs-kernel-server: make lockd, statd and mountd bind to fixed ports to make it useable with a firewall Feb 18 16:18:51 yeah it does Feb 18 16:20:22 thanks thepeople Kaloz Feb 18 16:23:15 tripolar * r19707 /packages/net/nfs-kernel-server/Makefile: nfs-kernel-server: release++ Feb 18 16:29:58 obsy * r19708 /packages/net/transmission/Makefile: [packages] transmission: update to 1.90 Feb 18 17:01:29 thanks xMff, rtz: I think I have solved the mtu problem with a patch (but this one is definitely going by Florian first) Feb 18 17:11:30 cshore: could you show me? Feb 18 17:20:12 http://openwrt.pastebin.ca/1801744 Feb 18 17:21:34 it works for me, but it might break something I haven't seen yet Feb 18 17:25:11 cshore: well, i don't know much about this code, I was only interested about the solution :) Feb 18 17:26:16 the part I'm not sure about is VLAN_ETH_FRAM_LEN...that might be fine as it was, and the only thing really needed was for the hardware mtu to change Feb 18 17:26:47 and VLAN_ETH_FRAME_LEN could result to too big packets for tagged vlan leaving the router Feb 18 17:39:46 IEEE 802.3ac specifies the maximum allowed frame length for tagged vlans as 1522 bytes and 1518 for untagged Feb 18 17:40:28 unfortunately I can't find a publically accisble pdf to cite Feb 18 17:40:35 *accessible Feb 18 17:40:42 **quote Feb 18 17:40:43 ... Feb 18 17:41:05 jow: so it should be right? Feb 18 17:42:16 well, I don't know whether the 4 bytes are added somewhere else already Feb 18 17:43:47 have you tested whether it works with just the first hunk (actual_mtu += ...) applied? Feb 18 17:43:53 not yet Feb 18 17:44:09 will do that now Feb 18 17:47:14 cshore: oh - and use VLAN_HLEN instead of VLAN_SWITCH_HLEN Feb 18 17:47:27 since this one is already defined Feb 18 17:47:41 VLAN_HLEN affects a whole bunch of things Feb 18 17:47:59 I mean this: actual_mtu += VLAN_ETH_HLEN + VLAN_HLEN; Feb 18 17:48:04 nothing else changed Feb 18 17:48:25 jow: yes but VLAN_HLEN is used elsewhere Feb 18 17:48:41 well, thats the point of defines :) Feb 18 17:49:08 VLAN_HLEN is descriped as "The additional bytes (on top of the Ethernet header) that VLAN requires." Feb 18 17:49:12 jow: but I'm pretty sure changing VLAN_HLEN will break things Feb 18 17:49:14 this is exactly what you want there Feb 18 17:49:20 why change? Feb 18 17:49:25 not change, use Feb 18 17:49:54 oh, I see, doh Feb 18 17:50:25 I was confusing VLAN_ETH_HLEN and VLAN_HLEN Feb 18 17:50:54 http://openwrt.pastebin.com/m58e4fbdb Feb 18 17:51:37 yes, if I can get quilt to obey me Feb 18 18:01:11 anyone know how to get avahi-autoip to work? Feb 18 18:30:59 ping xMff Feb 18 18:31:12 ping nbd Feb 18 18:32:56 pong Feb 18 18:33:12 have you seen the automount patches I've done up? Feb 18 18:34:43 not yet Feb 18 18:34:47 i'll take a look at them later Feb 18 18:36:41 ok...also, what do you think on the packaging side...I initially tried to keep it simple, but there seemed to be a desire to have it split out...I value your input on how it should be packaged Feb 18 18:41:30 Hi, I'm trying to compile openwrt 8.09.2 on ubuntu 9.10 Feb 18 18:41:36 but I get the following error: Feb 18 18:41:49 *** This configuration requires the GNU assembler Feb 18 18:41:51 make[4]: *** [configure-gcc] Error 1 Feb 18 18:41:53 make[4]: Leaving directory `/home/skaapgif/Workspace/WISPr/OpenWrt/8.09.2/build_dir/toolchain-mips_gcc4.1.2/gcc-4.1.2-initial' Feb 18 18:42:08 I do however have binutils installed Feb 18 18:43:11 does brcm47xx also have a /proc/diag/led dir? Feb 18 18:43:37 sKAApGIF: check the configure log, what went wrong Feb 18 18:44:14 this is the crux of it: Feb 18 18:44:18 int main() { Feb 18 18:44:22 #if __GNU_MP_VERSION < 3 Feb 18 18:44:24 choke me Feb 18 18:44:26 #endif Feb 18 18:47:46 cshore: why keep the plugin paths in the config? Feb 18 18:47:56 for fsck Feb 18 18:48:01 that seems a bit unnecessary to me Feb 18 18:49:31 also, about the modularization: i do think it would be nice to keep the automounting stuff in a package separate from base-files Feb 18 18:49:44 but i think the small fsck handler shell scripts should be part of the fsck packages themselves Feb 18 18:50:06 that's what I did originally Feb 18 18:50:26 ok Feb 18 18:50:40 to keep things simple, we also shouldn't split things up too much Feb 18 18:51:02 +$(eval $(call BuildPackage,block-mount)) Feb 18 18:51:02 +$(eval $(call BuildPackage,block-hotplug)) Feb 18 18:51:02 +$(eval $(call BuildPackage,block-swap)) Feb 18 18:51:02 +$(eval $(call BuildPackage,block-blkid)) Feb 18 18:51:07 [... Feb 18 18:51:15 that looks a bit confusing Feb 18 18:52:44 also, about busybox vs util-linux: when there's a feature provided by both, we should probably stick to the one in busybox, unless the util-linux one provides extra features Feb 18 18:52:56 for instance swapon is probably so small that we could just enable it by default Feb 18 18:53:13 ok, that applies to blkid too, most likely Feb 18 18:53:18 yeah Feb 18 18:53:28 then we can keep the script handlers for it in the core package Feb 18 18:53:35 right Feb 18 18:53:47 too much configurability with alternatives makes things confusing for users Feb 18 18:54:12 that was part of the problem is that I was trying keep the scripts with the programs it depended on Feb 18 18:54:51 with stuff provided by busybox we should make an exception Feb 18 18:54:51