**** BEGIN LOGGING AT Mon Jan 02 02:59:56 2012 Jan 02 07:22:15 build #122 of s3c24xx is complete: Failure [failed compile_10] Build details are at http://buildbot.openwrt.org:8010/builders/s3c24xx/builds/122 Jan 02 13:13:02 jow * r29638 /tags/backfire_10.03.1/package/base-files/files/etc/openwrt_version: [10.03.1] fix openwrt_version entry **** BEGIN LOGGING AT Mon Jan 02 13:47:34 2012 Jan 02 20:10:36 obsy * r29639 /packages/net/transmission/ (Makefile files/transmission.init): [package] transmission: Fix peer_socket_tos option. Jan 02 21:03:00 nbd. i got some netifd questions/comments if you're around and have bit free time? Jan 02 21:03:15 sure Jan 02 21:03:53 great. i'll start with little background. Jan 02 21:04:54 been playing with multiple wan links. multiwan kinda works but it's not what i'm after. i believe basic multihoming, ie. support to route return packets thru same interface original came in, should be separate from multiwan. Jan 02 21:05:10 it was fairly easy to implement with old scripts. not quite so with netifd. Jan 02 21:05:53 with netifd even very basics like route metrics, not setting default route etc. are not implemented. i know it's not final but bit worried if these parts will be fixed before release or not Jan 02 21:06:51 can i get wishlist item for netifd to create route table when new interface comes up and populate that route table with default route thru default gw received from ppp/dhcp/static settings for that interface Jan 02 21:07:20 i was planning on adding more extensive support for policy routing and route properties Jan 02 21:07:29 great :) Jan 02 21:07:33 and one of the main design goals in netifd was to handle all that in the core Jan 02 21:07:39 instead of adding special cases to each protocol handler Jan 02 21:07:53 any chance someone could come the linux-atm patches I posted? thanks. Jan 02 21:08:10 even better. in that case i guess i'll do my hacks to old system and wait until netifd is "complete" Jan 02 21:08:25 feel free to send me patches if you want to look into things yourself Jan 02 21:08:48 if you need any help figuring out the code structure, let me know Jan 02 21:09:27 i'd love to, but as usual, lot of ideas but not enough skills. ip routing is something i can do and so is hacking scripts. however when we're talking about writing new code in c, sorry. :( Jan 02 21:09:52 for some of the enhancements like metrics it's just a matter of adding a few lines Jan 02 21:11:26 with non-netifd scripts what i added were three ip route rules to scripts so traffic with wan2 source will always be routed out using route table created for that interface. port forward towards wan>lan / wan2>lan hosts seemed to require mark/connmark but works ok after adding those. Jan 02 21:14:08 ok, so we have an option for suppressing default route setting, setting route metrics, assigning interface routes to a table, configuring ip rules Jan 02 21:14:14 need anything else in netifd? Jan 02 21:16:37 gateway-less static routes when not using point-to-point interface with dynamic ip would be nice. Jan 02 21:16:58 ok Jan 02 21:17:09 making a new todo list for netifd right now Jan 02 21:18:00 that works with old scripts, they take default-gw from that interface (even if big metric) and use it instead Jan 02 21:18:21 eventually i'd like to have multiwan integrated in netifd Jan 02 21:18:43 i also want to have a mode where netifd can test a link before activating the ip rule to use its routes Jan 02 21:19:10 not sure if route tables will take care of dhcp renew packets? seen problems where dhcp server is in different subnet and packets are routed to it via wrong isp. result is renews failing and disconnection which can be difficult to track depending how long leases are Jan 02 21:19:23 eventually i'll move the dhcp client to netifd Jan 02 21:20:16 dns routes are also one thing. i'd like to see it by default but at least as an option to route traffic to dns via same interface their ips were received. Jan 02 21:20:33 dns routes? Jan 02 21:21:01 had weird problem last week that turned out to be due isp dns. as dnsmasq sends queries sometimes to all servers and uses first reply. Jan 02 21:22:06 "wan2" isp has one dns resolver that returns "nxdomain" to all queries not coming from their own ip range. now when packets were set via "wan1" isp dnsmasq served clients not found replies more or less randomly. Jan 02 21:22:39 usual would be refused or timeout, but they're sending not found instead. nasty. Jan 02 21:22:49 hm, makes sense Jan 02 21:26:32 pasted some notes from my testing to http://pastebin.com/TnHefDSh . i got answers to my questions and rest are probably known issues. Jan 02 21:27:46 speaking of default routes Jan 02 21:28:03 apparently there are ISPs who advertise gateways with DHCP wich are outside of the assigned subnet Jan 02 21:28:14 jr-: if you can still reproduce the segfault, it should store a core file in /tmp Jan 02 21:28:17 jr-: get me that core Jan 02 21:28:56 adding a simple default route (route add default gw foo dev bla) will fail. I'd propose to always to route add -host foo dev bla; route add default gw foo Jan 02 21:29:10 this will work in normal cases and in cases where the gw is outside of the subnet Jan 02 21:29:15 nbd. is core deleted after restarting netifd? haven't booted device since it segfaulted but did restart netifd and there's no core Jan 02 21:29:48 it's not deleted automatically Jan 02 21:30:02 do you have CONFIG_KERNEL_ELF_CORE=y in your .config? Jan 02 21:32:28 haven't changed that setting. running r29634 with only change from default being enabling netifd + comgt (to get netifd version). wzr-hp-ag300h Jan 02 21:34:03 jow. any ideas why they do that? saving one ip (or maybe three with hsrp) out of large subnet with customers doesn't make sense. or are they giving client ip with /32 mask for example and then gw is obviously outside it. Jan 02 21:34:13 try running 'ulimit -c unlimited' before starting netifd from the command line Jan 02 21:34:19 (bypassing the init script) Jan 02 21:34:44 jr-: no idea. I got a pcap dump from a user, they give you some random rfc1918 ip with a /24 prefix and a gateway which lies in another /24 Jan 02 21:34:46 nbd. yep, that's it of course as i started it from command line to see logs Jan 02 21:34:56 obsy * r29640 /packages/net/transmission/files/transmission.config: [package] transmission: oops, missing value for peer_socket_tos. Jan 02 21:35:56 btw. the last segfault is from netifd? Jan 02 21:36:07 because there's another segfault in that log that appears to come from something else Jan 02 21:37:29 noticed same thing. after last one netifd was no longer running so i think it is. i'll try to reproduce it by starting and stopping 3g. that's when it happened. Jan 02 21:37:44 ok Jan 02 21:41:40 what would be sensible values to use for debug mask and log level parameters? Jan 02 21:43:03 seems rapidly taking 3g up/down causes pppd process to stay running but ppp interface staying down. after that further attempts to start/stop 3g do nothing. netifd might need some logic to spot such misbehaving pppd and kill it. Jan 02 21:44:19 I found similar behaviour in my local tests Jan 02 21:44:36 Jan 2 23:31:12 OpenWrt daemon.notice pppd[15365]: Connect: 3g-e220 <--> /dev/ttyUSB0 Jan 02 21:44:39 Jan 2 23:31:13 OpenWrt daemon.info pppd[15365]: Terminating on signal 15 Jan 02 21:44:41 15365 root 1516 S /usr/sbin/pppd nodetach ipparam e220 ifname 3g-e220 Jan 02 22:18:32 loswillios: are you there , to discuss pulseaudio stuff ? Jan 02 22:19:17 i'm not sure wether it's appropriate to file a bug report without checking with you first about trivial stuff I should check... Jan 02 22:59:24 obsy * r29641 /packages/net/transmission/files/transmission.config: [package] transmission: revert peer_socket_tos to default value Jan 03 00:04:49 loswillos: ping Jan 03 00:07:10 jow_laptop: I'm stumped as to why the vlan stuff seems to be non-deterministic... the "vconfig set_name_type" doesn't seem to work reliably. Jan 03 00:07:48 philipp64|laptop: I too. I never had issues with it Jan 03 00:08:01 what can I do to debug it? Jan 03 00:08:09 you could use the hammer and stuff it in front of every add call Jan 03 00:08:29 if you type "vconfig" all by itself, it dumps the usage message, but the usage message is wrong. Jan 03 00:08:35 e.g. in prepare_interface() of /lib/network/config.sh Jan 03 00:08:43 you can't use "vconfig set_name_type" with no arg. Jan 03 00:13:38 yep Jan 03 00:13:46 the source is a very thin ioctl wrapper Jan 03 00:14:02 it does not even contain any print statement besides the usage Jan 03 00:14:31 but thats not your problem Jan 03 00:20:56 ok, tweaking /etc/init.d/boot to do some debugging. Jan 03 00:47:16 jow_laptop: well, it turns out the vconfig set_name_type is working... sort of. Jan 03 00:47:19 http://fpaste.org/ASjw/ Jan 03 00:47:47 not sure why "ifconfig -a" shows it one way, and "ip -o link show" does it another. Jan 03 00:48:18 d'oh Jan 03 00:48:40 but why does it show it in a different way? Jan 03 00:48:45 eth0.1 looks right Jan 03 00:48:51 foo@bar indicates a vlan Jan 03 00:49:47 no idea. Jan 03 00:51:54 I think "ip" might just be braindead: Jan 03 00:51:56 ip -o link show dev eth0.1 Jan 03 00:51:57 6: eth0.1@eth0: mtu 1500 qdisc noqueue state UP \ link/ether 00:0d:b9:22:6e:64 brd ff:ff:ff:ff:ff:ff Jan 03 00:52:12 no Jan 03 00:52:25 it looks like generic syntax to indicate that eth0.1 is a child of eth0 Jan 03 00:53:44 same for macvlan: Jan 03 00:53:49 $ sudo ip link add link eth0 address 00:19:d1:29:d2:58 macvlan0 type macvlan Jan 03 00:53:53 $ sudo ip -o link show dev macvlan0 Jan 03 00:53:55 6: macvlan0@eth0: mtu 1500 qdisc noop state DOWN \ link/ether 00:19:d1:29:d2:58 brd ff:ff:ff:ff:ff:ff Jan 03 00:56:33 I mean braindead in that when parsing the output, you need to special-case vlans to strip the parent device name. that's a pain. Jan 03 00:56:58 are we ever going to deprecate ifconfig/route in favor of iproute2? Jan 03 00:57:36 unlikely Jan 03 00:57:42 ok. Jan 03 00:57:54 it will get deprecated by netifd so that there is no need for those tools anymore Jan 03 00:58:08 then the user is free to choose whatever is suitable Jan 03 00:58:10 well, except when you need to do stuff by hand. Jan 03 00:58:18 there won't be any hard deps Jan 03 00:58:20 but yeah. Jan 03 01:00:19 the main problem I see with iproute2 is its non-modularity Jan 03 01:00:32 the busybox one is ver limited and the full one very big Jan 03 01:00:53 and whenver something new appears you'll need a separate util anyway, until iproute2 picks it up Jan 03 01:01:05 see for example l2tpv3tun Jan 03 01:02:00 it would be awesom if the iproute2 subcommands would be loadable libraries Jan 03 01:02:09 then it could be extended on demand Jan 03 01:02:59 or maybe such a facility is already there, not sure Jan 03 01:03:08 tc seems to support loadable plugins Jan 03 01:16:19 ok, ip apparently too. At least it links libdl on my ubuntu Jan 03 01:33:16 jow_laptop: it already supports it, yeah... Jan 03 01:33:40 btw, who do I talk to about getting the ath5k LED stuff to stop panicking the kernel? Jan 03 01:35:16 hm Jan 03 01:35:26 linux-wireless I suppose Jan 03 01:37:19 yeah, posted on the 28th but didn't hear back. Jan 03 01:38:04 we apply a fairly significant number of patches to the compat-wireless releases. maybe one introduced damage? Jan 03 01:42:19 well there was some work on funneling led control through the wifi driver lately Jan 03 01:42:24 but I thought that was ath9k only Jan 03 01:51:20 and that's what worries me... some of the updates that needed to happen in both places might have only happened in the ath9k code, leaving it incorrectly initialized, etc. Jan 03 01:52:23 maybe it will get fixed with the next pull of compat-wireless... when is that, anyway? Jan 03 01:57:50 jow_laptop: how would I get svn diff to produce a patch file that also includes files that should be deleted Jan 03 01:58:05 I've updated the bind package and the two existing patch files should be removed Jan 03 02:00:05 svn del before Jan 03 02:02:20 jow_laptop: done, is it preferable to use --no-diff-deleted Jan 03 02:26:59 Olipro: no Jan 03 02:33:59 too bad "patch" doesn't detect the underlying SCM and do the "git add", "git rm", etc. as needed. :-( **** ENDING LOGGING AT Tue Jan 03 02:59:57 2012