**** BEGIN LOGGING AT Tue Apr 12 02:59:57 2011
Apr 12 04:41:51 <RealOpty> hey
Apr 12 04:43:56 <RealOpty> jow_laptop, xMff if u get some time, pure-ftpd has a new release :)  came out last month
Apr 12 05:36:14 <romand> Is anyone doing hpna development in openwrt?
Apr 12 06:19:34 * russell-- wonders why i am seeing erratic rssi from a madwifi 5GHz radio, changing diversity and txantenna has not effect, bouncing 6 dB up and down
Apr 12 07:47:08 <gzanan> libstdcpp fails to build with gcc-4.3.3.
Apr 12 07:47:14 <gzanan> How to fix it?
Apr 12 07:55:05 <Acinonyx> gmorning
Apr 12 07:59:30 <philipp64|laptop> evening.
Apr 12 08:00:00 <philipp64|laptop> gzanan: why are you using such an old compiler?
Apr 12 08:02:30 <gzanan> Because aria2 has problems when running a gcc-452 linaro built openwrt
Apr 12 08:02:56 <gzanan> Amule and debootstrap maybe so.
Apr 12 08:03:04 <[florian]> what about fixing them instead?
Apr 12 08:04:03 <gzanan> Patching them will be much more difficult.
Apr 12 08:06:07 <gzanan> Does anyone what to look into it.I can provide the Makefile.
Apr 12 08:07:32 <gzanan> I has tested it in AR71xx and X86.Both failed in BT download.When using a old kernel and gcc.It works fine
Apr 12 08:10:34 <gzanan> Right now I am having a "libstdc++ fails to compile" problem
Apr 12 08:12:36 <gzanan> http://pastebin.com/0SLpBbbx
Apr 12 09:30:12 <CIA-83> juhosg * r26600 /trunk/target/linux/generic/files/drivers/net/phy/ (rtl8366rb.c rtl8366s.c):
Apr 12 09:30:12 <CIA-83> generic: rtl8366{s,rb}: remove the PHY driver.
Apr 12 09:30:12 <CIA-83> Since the PHY driver is only used for the WAN port and there is virtually
Apr 12 09:30:12 <CIA-83> no difference between it and the generic PHY driver, we can sefely remove
Apr 12 09:30:12 <CIA-83> it.
Apr 12 09:30:13 <CIA-83> Signed-off-by: Jonas Gorski <jonas.gorski+openwrt@gmail.com>
Apr 12 09:30:15 <CIA-83> juhosg * r26601 /trunk/target/linux/ar71xx/ (10 files in 8 dirs): (log message trimmed)
Apr 12 09:30:15 <CIA-83> ar71xx: Add support for WZR-HP-G301NH
Apr 12 09:30:15 <CIA-83> Add support for the Buffalo WZR-HP-G301NH. The only difference between it
Apr 12 09:30:15 <CIA-83> and the WZR-HP-G00NH is that it has a RTL8366RB instead of a RTL8366S.
Apr 12 09:30:15 <CIA-83> Since we don't do runtime detection of the switch, we need a separate
Apr 12 09:30:16 <CIA-83> machine definition for it.
Apr 12 09:30:17 <CIA-83> While we are at it, also rename the profile to reflect that it now is for
Apr 12 09:30:21 <CIA-83> juhosg * r26602 /trunk/package/kernel/modules/other.mk: package/kernel: add module for the gpio_keys_polled driver
Apr 12 09:30:23 <CIA-83> juhosg * r26603 /trunk/target/linux/ar71xx/ (38 files in 3 dirs): ar71xx: use the gpio_keys_polled driver instead of gpio_buttons
Apr 12 09:30:26 <CIA-83> juhosg * r26604 /trunk/package/mac80211/ (2 files in 2 dirs): (log message trimmed)
Apr 12 09:30:26 <CIA-83> mac80211: ath9k: register id table for platform device
Apr 12 09:30:26 <CIA-83> Currently the device id in the platform driver is hardcoded to an
Apr 12 09:30:26 <CIA-83> id which is specific to AR9130/AR9132 SOCs as it supports only wmac
Apr 12 09:30:26 <CIA-83> (wireless mac) of these SOCs. But this needs to be dynamic when we
Apr 12 09:30:27 <CIA-83> want to support different wmac of SOCs. So add id_table to driver to
Apr 12 09:30:27 <CIA-83> make it extendable to more SOCs.
Apr 12 09:33:19 <KanjiMonster> [florian]: ping
Apr 12 09:33:26 <[florian]> KanjiMonster: pong
Apr 12 10:40:57 <cshore> ping jow_laptop
Apr 12 10:47:08 <cshore> xMff: have you seen https://dev.openwrt.org/ticket/9143 ?
Apr 12 10:48:21 <cshore> xMff: do you know if this used to work?
Apr 12 11:02:46 <jow_laptop> pong cshore
Apr 12 11:03:15 <cshore> jow_laptop: hey there: have you seen #9143?
Apr 12 11:03:41 <jow_laptop> yeah, got a similar ticket on luci
Apr 12 11:03:57 <cshore> jow_laptop: did it used to work?
Apr 12 11:03:57 <jow_laptop> however I never seen something like this
Apr 12 11:04:01 <jow_laptop> yes of course
Apr 12 11:06:44 <cshore> jow_laptop: do you know if the deadc0de handling changed?  it seems odd that erase is not resulting in formatting on the next boot.
Apr 12 11:07:08 <jow_laptop> cshore: I don't know but I don't think it changed either
Apr 12 11:08:20 <jow_laptop> cshore: I suspect its a platform specific issue
Apr 12 11:08:28 <cshore> jow_laptop: ok, so maybe an unclean build, or arc-specific
Apr 12 11:09:02 <cshore> since mount should block
Apr 12 11:10:10 <jow_laptop> cshore: exactly
Apr 12 11:10:37 <jow_laptop> cshore: and he runs into a kernel oops, that is hardly something preinit should handle
Apr 12 11:21:34 <cshore> ok, I've asked him to do a clean build. Seems to work fine here, so it's not a generic issue.
Apr 12 11:31:37 <cshore> jow_laptop: I noticed though that the mtd wasn't reformatted (that no jffs2 formatting messages).  Is that normal for after an erase or does it indicate that something is broken (e.g. the missing deadc0de marker)?
Apr 12 11:55:50 <thepeople> KanjiMonster: pong
Apr 12 11:56:14 <KanjiMonster> thepeople: the usual ;)
Apr 12 11:56:38 <thepeople> KanjiMonster: try it, a batch of maintainers was added yesterday
Apr 12 11:56:43 <KanjiMonster> ah cool
Apr 12 11:57:19 <cshore> thepeople: hi, would it be possible to a patchwork login so I can mark patches as applied when I commit them?
Apr 12 11:59:13 <thepeople> cshore: did you register for patchwork?
Apr 12 11:59:29 <cshore> thepeople: er, no, should that be enough?
Apr 12 11:59:44 <thepeople> register and I will add you to the project
Apr 12 12:00:31 <EqUaTe> thepeople: you after more buildhosts?
Apr 12 12:01:17 <thepeople> EqUaTe: yes
Apr 12 12:08:12 <thepeople> cshore: you should be good (assuming my German is ok)
Apr 12 12:08:31 <cshore> bah, greylisting...got to wait for the confirmation email
Apr 12 12:08:39 <cshore> thepeople: you added me already?
Apr 12 12:09:20 <trine_> why does all this take so long
Apr 12 12:09:44 <trine_> and why once a decision has been made cant it be instant
Apr 12 12:10:13 <thepeople> cshore: I seend your account
Apr 12 12:10:20 <trine_> there seems to be a lot of buggering about going on
Apr 12 12:10:21 <thepeople> seen*
Apr 12 12:10:37 <trine_> as we say in English
Apr 12 12:11:53 <builder_> build #4 of uml is complete: Failure [failed compile_4]  Build details are at http://tksite.gotdns.org:8010/builders/uml/builds/4
Apr 12 12:12:49 <cshore> trine_: I hope that's satire, because some of us have to work for a living and have significant others as well.
Apr 12 12:13:05 <trine_> its not satire at all
Apr 12 12:13:23 <trine_> you have missed the point
Apr 12 12:13:39 <KanjiMonster> thepeople: trac login works, but I can't get svn+ssh to work (it's always asking me for a password instead of the password for the keyfile)
Apr 12 12:13:50 <trine_> when a decision is made to allow someone access then why is it not instant thereafter
Apr 12 12:14:19 <cshore> trine_: because the admin has add them?
Apr 12 12:14:47 <cshore> trine_: it's not like security is a non-issue
Apr 12 12:14:48 <trine_> cshore and does that take an enormous amount of time and effort
Apr 12 12:15:10 <trine_> answer is no
Apr 12 12:16:31 <cshore> trine_: people always complain about admin speeds....it's not part of the job I'd like if I were an admin (dealing with naggers who don't understand what I do).
Apr 12 12:16:52 <trine_> messing about like this cause a good deal of frustration I would have thought
Apr 12 12:17:02 <loswillios> KanjiMonster: ssh-agent?
Apr 12 12:17:05 <cshore> trine_: mistakes happen
Apr 12 12:17:18 <thepeople> loswillios: I am helping him in pm :-)
Apr 12 12:17:28 <loswillios> ok
Apr 12 12:17:50 <KanjiMonster> got it to work :)
Apr 12 12:18:07 * thepeople looks for KanjiMonster commits :-)
Apr 12 12:19:19 <trine_> thepeople, are you still working with webif
Apr 12 12:19:31 <trine_> or is it fofware
Apr 12 12:19:40 <thepeople> trine_: as time permits (both of us)
Apr 12 12:20:03 <thepeople> trine_: I did fix up a few things in the past couple of weeks
Apr 12 12:20:18 <trine_> I like web-if especially the asterisk stuff
Apr 12 12:21:26 <thepeople> anyhow I got to run, time to go do paying work :-)
Apr 12 12:21:35 <trine_> fofware mentioned once he was working on another asterisk part for web-if
Apr 12 12:21:42 <KanjiMonster> thepeople: thanks for your help :)
Apr 12 12:21:50 <thepeople> KanjiMonster: np
Apr 12 12:23:19 <cshore> KanjiMonster: did you commit?  I didn't see any messages from the bot...
Apr 12 12:23:29 <KanjiMonster> cshore: not yet
Apr 12 12:23:38 <cshore> KanjiMonster: ah, that would explain it
Apr 12 12:24:01 <cshore> KanjiMonster: I thought that was what wasn't working
Apr 12 12:24:56 <KanjiMonster> cshore: no, I had problems setting up the ssh key auth - now I successfully checked out with it
Apr 12 12:26:22 <cshore> KanjiMonster: ah, ok.
Apr 12 12:43:45 <mazilo> There is some new commits (r26604) for Linux kernel on AR71XX.
Apr 12 12:44:00 <mazilo> I don't know if that will help/
Apr 12 12:44:23 <mazilo> Oops, sorry about that comment.
Apr 12 12:56:59 <builder_> build #4 of ar7 is complete: Failure [failed compile_6]  Build details are at http://tksite.gotdns.org:8010/builders/ar7/builds/4
Apr 12 13:10:08 * EqUaTe returns from lunch
Apr 12 13:15:57 <CIA-83> juhosg * r26605 /trunk/target/linux/ar71xx/ (config-2.6.37 generic/config-default image/Makefile): ar71xx: don't hardcode console parameters in kernel config
Apr 12 13:16:00 <CIA-83> juhosg * r26606 /trunk/target/linux/ar71xx/files/arch/mips/ (3 files in 2 dirs): ar71xx: fix build error w/o CONFIG_PCI
Apr 12 14:17:37 <CIA-83> hcg * r26607 /trunk/target/linux/omap35xx/patches-2.6.36/003-change_partition_table.patch: [omap35xx] Change partition table layout
Apr 12 14:25:27 <CIA-83> hcg * r26608 /trunk/package/uboot-omap35xx/files/include/configs/omap3_overo.h: [uboot-omap35xx] Modify environment variables for altered filesystem layout
Apr 12 14:51:37 <builder_> build #4 of orion is complete: Failure [failed compile_7]  Build details are at http://tksite.gotdns.org:8010/builders/orion/builds/4
Apr 12 15:59:46 <builder_> build #4 of lantiq is complete: Failure [failed compile_6]  Build details are at http://tksite.gotdns.org:8010/builders/lantiq/builds/4
Apr 12 16:20:45 <mazilo> Can anyone please help? I did an 'svn up' to r26608 and my WGT634U has been up with it. I put in an external USB partition on a Compact Flash card with this OpenWRT and the next reboot gives me this error message "Apr 12 12:13:32 WGT634U user.notice fstab: mount: mounting /dev/sda1 on /tmp/overlay-disabled failed: No such device"
Apr 12 16:22:51 <mazilo> And, when I manually tried 'mount /dev/sda1 /mnt', I got thie error message from mount "mount: mounting /dev/sda1 on /mnt failed: Invalid argument". What's going one?
Apr 12 16:29:24 <_trine> any idea why my new dockstar compile does not run :- http://dpaste.com/531280/
Apr 12 16:30:25 <mazilo> _trine: Looks like you did not include some needed FS?
Apr 12 16:30:44 <trine> yes thats what it looks like to me too
Apr 12 16:30:53 <trine> but I did include the FS
Apr 12 16:31:15 <trine> I have ext2 ext3 vfat and ntfs
Apr 12 16:31:24 <mazilo> What FS is used on th sda1 partition?
Apr 12 16:31:31 <trine> ext2
Apr 12 16:31:47 <trine> i think its a platform issue
Apr 12 16:31:55 <mazilo> And, you have the ext2 built-in or at least as module?
Apr 12 16:32:00 <trine> yes
Apr 12 16:32:18 <trine> I included it in kernel modules
Apr 12 16:32:29 <mazilo> If you compiled it as a module, make sure it is accessible on your USB partition.
Apr 12 16:33:06 <trine> how
Apr 12 16:34:30 <mazilo> check /lib/modules/<version>/
Apr 12 16:35:28 <trine> mazilo, what do you mean
Apr 12 16:36:03 <mazilo> Make sure the ext2 module is in /lib/modules/<kernel version>/ directory.
Apr 12 16:36:18 <trine> do you mean 2.6.37.6
Apr 12 16:36:28 <trine> thats a folder
Apr 12 16:36:49 <mazilo> If you compiled with Linux v.2.6.37.6, then that is the version.
Apr 12 16:37:06 <trine> well thats what it is
Apr 12 16:37:11 <trine> and it does not work
Apr 12 16:38:04 <trine> my working vrsion is 2.6.35.11
Apr 12 16:38:29 <mazilo> Can you try to reconfigure using 'make kernel_menuconfig' and include the ext2 and recompile?
Apr 12 16:38:46 <trine> I could do
Apr 12 16:41:38 <trine> where abouts in there is ext2
Apr 12 16:41:52 <mazilo> FileSystem sub-menu
Apr 12 16:42:46 <trine> ext2 isnt an option
Apr 12 16:42:56 <mazilo> It should be.
Apr 12 16:44:35 <trine> http://img812.imageshack.us/i/screenshot6n.png/
Apr 12 16:44:40 <mazilo> If not, just use 'make menuconfig' and under Kernel modules -> FileSystem -< ext2.
Apr 12 16:45:07 <trine> I already did that
Apr 12 16:46:11 <mazilo> If you did that (select with * and not M), then the compilation will build the kernel with an ext2 built-in and not as a module.
Apr 12 16:46:27 <trine> I did use *
Apr 12 16:46:56 <xMff> PrimasMike__: so, what did you find out?
Apr 12 16:47:07 <mazilo> Then, I am not sure why your DockStar fails to look for the USB partition.
Apr 12 16:47:21 <DelphiWorld> hi mazilo
Apr 12 16:47:25 <PrimasMike__> that my guy didn't try to reach you like I asked ... lol
Apr 12 16:47:35 <mazilo> What;s up?
Apr 12 16:47:43 <PrimasMike__> he took one of your suggestions and ran with it
Apr 12 16:47:45 <trine> make kernel-menuconfig says Use ext4 for ext2/ext3 file systems
Apr 12 16:47:51 <PrimasMike__> the TCPdump
Apr 12 16:47:54 <trine> and that is already selecte
Apr 12 16:47:55 <trine> d
Apr 12 16:48:22 <mazilo> Then, your built kernel should already include the ext2 FS.
Apr 12 16:48:38 <trine> yes agreed but it does not boot
Apr 12 16:49:07 <mazilo> Sorry that I ran out of solution. :(
Apr 12 16:49:15 <xMff> PrimasMike__: ok
Apr 12 16:49:31 <trine> mazilo, does it need this     < > Kernel automounter version 4 support (also supports v3)
Apr 12 16:49:45 <trine> cos that is not selected
Apr 12 16:49:46 <mazilo> I have that enabled on mine.
Apr 12 16:50:03 <trine> why is not not selected on mine
Apr 12 16:50:14 <xMff> PrimasMike__: ok
Apr 12 16:50:29 <xMff> oops ewin
Apr 12 16:50:50 <mazilo> IIRC, when you enable US2 Storage using 'make menuconfig', all those switches are included. I do these all using 'make kernel_menuconfig'.
Apr 12 16:51:18 <trine> well they have not been selected now
Apr 12 16:51:29 <trine> and they should have been
Apr 12 16:51:34 <mazilo> Perhaps, xMff can help you on this.
Apr 12 16:52:02 <xMff> kernel automounter is totally unrelated here
Apr 12 16:52:17 <PrimasMike__> xMff PrimasRich is logging in now
Apr 12 16:52:47 <trine> xMff, do you think its a kernel version issue
Apr 12 16:53:08 <xMff> trine: I don't know
Apr 12 16:53:44 <trine> well I could change the make file back to the older kernel version and recompile
Apr 12 16:53:53 <xMff> I suppose you could
Apr 12 16:54:18 <trine> I cant make pigs fly though
Apr 12 16:55:04 <xMff> that'd be surprising, indeed
Apr 12 16:57:09 <PrimasMike__> xMff, while we are waiting for Rich... is there a way to do a linux command to see what filters are running
Apr 12 16:57:50 <xMff> I am not sure what kind of filters you are referring to
Apr 12 16:59:13 <trine> I have changed it back to 2.6.35.11
Apr 12 16:59:28 <trine> I will clean and recompole
Apr 12 16:59:31 <trine> I will clean and recompile
Apr 12 17:01:37 <trine> xMff, will make clean be enough
Apr 12 17:01:48 <xMff> usually yes
Apr 12 17:01:55 <trine> cos it just wrrored
Apr 12 17:02:00 <trine> cos it just errored
Apr 12 17:02:20 <trine> doing V=99 now
Apr 12 17:03:08 <trine> its out of sinc ,,, just fixing that now
Apr 12 17:03:20 <PrimasMike__> xMff   libpcap filters
Apr 12 17:03:26 <PrimasMike__> Rich is now on
Apr 12 17:03:34 <PrimasMike__> PrimasRich is now on'
Apr 12 17:03:58 <xMff> PrimasMike__: no there is no such command, it depends on how they've been set up
Apr 12 17:04:17 <PrimasMike__> that explains why we couldn't find it
Apr 12 17:04:53 <PrimasMike__> this goes back to yesterday's conversation where we were trying to find out what was re-directing the packets
Apr 12 17:05:13 <xMff> I really suggest to read into the libpcap documentation http://www.tcpdump.org/pcap.html
Apr 12 17:05:17 <PrimasMike__> and our thought was that there was a filter installed
Apr 12 17:06:12 <PrimasRich> Hi xMff, Mike and I were looking at the SO_ATTACH_FILTER
Apr 12 17:06:33 <PrimasMike__> while we do that, can you explain to PrimasRich the Tap suggestion that was your recommendation for the easiest approach
Apr 12 17:06:35 <PrimasRich> Which is what we saw in the code for libpcap.
Apr 12 17:07:26 <PrimasRich> Would it be possible to redirect traffic via a Socket Filter?
Apr 12 17:07:35 <xMff> no it isn't
Apr 12 17:08:44 <trine> it wont let me compile now http://dpaste.com/531333/
Apr 12 17:09:03 <trine> it might need a distclean
Apr 12 17:09:24 <trine> mazilo, which kernel does yours use
Apr 12 17:09:53 <PrimasRich> So what if i modified the packet's header when a packet was received via a socket, could i redirect a packet then?
Apr 12 17:11:02 <xMff> I though you want to capture traffic?
Apr 12 17:11:25 <xMff> if you alter a packet you're not capturing traffic anymore, you're intercepting and manipulating it
Apr 12 17:12:29 <xMff> for simple capturing I suggest to write a C program which uses libpcap to listen on a given interface and then re-sends the captured datastream in pcap format via a unicast tcp/ip connection to a remote server for further prcessing
Apr 12 17:12:31 <trine> Kaloz, are you here?
Apr 12 17:13:28 <PrimasRich> is libpcap much different to what can be achived via programming sockets in the Kernel?
Apr 12 17:13:30 <xMff> yesterday I suggested to do a layer 2 tap openvpn tunnel and bridge the interface to it plus disable learning on the bridge but I am not so sure whether this would even work
Apr 12 17:14:02 <xMff> fram a programming standpoint; no it isn't
Apr 12 17:14:16 <xMff> its merely an abstraction that works on a variatey of systems, even windows
Apr 12 17:14:23 <xMff> in contrast to BSD and Linux BPF
Apr 12 17:14:36 <PrimasRich> the reason i ask is because, i already have programmed a Socket which selectively captured the traffic i want and i have been extending it to send those packets.
Apr 12 17:15:03 <xMff> that is not the filters task
Apr 12 17:15:16 <xMff> make you daemon resend the captured traffic wherever you want
Apr 12 17:15:46 <PrimasRich> So using libpcap is a better approach then?
Apr 12 17:16:29 <xMff> from a portability standpoint it is, yes
Apr 12 17:16:37 <PrimasRich> great
Apr 12 17:16:47 <xMff> it also way more high level than ioctl based bpf
Apr 12 17:18:51 <xMff> and as I already wrote yesterday there are python bindings for it so you can somewhat use it for rapid prototyping
Apr 12 17:18:51 <xMff> and implement it in C later on
Apr 12 17:18:51 <xMff> the process is simple you setup a pcap session with the filters you want (or none for all traffic), keep reading the datastream and copy that into a tcp/ip connection
Apr 12 17:19:01 <CIA-83> nbd * r26609 /trunk/package/mac80211/patches/ (3 files): mac80211: fix WPA auth on WDS station interfaces (#9227)
Apr 12 17:19:05 <xMff> obviously the bandwidth of your captured traffic may exceed the bandwidth of your vpn connection so you have to think about mechanisms to cope with that
Apr 12 17:19:36 <xMff> e.g. by dropping/truncating packages or only look fro specific streams
Apr 12 17:19:42 <PrimasMike__> xMff bandwidth is not an issue
Apr 12 17:20:05 <PrimasMike__> I just read the doc you suggested and it seems simple enough
Apr 12 17:20:09 <CIA-83> nbd * r26610 /branches/backfire/package/mac80211/patches/ (19 files): mac80211: merge latest changes from trunk, fixes #9227
Apr 12 17:20:27 <xMff> I suggested a crude hack yesterday
Apr 12 17:20:37 <xMff> some people use to run "tcpdump" remotely
Apr 12 17:20:39 <PrimasRich> from what i read, packets will only get dropped if you have too much overhead.
Apr 12 17:20:40 <PrimasMike__> in our implementation it suggested that we could filter on incoming and outgoing ports
Apr 12 17:20:56 <PrimasRich> but buffering is one machanism, right?
Apr 12 17:21:04 <xMff> PrimasRich: yep
Apr 12 17:21:22 <xMff> PrimasRich: either you get the stuff moved away fast enough or you have to buffer it
Apr 12 17:21:50 <PrimasMike__> lets not worry about this, we are working with very low traffic
Apr 12 17:22:27 <builder_> build #7 of at91 is complete: Failure [failed compile_4]  Build details are at http://tksite.gotdns.org:8010/builders/at91/builds/7
Apr 12 17:22:37 <PrimasMike__> bandwidth will be 1000x+ more than we need
Apr 12 17:23:16 <PrimasRich> xMff, that is an interesting idea about the layer 2 Tap and Open VPN tunnel.
Apr 12 17:23:41 <PrimasMike__> how easy can we do this
Apr 12 17:23:51 <xMff> I think it won't work
Apr 12 17:24:11 <PrimasRich> It looks like just careful configuration
Apr 12 17:24:19 <PrimasRich> but im not sure if it will work either.
Apr 12 17:25:31 <xMff> but you could try. setup an openvpn tap tunnel,  do  brctl addbr br-capture; ifconfig br-capture up; brctl addif br-capture eth0; brctl addif br-capture tap0; brctl setageing br-capture 0
Apr 12 17:26:35 <PrimasRich> I had previously used the VPN as a PPTP link and this did not work, but there was no Tap used.
Apr 12 17:27:05 <PrimasRich> the problems i faced were getting the packet past the WAN port.
Apr 12 17:27:36 <cshore> PrimasRich: the gotcha is you can't let OpenVPN set the ip on the device IIRC
Apr 12 17:27:57 <cshore> PrimasRich: otherwise it destroys the ip that is already there
Apr 12 17:28:23 <cshore> PrimasRich: and I seem to recall that being an issue in terms of maybe not being possible
Apr 12 17:29:48 <PrimasRich> thanks for the heads-up, but it may be worth trying the OpenVPN.
Apr 12 17:30:20 <KanjiMonster> meh, I broke 2.6.39 for openwrt
Apr 12 17:31:04 <PrimasMike__> xMff can you tell me which client works good with Windows 7.  We are using the webchat now and want to install the client
Apr 12 17:31:19 <CIA-83> nbd * r26611 /trunk/package/hostapd/patches/700-random_pool_add_kernel.patch: hostapd: properly mark random data as ready if initialization succeeds without reassociation (#9222)
Apr 12 17:31:32 <xMff> I used pidgin on windows
Apr 12 17:31:36 <PrimasRich> ha! Im using XP :)
Apr 12 17:31:47 <PrimasRich> thx
Apr 12 17:32:02 <PrimasMike__> pidgin works on windows 7
Apr 12 17:32:15 <xMff> however pidgin is a multi protocol client, there are a cuple of good irc only clients
Apr 12 17:32:16 <KanjiMonster> nbd: 2.6.39 got xz compressor options support - which obviously brakes with my extensions (I should clean them up and submit them upstream... )
Apr 12 17:32:20 <xMff> but I never used one of them
Apr 12 17:34:08 <CIA-83> nbd * r26612 /branches/backfire/package/hostapd/patches/700-random_pool_add_kernel.patch: hostapd: properly mark random data as ready if initialization succeeds without reassociation (#9222), backport of r26611
Apr 12 17:37:17 <PrimasRich> We just spoke about libpcap and capturing, but will it make any difference if the packet i captured was while in promiscuous mode and i send it out the WAN?
Apr 12 17:38:03 <PrimasRich> i ask because this is where the packets stops flowing, I dont see it being droped, but it does not get through either.
Apr 12 17:38:26 <xMff> you can't just capture a random packet and put it on wan
Apr 12 17:38:31 <xMff> how is the routing supposed to work out
Apr 12 17:38:49 <PrimasRich> This may actually be where all my problems lay, but not know enough about what happens at the WAN port.
Apr 12 17:39:38 <PrimasRich> Is there a way of pushing a promiscuously captured packet out of the WAN?
Apr 12 17:39:42 <xMff> no
Apr 12 17:39:58 <PrimasRich> Perhaps, if it were encapsulated?
Apr 12 17:40:06 <xMff> then yes
Apr 12 17:40:10 <cshore> PrimasRich: basically what you want to do is grab packets with pcap and then send the encapsulated stream
Apr 12 17:40:26 <xMff> and thats basically what I repeating over and over again
Apr 12 17:40:52 <PrimasRich> k
Apr 12 17:41:47 <xMff> pcap actually providing an encapsulation format which can handle all kinds of traffic
Apr 12 17:41:52 <xMff> including raw ethernet frames
Apr 12 17:42:09 <xMff> you can put this datastream into a simple tcpip connection, maybe secured with ssl or tls
Apr 12 17:42:17 <xMff> then you do not even need a vpn
Apr 12 17:42:26 <xMff> just a simple tcp/ip ssl server
Apr 12 17:42:31 <CIA-83> nbd * r26613 /branches/backfire/package/mac80211/patches/ (3 files): mac80211: merge some more fixes from trunk (fixes #9224)
Apr 12 17:42:45 <xMff> and one or more tcp/ip ssl clients on your remote mechines where you want to capture
Apr 12 17:43:03 <xMff> on the server you can unpack and analyze the pcap encapsulated traffic
Apr 12 17:43:13 <PrimasMike__> xMff please note that we don't want to route these packets
Apr 12 17:43:40 <xMff> PrimasMike__: exactly this is why you can't just grab to packet and put it on wan
Apr 12 17:43:53 <PrimasMike__> we only want to put them into the client side of the VPN pipe and have them presented out the other side where there is another sniffer
Apr 12 17:43:57 <xMff> apart from that not all kinds of traffic are actually routable
Apr 12 17:44:00 <xMff> think of arp
Apr 12 17:44:09 <xMff> or link local multicast
Apr 12 17:45:20 <xMff> PrimasMike__: yes, so put a small agent on the client side which 1) opens a pcap session without filters 2) opens a connection to your sniffer server 3) reads all data from the pcap session 4) writes all readed data into the connection to the sniffer server
Apr 12 17:45:37 <KanjiMonster> nbd: fixing it looks like a three liner: the compressor options struct just needs to be adjusted
Apr 12 17:45:41 <PrimasMike__> understood
Apr 12 17:46:13 <xMff> then have the sniffer server 1) accept the agent connection  2) read everything from the agent connection  3) process it as needed
Apr 12 17:47:00 <PrimasMike__> Guys, please bear with us a bit on this issue.  Before we cound this forum, we had a number of people give us advice on how to tackle this.
Apr 12 17:47:38 <PrimasMike__> PrimasRich has  been dilligently following previous suggestions and has many experiences that have led to dead ends
Apr 12 17:47:58 <nbd> KanjiMonster: ok, let me know when you have any patches that you want me to look over
Apr 12 17:48:09 <xMff> PrimasMike__: I understand that much, thats the risk of asking random people on the interwebz ;)
Apr 12 17:48:14 <PrimasMike__> So many of his questions are closing loose ends
Apr 12 17:48:38 <PrimasRich> Thanks ;) BTW thansk for the
Apr 12 17:48:45 <PrimasRich> info
Apr 12 17:48:51 <xMff> so in order to capture traffic remotely and get it to you *unmodified* you have to encapsulate it
Apr 12 17:48:56 <PrimasMike__> The good news is that PrimasRich is now well versed on many of the other directions and has a good indepth understanding
Apr 12 17:48:57 <xMff> libpcap will do that for you
Apr 12 17:49:13 <PrimasMike__> Understood xMff
Apr 12 17:49:29 <xMff> another advantage of the pcap format is that many tools understand it
Apr 12 17:49:32 <PrimasRich> yes understood
Apr 12 17:49:45 <xMff> you could for example use the grpahical wireshark to browse through a pcap data stream
Apr 12 17:49:52 <PrimasRich> yes like wireshark and ethertest .....
Apr 12 17:50:10 <KanjiMonster> nbd: just booted to login, but got a overlayfs during boot (overlayfs: ERROR - failed to whiteout 'brcm63xx_fixcrc.sh')
Apr 12 17:50:59 <PrimasMike__> xMff, so in our environment, so we need to disable the openwrt software so it doesn't intercept the traffic?
Apr 12 17:51:13 <xMff> PrimasMike__: not at all
Apr 12 17:51:27 <xMff> PrimasMike__: libpcap works below the firewall
Apr 12 17:51:55 <PrimasRich> I think we run the Libpcap as a userland app right? And that hooks into the lower levels.
Apr 12 17:52:02 <xMff> yes
Apr 12 17:52:13 <xMff> but it will require root to setup the capture session
Apr 12 17:52:18 <PrimasMike__> so these will be duplicate packets on a different socket?  or are we intercepting the packets before they get to openwrt
Apr 12 17:52:20 <xMff> for obvious reasons
Apr 12 17:52:30 <PrimasRich> and libpcap is an API and not a runnable app.
Apr 12 17:52:36 <xMff> correct
Apr 12 17:52:48 <xMff> tcpdump is a runnable app which uses libpcap
Apr 12 17:52:54 <xMff> wireshark is another
Apr 12 17:53:48 <PrimasMike__> I need to ask a question on the other router at our home office...
Apr 12 17:53:49 <xMff> PrimasMike__: you will intercept pakets before they get to the kernel, then you will copy them as char arrays into an open tcp socket
Apr 12 17:54:13 <PrimasMike__> understood, so openwrt will not see them
Apr 12 17:54:24 <xMff> it will see them too
Apr 12 17:54:37 <PrimasMike__> oh, because we are copying
Apr 12 17:54:41 <xMff> yes
Apr 12 17:55:01 <xMff> you can't do a true accurate packet capture if the traffic you observe cannot reach its destination
Apr 12 17:55:18 <xMff> you'd just capture connection attempts and errors...
Apr 12 17:55:26 <russell--> passive sniffing++
Apr 12 17:56:01 <KanjiMonster> nbd: okay, seems to be non-fatal, the file is actually removed/hidden
Apr 12 17:56:18 <xMff> so in essence all traffic is working exactly like it does allways but you can copy it as it passes through the router
Apr 12 17:56:32 <xMff> through the libpcap api
Apr 12 17:56:44 <PrimasMike__> on the host router...
Apr 12 17:56:59 <xMff> well on the router that you capture on
Apr 12 17:57:18 <PrimasMike__> do we have to run special software as well, or can we use the standard openwrt load
Apr 12 17:58:04 <PrimasMike__> there are 2 routers.  one at the client (we have been talking about) and another at our host site (that has the real sniffer with our custom decoders)
Apr 12 17:58:57 <xMff> in theory you could use tcpdump and relay the pcap data stream via ssh
Apr 12 17:58:58 <PrimasMike__> the host router only needs to present these packets to a ethernet port that is being "sniffed"
Apr 12 17:59:48 <PrimasMike__> please explain, what you mean by relay.
Apr 12 17:59:52 <xMff> http://linuxexplore.wordpress.com/2010/05/30/remote-packet-capture-using-wireshark-tcpdump/
Apr 12 18:00:24 <PrimasMike__> lol...
Apr 12 18:03:30 <PrimasMike__> will this work with routers?
Apr 12 18:04:32 <russell--> i've just sent it over ssh tunnels before
Apr 12 18:04:56 <xMff> PrimasMike__: with openwrt yes if you allow ssh access from wan
Apr 12 18:05:59 <PrimasMike__> what is the drawback to this approach?  it seems too easy...
Apr 12 18:06:06 <russell--> tcpdump -s0 -w- -i $iface | ssh me@myhost 'cat > /tmp/capture.pcap'
Apr 12 18:06:47 <russell--> PrimasMike__: you could stand in a bucket of cement at the bottom of a lake if you are looking for a challenge!
Apr 12 18:07:18 <PrimasRich> wow, that really does sound easy!
Apr 12 18:07:31 <PrimasRich> (referring to the command)
Apr 12 18:07:43 <builder_> build #7 of ubicom32 is complete: Failure [failed compile_3]  Build details are at http://tksite.gotdns.org:8010/builders/ubicom32/builds/7
Apr 12 18:07:45 <PrimasMike__> russel, I already feel like i have been in that bucket ... lol
Apr 12 18:07:48 <xMff> the one I linked is "pulling", russell-- is "pushing"
Apr 12 18:08:09 <russell--> the only downside to mine is that it isn't streaming into wireshark
Apr 12 18:08:17 <russell--> or whatever
Apr 12 18:08:35 <PrimasMike__> we need "real time"
Apr 12 18:08:37 <russell--> on myhost, you would have to periodically look at the capture.pcap file
Apr 12 18:08:57 <cshore> russell--: and you have to have an ssh key on the router that let the router have access to the ssh on the server.
Apr 12 18:09:00 <xMff> for real time take the first approach
Apr 12 18:09:21 <xMff> and read into ssh public key authentication
Apr 12 18:09:55 * russell-- missed the requirements section of this escapade
Apr 12 18:10:36 <KanjiMonster> nbd: is there an easy way to update the generic kernel config?
Apr 12 18:10:43 <PrimasMike__> russel, thanks for the alternate approach
Apr 12 18:11:09 <PrimasMike__> this will come in handy for development reasons where we need to store in a file
Apr 12 18:11:20 <nbd> KanjiMonster: copy the old one, update a target, move all new target specific symbols that should be generic into the generic config
Apr 12 18:11:32 <PrimasRich> right, yes that is true.
Apr 12 18:12:01 <KanjiMonster> nbd: okay (I had hoped for some scripts or so ;)
Apr 12 18:12:15 <nbd> nah, it's not easily possible to automate this imho
Apr 12 18:12:22 <nbd> unless you can think of a good way how this could be automated
Apr 12 18:13:00 <PrimasMike__> xMff, so the remote wireshark approach is "real time"?
Apr 12 18:13:11 <xMff> PrimasMike__: yes
Apr 12 18:13:25 <PrimasMike__> this is the "first" approach you are referring to?
Apr 12 18:13:35 <xMff> PrimasMike__: only capped by the bandwidth of the ssh connection and/or the cpu speed for encryption. Yes it is.
Apr 12 18:13:40 <cshore> nbd: what would be a good way of having different types of generic (as opposed to platform) profiels for OpenWRT.  E.g. so you could router, web server, nas, other network appliance, for example?
Apr 12 18:14:00 <xMff> cshore: imagebuilder + files + package lists
Apr 12 18:14:32 <xMff> cshore: we use openwrt as HA appliance and the images are all prepared with IB
Apr 12 18:14:44 <cshore> xMff: cool
Apr 12 18:14:45 <xMff> I don't think its openwrts task to do such profiles
Apr 12 18:15:11 <KanjiMonster> nbd: I can only think of bad ways ;)
Apr 12 18:15:16 <PrimasMike__> xMff, so what about the host router.  anthing special we need there for the pcap solution
Apr 12 18:15:18 <cshore> xMff: well, I'm think if a different busybox profile is needed or things like that
Apr 12 18:15:18 <PrimasRich> i think the Client Router to Host Router would work just fine with the Wireshark method, until we have many Client Routers connecting.
Apr 12 18:15:59 <nbd> cshore: i don't think profiles are a good way to implement that
Apr 12 18:16:12 <nbd> cshore: this could be handled with metapackages instead
Apr 12 18:16:14 <xMff> PrimasRich: yeah, that is where your custom written tcp/ip server and custom written tcp/ip software would come into play. Instead of the naive ssh + wireshark approach
Apr 12 18:16:54 <PrimasMike__> understood
Apr 12 18:17:21 <PrimasRich> k
Apr 12 18:17:27 <cshore> nbd: ah, ok....but that would be non-official metapackages right (since changes to busybox in a package are  problematic for compatibility)
Apr 12 18:17:50 <xMff> cshore: why not just coreutils?
Apr 12 18:18:20 <xMff> imo it seldom that something in BB is missing that is more than a simple cli user convenience tool
Apr 12 18:18:37 <xMff> like watch or ps w or something
Apr 12 18:18:49 <cshore> xMff: hmmm....right since most profiles other than router would only be for bigger devices anyway
Apr 12 18:18:58 <cshore> xMff: and busybox is smaller, usually
Apr 12 18:19:13 <nbd> cshore: not sure about changes to busybox, which ones do you think would be necessary?
Apr 12 18:19:22 <russell--> btw, did anyone see my "fluctuating signal strength" problem last night? i'm seeing (at the other end) rssi go: 30, 30, 30, 24, 30, 30, 30, 24, .... with madwifi.  any ideas?  txantenna=1, rxantenna=1, diversity=0.
Apr 12 18:19:45 <nbd> russell--: no idea. did you try ath5k to see if it has the same problem?
Apr 12 18:19:54 <russell--> not yet
Apr 12 18:20:14 <russell--> but, this is part of a meshy thing, i might be constrained to needing adhoc+ap
Apr 12 18:20:34 <nbd> and i might add that to ath5k and ath9k soon
Apr 12 18:20:42 <cshore> nbd: well I'm think shadow password and suid/guid stuff.....but thinking about it, that's more an issue of not having the build infrastructure to handle that yet, rather than particular to other profiles
Apr 12 18:21:03 <russell--> (although in this case, maybe i can avoid ... it's a two radio soekris 4826 rig)
Apr 12 18:21:09 <PrimasMike__> xMff, so I am understanding this correctly.  The remote wireshark suggestion is a simple 15 minute test that should work until we develop the pcap approach?
Apr 12 18:21:23 <xMff> PrimasMike__: yes
Apr 12 18:21:28 <nbd> cshore: i'm thinking that maybe we should just enable those by default at some point
Apr 12 18:21:34 <russell--> but adhoc+ap is very desirable ... i want to be able to run away from madwifi with everyone else
Apr 12 18:22:12 <cshore> nbd: yeah....the problem at the moment (which I have on my todo list) is the proper permissions and uid/gid settings in the squashfs/jffs2 etc
Apr 12 18:23:39 <cshore> well actually uid/gid is a separate problem though similar
Apr 12 18:24:26 <cshore> ermo: has been working on this....right ermo?
Apr 12 18:25:10 <ermo> cshore: hm?
Apr 12 18:25:30 <cshore> ermo: you've been working on the proper permissions stuff for squashfs and such
Apr 12 18:25:33 <ermo> Oh, yes.
Apr 12 18:25:59 <ermo> jow didn't like my approach too much -- he felt that it was arbitrary to control setup from include/image.mk
Apr 12 18:26:14 <ermo> I believe that it's a relic from before umasks were properly set
Apr 12 18:26:31 <ermo> also, mkfs.jffs strips sgid/suid bits afaict
Apr 12 18:26:45 <ermo> while squashfs and tar.gz don't w/my proposed tweaks
Apr 12 18:26:54 * ermo waves at xMff 
Apr 12 18:27:10 <ermo> s/setup/permissions/
Apr 12 18:27:43 <ermo> for those who are interested, I've attempted to document stuff in #7667
Apr 12 18:28:15 <ermo> jow mentioned something about talking to a couple of you about it, but I'm guessin that you have more important stuff on your plates
Apr 12 18:28:22 <ermo> *guessing
Apr 12 18:30:32 <CIA-83> nbd * r26614 /trunk/package/ppp/patches/405-no_multilink_option.patch: pppd: support the nomp option if multilink support is disabled
Apr 12 18:30:50 <cshore> I think what's really needed is to drop the normalization and do an audit to make sure things don't break.
Apr 12 18:31:49 <PrimasMike__> xMff, so I am thinking through what you suggested and have a question
Apr 12 18:32:07 <KanjiMonster> yay, config options without any help text, defaulting to y, nothing depending on them (or selecting them), and seemingly expected from some other parts to be enabled
Apr 12 18:32:12 <ermo> Hauke: will you kick me down, stab me through the lungs, break my legs and set me on fire if I happen to mention the disappearing memory isseu on my wl500gP again?
Apr 12 18:34:33 <PrimasMike__> it sounds like we run a VPN client at the remote router (so we have a remote IP address).  We do the SSH "VPN IP address" tcpdump ... command to open the channel
Apr 12 18:34:58 <russell--> ermo, are you suggesting there is something wrong with kicking,stabbing,leg-breaking,immolation???
Apr 12 18:35:05 <PrimasMike__> the we pipe the traffic into the host sniffer
Apr 12 18:35:19 <trine> Kaloz, ping
Apr 12 18:35:24 <ermo> russell--: Not as long as it is done lovingly <3
Apr 12 18:35:38 <russell--> lol
Apr 12 18:36:03 <russell--> bug reporting is the sincerest form of flattery
Apr 12 18:36:47 <russell--> of course, it is possible to be flattered too much
Apr 12 18:37:04 <PrimasMike__> russel, you want that bucket back?
Apr 12 18:37:08 <ermo> russell--: https://dev.openwrt.org/ticket/9097 <- 'break a leg, love <3' ;)
Apr 12 18:37:19 <T_X> hey ho, is this build-failure a known issue? I can't build the toolchain with x86 anymore in trunk http://pastebin.com/HyUR310N
Apr 12 18:38:51 <mazilo> _trine: I just came back and here it the output from 'uname -a "on my DockStar"
Apr 12 18:38:52 <mazilo> root@DockStar:/# uname -a
Apr 12 18:38:52 <mazilo> Linux DockStar 2.6.37.4 #1 Sat Mar 26 14:13:20 EDT 2011 armv5tel GNU/Linux
Apr 12 18:38:53 <mazilo> root@DockStar:/#
Apr 12 18:39:53 <cshore> ermo: hauke replied with his test and said he couldn't reproduce.  perhaps you are doing something different than he, that will create a reproducible error?  (assuming clean build et al.)
Apr 12 18:39:57 <russell--> ermo, weird
Apr 12 18:39:57 <ermo> mazilo: I think you should rename that thing 'RockStar'.
Apr 12 18:40:19 <trine> mine which does not work is v.2.6.37.6
Apr 12 18:40:22 <mazilo> ermo: LOL.
Apr 12 18:40:32 <ermo> cshore: I hadn't noticed.
Apr 12 18:40:33 <trine> ermo, very original !
Apr 12 18:40:36 <ermo> but 2.6.27?
Apr 12 18:40:40 <ermo> not 2.6.37?
Apr 12 18:40:47 <ermo> I'm using the backfire branch, so that might be it
Apr 12 18:41:00 <russell--> ermo: yeah, i was going to suggest trying trunk
Apr 12 18:41:05 <xMff> PrimasMike__: sounds right
Apr 12 18:41:58 <PrimasMike__> xMff, is there anything special at the host router?
Apr 12 18:42:11 <xMff> PrimasMike__: no
Apr 12 18:42:45 <ermo> russell--: but what if the issue persists in 10.03.1?
Apr 12 18:42:47 <PrimasMike__> so the only function of the host router in our example, is to host the VPN client?>
Apr 12 18:45:13 <ermo> Hauke: in any case, thanks for taking a look!
Apr 12 18:46:52 <Hauke> ermo: could you please try trunk
Apr 12 18:47:09 <ermo> yessir
Apr 12 18:51:54 <philipp64|laptop> xMff: any thoughts on the firewall patch?
Apr 12 19:03:46 <PrimasRich> Thank you all very much, its been extremely helpful being here!!!
Apr 12 19:05:17 <PrimasMike__> xMff, thank you for your help.  We will go give this all a try and let you know our results
Apr 12 19:05:26 <PrimasMike__> russel, thank you as well
Apr 12 19:06:51 <PrimasMike__> russell, are you still here
Apr 12 19:11:10 <russell--> yes
Apr 12 19:11:22 <russell--> PrimasMike__: i am indeed still here
Apr 12 19:11:32 <PrimasMike__> Thank you for your help
Apr 12 19:11:37 <russell--> noprob
Apr 12 19:12:18 <PrimasMike__> I have a question on using a chat client versus this web client
Apr 12 19:12:41 <russell--> for irc?
Apr 12 19:12:41 <PrimasMike__> I downloaded one and it is looking for this server
Apr 12 19:12:47 <xMff> philipp64|laptop: not sure, patch itself is okay but I do not like pulling in this new mod for such a border case
Apr 12 19:12:48 <PrimasMike__> yes
Apr 12 19:13:06 <russell--> what OS are you on?
Apr 12 19:13:12 <PrimasMike__> windows 7
Apr 12 19:13:31 <ermo> PrimasMike__: use mirc -- there's a 30 day trial.
Apr 12 19:13:33 * russell-- doesn't know much about those fringe operating systems
Apr 12 19:13:41 <PrimasMike__> lol
Apr 12 19:13:56 <PrimasMike__> ermo, that is what I downloaded
Apr 12 19:14:04 <PrimasMike__> freenode suggested that one
Apr 12 19:14:09 <russell--> or an ubuntu CD
Apr 12 19:14:16 <ermo> and what's the issue?
Apr 12 19:14:24 <ermo> (a bit OT, but what the heck)
Apr 12 19:14:25 <PrimasMike__> what is the address of the server to use
Apr 12 19:14:37 <xMff> irc.freenode.net
Apr 12 19:14:40 <PrimasMike__> gateway/web/freenode/ip.24.136.67.243 is what i have
Apr 12 19:14:48 <PrimasMike__> that was too easy
Apr 12 19:14:51 <ermo> PrimasMike__: you are an US resident?
Apr 12 19:14:56 <PrimasMike__> y
Apr 12 19:14:57 <ermo> *a
Apr 12 19:15:05 <PrimasMike__> California
Apr 12 19:15:48 <ermo> PrimasMike__: check this for the server closest to you: http://freenode.net/irc_servers.shtml
Apr 12 19:16:28 <ermo> PrimasMike__: on win 7, you can use 'pathping <servername>' to see which is the closest in terms of the network distance
Apr 12 19:16:44 <ermo> and then use the 3 CA servers in descending order of 'closeness'
Apr 12 19:16:48 <KanjiMonster> nbd: any idea how I can reduce the size of the patch? --find-copies-harder reduced it from 1.8MB to 1.4MB, but thats still quite big
Apr 12 19:16:52 <KanjiMonster> Olipro: ping
Apr 12 19:16:55 <PrimasMike__> ok
Apr 12 19:17:14 <nbd> KanjiMonster: what kind of patch?
Apr 12 19:17:30 <KanjiMonster> nbd: support for 2.6.39 (for generic)
Apr 12 19:17:39 <ermo> PrimasMike__: sorry, kubrick is down.
Apr 12 19:17:48 <ermo> so 'only' 2 servers in CA
Apr 12 19:18:40 <nbd> KanjiMonster: i don't mind the size
Apr 12 19:18:57 <russell--> PrimasMike__: under the keep-it-simple-stupid principle, i'd recommend just irc.freenode.net
Apr 12 19:18:59 <nbd> you can send it to me directly if you want to
Apr 12 19:19:57 <PrimasMike> russel are you there?
Apr 12 19:21:08 <PrimasMike> I am now attached under the irc.freenode.net server
Apr 12 19:21:20 <nbd> philipp64|laptop: any pending patches of your that still need committing?
Apr 12 19:21:22 <ermo> PrimasMike: does your client 'highlight' you now?
Apr 12 19:21:31 <PrimasMike> thanks
Apr 12 19:21:37 <PrimasMike> no
Apr 12 19:21:58 <PrimasMike> everything is black
Apr 12 19:22:07 <xMff> everything?
Apr 12 19:22:16 <PrimasMike> probably some option I haven't set yet
Apr 12 19:28:13 <PrimasMike> wow, it's a process to add nicks to an address book, then select the color and enable it
Apr 12 19:32:13 <builder_> build #5 of cobalt is complete: Success [build successful]  Build details are at http://tksite.gotdns.org:8010/builders/cobalt/builds/5
Apr 12 19:39:06 <philipp64|laptop> nbd: sorry, was eating lunch.
Apr 12 19:39:58 <philipp64|laptop> Yes, I think so. Let's see... http://patchwork.midlink.org/patch/882/ if JOW signs off on it, and http://patchwork.midlink.org/patch/871/
Apr 12 19:40:29 <CIA-83> nbd * r26615 /trunk/target/linux/generic/ (104 files in 2 dirs):
Apr 12 19:40:29 <CIA-83> generic: Add support for 2.6.39
Apr 12 19:40:29 <CIA-83> Add support for 2.6.39 based on rc3. Runtime tested on bcm63xx.
Apr 12 19:41:16 <xMff> I appreciate the work on newer kernels but wasn't .38 the version to focus on for the upcoming release?
Apr 12 19:41:38 <nbd> oh, forgot to attribute the patch
Apr 12 19:41:45 <nbd> it was KanjiMonster's
Apr 12 19:42:19 <xMff> I see
Apr 12 19:42:42 <KanjiMonster> nbd: my own fault, I forgot the sob ;)
Apr 12 19:43:33 <philipp64|laptop> how do we handle a patch that's not in 2.6.38.2 but appears in 2.6.38.3? does our patching process ignore patches already applied?
Apr 12 19:44:35 <philipp64|laptop> who's a sob?
Apr 12 19:44:41 <xMff> signed-off-by
Apr 12 19:45:04 <nbd> btw. how do you change the status of a patch in patchwork?
Apr 12 19:45:41 <xMff> change state: ...  -> update   ?
Apr 12 19:45:46 <philipp64|laptop> with the 'status' drop down...
Apr 12 19:46:12 <xMff> heh, maybe you're not admin yet
Apr 12 19:46:19 <xMff> or project member
Apr 12 19:46:39 <nbd> yeah, probably. i have access to the admin interface, so i can probably fix that myself
Apr 12 19:48:27 <philipp64|laptop> I'm guessing that patch will fail if the patch is in patches-2.6.38/ and the tarball?
Apr 12 19:48:54 <xMff> philipp64|laptop: yeah well it wouldn't be the first patch that fails between micro versions
Apr 12 19:49:10 <xMff> thats also a reason why all targets should be bumped at once
Apr 12 19:49:29 <xMff> at least for micro versions
Apr 12 19:49:54 <philipp64|laptop> looking at the --forward option for patch, it seems broken...
Apr 12 19:50:16 <nbd> hm, according to the admin page i should have the necessary rights
Apr 12 19:50:44 <nbd> and i'm logged in, yet can't change patch state stuff
Apr 12 19:50:54 <xMff> on which number?
Apr 12 19:51:24 <nbd> any
Apr 12 19:51:29 <nbd> 871 in this case
Apr 12 19:51:30 <xMff> odd
Apr 12 19:52:40 <Hauke> nbd: I have the same problem
Apr 12 19:52:41 <nbd> philipp64|laptop: committed the solos patch, i'll let xMff take the other one
Apr 12 19:52:48 <CIA-83> nbd * r26616 /trunk/target/linux/generic/patches-2.6.37/ (282-solos-debug_skbuff.patch 283-solos-vccs_release.patch):
Apr 12 19:52:48 <CIA-83> solos: various upstreamed solos patches
Apr 12 19:52:48 <CIA-83> These patches were submitted to netdev and will likely be out in 2.6.38.3.
Apr 12 19:52:48 <CIA-83> In the meantime, they're needed in 2.6.37.6.
Apr 12 19:52:48 <CIA-83> Patch by Philip Prindeville
Apr 12 19:53:35 <xMff> did anybody check the size impact of the conntrack module?
Apr 12 19:53:54 <xMff> not that it is like trace which enables stuff all over the place
Apr 12 19:54:08 <nbd> which module?
Apr 12 19:54:22 <xMff> xt_conntrack
Apr 12 19:54:38 <xMff> for iptables
Apr 12 19:55:16 <nbd> no impact aside from enabling the module
Apr 12 19:55:18 <nbd> just did a quick grep
Apr 12 19:55:52 <xMff> ok
Apr 12 19:55:53 <philipp64|laptop> nbd: thanks!
Apr 12 19:56:02 <xMff> than I'm fine with moving that to core
Apr 12 19:56:11 <xMff> might allow for some other neat firewall hacks in the future
Apr 12 19:56:22 <xMff> *then
Apr 12 19:57:11 <philipp64|laptop> xMff: well, it's less confusing, for a start...  having ipt-conntrack not contain {nf,xt}_conntrack.ko had me convinced I had broken something... :-)
Apr 12 20:01:27 <philipp64|laptop> nbd: is it worth copying the patches into other releases as well?
Apr 12 20:01:53 <nbd> if they're not needed right now then let's just wait for the -stable update
Apr 12 20:05:08 <CIA-83> jow * r26617 /trunk/ (2 files in 2 dirs): (log message trimmed)
Apr 12 20:05:08 <CIA-83> firewall: allow local redirection of ports
Apr 12 20:05:08 <CIA-83> Allow a redirect like:
Apr 12 20:05:08 <CIA-83> config redirect
Apr 12 20:05:08 <CIA-83> option src 'wan'
Apr 12 20:05:09 <CIA-83> option dest 'lan'
Apr 12 20:05:09 <CIA-83> option src_dport '22001'
Apr 12 20:07:32 <xMff> nbd: can you please logout and login into patchwork again?
Apr 12 20:07:40 <xMff> I believe the permissions should work now
Apr 12 20:07:44 <philipp64|laptop> xMff: thanks!
Apr 12 20:07:54 <xMff> at least I see your name in the delegate box
Apr 12 20:08:02 <nbd> looks better now
Apr 12 20:08:41 <xMff> openwrt was not highlighted in the project menubox of the profile page
Apr 12 20:08:50 <xMff> apparently it is not enough to set the primary project
Apr 12 20:09:53 <nbd> ah, ok
Apr 12 20:10:03 <nbd> so what's the 'archived' option for?
Apr 12 20:10:13 <nbd> and a merged patch should just be set to 'accepted', right?
Apr 12 20:13:34 <CIA-83> jow * r26618 /packages/utils/hd-idle/Makefile:
Apr 12 20:13:34 <CIA-83> Version bump hd-idle to 1.03. 1.02 and 1.03 were bugfix releases.
Apr 12 20:13:34 <CIA-83> Signed-off-by: Ian Leonard <antonlacon@gmail.com>
Apr 12 20:14:57 <CIA-83> jow * r26619 /packages/utils/hd-idle/Makefile: [packages] hd-idle: remove redundant PKG_BUILD_DIR, extend copyright
Apr 12 20:20:56 <CIA-83> jow * r26620 /trunk/tools/missing-macros/ (Makefile src/m4/fake-gtk-doc-check.m4):
Apr 12 20:20:56 <CIA-83> missing-macros: add GTKDOC_REBASE macro needed by some newer packages
Apr 12 20:20:56 <CIA-83> Signed-off-by: Jochen Friedrich <jochen@scram.de>
Apr 12 20:21:32 <CIA-83> jow * r26621 /branches/backfire/tools/missing-macros/ (Makefile src/m4/fake-gtk-doc-check.m4): [backfire] merge r26620§
Apr 12 20:24:36 <xMff> cshore: is this still relevant? http://patchwork.midlink.org/patch/530/
Apr 12 20:25:25 <cshore> xMff: no, that functionality is in the current miniupnpd
Apr 12 20:34:18 <CIA-83> jow * r26622 /trunk/package/qos-scripts/ (3 files in 2 dirs): (log message trimmed)
Apr 12 20:34:18 <CIA-83> This patch updates qos-scripts to support fair traffic sharing using the
Apr 12 20:34:18 <CIA-83> SFQ with external classifiers method. It also corrects a bug in the
Apr 12 20:34:18 <CIA-83> unsupported ESFQ method already used by qos-scripts. (ESFQ:
Apr 12 20:34:18 <CIA-83> http://fatooh.org/esfq-2.6/ only updated to 2.6.24, it was switched to
Apr 12 20:34:18 <CIA-83> an SFQ patch after that and not updated since 2008)
Apr 12 20:34:19 <CIA-83> A class can be forced to use SFQ, and an external classifier added like
Apr 12 20:34:29 <xMff> cshore: ok
Apr 12 20:35:10 <cshore> xMff: btw I noticed that ipv6 routes that depend on the 6to4 interface fail to be created unless you add something like 93_6to4-route that does the routes after 91_6to4.  on a fairly old revision (r24941).  I don't see any changes that would fix in the hotplug.d scripts, so unless it's been fixed elsewhere it's probably still a problem.
Apr 12 20:35:41 <xMff> cshore: good point, might need to relocate routes hotplug
Apr 12 20:36:24 <xMff> can you give it a try sometime? (simply move the default route hotplug to 99)
Apr 12 20:37:51 <cshore> ok...it might be a little while (I'm currently merging various configuration things on my routers, and realizing changes I'd forgotten about that were done in a hurry.
Apr 12 20:38:51 <CIA-83> jow * r26623 /trunk/package/base-files/Makefile: (log message trimmed)
Apr 12 20:38:51 <CIA-83> base-files: return success on lib-copying with external toolchain
Apr 12 20:38:51 <CIA-83> when using an external toolchain the base-files package copies libc, libgcc and
Apr 12 20:38:51 <CIA-83> others from the library directory.
Apr 12 20:38:51 <CIA-83> The file list is given as following in the .config:
Apr 12 20:38:52 <CIA-83> CONFIG_LIBC_FILE_SPEC="./lib/ld{-*.so,-linux*.so.*} ./lib/lib{anl,c,cidn,crypt,dl,m,nsl,nss_dns,nss_files,resolv,util}{-*.so,.so.*}"
Apr 12 20:38:53 <CIA-83> Because the filenames are composed with different endings, not all files exist
Apr 12 20:44:11 <xMff> cshore: what about this? http://patchwork.midlink.org/patch/3/
Apr 12 20:46:48 <cshore> xMff: with some minor changes to reflect the changes in block-mount (the merge and changes to block-extroot before that) it should be relevant still.
Apr 12 20:47:25 <builder_> build #4 of ixp4xx is complete: Failure [failed compile_4]  Build details are at http://tksite.gotdns.org:8010/builders/ixp4xx/builds/4
Apr 12 20:47:43 <CIA-83> jow * r26624 /trunk/target/linux/x86/image/Config.in:
Apr 12 20:47:43 <CIA-83> Enable padding of jffs2 images to user specified filesystem size
Apr 12 20:47:43 <CIA-83> Signed-off-by: Vasilis Tsiligiannis <b_tsiligiannis@silverton.gr>
Apr 12 20:49:54 <CIA-83> jow * r26625 /trunk/target/linux/x86/image/Makefile:
Apr 12 20:49:54 <CIA-83> [x86] gzip jffs2 images
Apr 12 20:49:54 <CIA-83> Signed-off-by: Vasilis Tsiligiannis <b_tsiligiannis@silverton.gr>
Apr 12 20:50:13 <xMff> cshore: okm are you in patchwork?
Apr 12 20:51:13 <cshore> I am now
Apr 12 20:51:46 <xMff> as cshore ?
Apr 12 20:51:53 <cshore> yep
Apr 12 20:52:21 <xMff> ok
Apr 12 20:52:29 <xMff> you should now be able to manage patchwork items
Apr 12 20:52:56 <xMff> note that "accepted" as patch status is what "closed" would be in trac
Apr 12 20:53:52 <cshore> ok, I delegated the kexec patch to me...I'll try to take a look at it this week
Apr 12 20:54:00 <xMff> sure, no hurry
Apr 12 20:55:22 <cshore> http://patchwork.midlink.org/patch/6/
Apr 12 20:55:23 <cshore> what do you think of that one?  I'm not sure I like the concept for the purposes of extroot.
Apr 12 20:56:26 <xMff> hm nice idea but cannot judge the practical value
Apr 12 20:57:31 <xMff> and seems invasive
Apr 12 20:57:46 <xMff> no idea, maybe later
Apr 12 20:58:08 <philipp64|laptop> cshore: does that mean that we'll soon have an easy way of doing a persistent ext2/4 filesystem for extroot on CF for x86?
Apr 12 20:58:13 <xMff> also since we mount by target name now it would be maybe better to just allow foo/bar
Apr 12 20:58:14 * philipp64|laptop hopes wildly....
Apr 12 20:59:03 <cshore> philipp64|laptop: er, I'm not sure what you mean by that.  The overlay is persisent.
Apr 12 20:59:43 <philipp64|laptop> all of the x86 systems that I'm aware of have a CF reader/writer that's bootable and takes 512MB or larger CF's.
Apr 12 20:59:56 <cshore> philipp64|laptop: yes, and?
Apr 12 21:00:18 <philipp64|laptop> more than big enough to have two partitions, one for bootable images and another for /overlay...  so I can keep Asterisk voicemail files on it, custom sounds, etc.
Apr 12 21:00:38 <russell--> soekris net4x26 have flash soldered on, fwiw
Apr 12 21:01:07 <philipp64|laptop> ok, I should add that I don't know any systems that haven't been manufactured in the last 4 years... ;-)
Apr 12 21:01:12 <philipp64|laptop> *own
Apr 12 21:01:20 <cshore> philipp64|laptop: you mean like /dev/sda1 for grub and /dev/sda2 for ext4 like now, only with squashfs, for which there are also images?
Apr 12 21:01:38 <xMff> cshore: more like an overlay that isn't wiped with a system upgrade
Apr 12 21:01:47 <philipp64|laptop> exactly.
Apr 12 21:01:51 <xMff> cshore: but on the main flash not on an external media
Apr 12 21:01:59 <philipp64|laptop> and that can be easily built and packaged in an automated fashion.
Apr 12 21:02:33 <cshore> xMff: while wouldn't that just be a matter of making three partitions instead of two?
Apr 12 21:02:45 <xMff> cshore: very likely so
Apr 12 21:02:52 <philipp64|laptop> why 3?
Apr 12 21:03:02 <cshore> philipp64|laptop: because there are already 2
Apr 12 21:03:10 <xMff> heh
Apr 12 21:03:15 <russell--> or strategically not remaking the third one
Apr 12 21:03:16 <philipp64|laptop> so what's the 3rd one needed for?
Apr 12 21:03:26 <cshore> grub, rootfs, and ovleray
Apr 12 21:03:26 <russell--> your stuff that you don't want stomped on
Apr 12 21:03:54 <cshore> or better grub, rootfs, and extra storage (not sure why you want an overlay in this case)
Apr 12 21:04:00 <russell--> yeah
Apr 12 21:04:03 * russell-- was going to say
Apr 12 21:04:59 <cshore> philipp64|laptop: the point of the overlay is to be able to have a bigger rootfs than the onboard flash allows
Apr 12 21:05:31 <cshore> philipp64|laptop: what you want is safe storage for voicemail etc (a data partition)
Apr 12 21:05:58 * russell-- did something like that for an alix-based kismet stumbler device
Apr 12 21:07:10 <russell--> it's been a while, but i think i just created another partition and mounted it
Apr 12 21:07:33 <cshore> philipp64|laptop: the trick is to use something like sfdisk to automate the partitioning (since you probably don't want an image that has the data partition as a huge mostly 0 image (when uncompressed and written to the drive)
Apr 12 21:09:01 <cshore> philipp64|laptop: writing 300MB of zeroes just to create a partition would kind of suck
Apr 12 21:09:19 <philipp64|laptop> there's no way to store the rootfs image on the grub partition?
Apr 12 21:09:37 <cshore> philipp64|laptop: what's the problem with three partitions?
Apr 12 21:10:25 <philipp64|laptop> cshore: that's what compression is for. :-)
Apr 12 21:10:40 <philipp64|laptop> (re: the 300Mb of zeroes)
Apr 12 21:10:53 <cshore> philipp64|laptop: but you still have to write it uncompressed to create the image and to get it onto the disk
Apr 12 21:11:04 <cshore> it's still a lengthy process and unncessary
Apr 12 21:11:08 <philipp64|laptop> no problem with 3 partitions... just trying to figure out what's the absolute minimum necessary.
Apr 12 21:11:22 <philipp64|laptop> cshore: yes, but you do that only once...
Apr 12 21:11:42 <philipp64|laptop> and on a 30X write-speed 4GB CF, that's pretty fast.
Apr 12 21:11:42 <cshore> philipp64|laptop: going less than 3 will complicate your life horribly, and it's not on my radar
Apr 12 21:11:51 <CIA-83> nbd * r26626 /trunk/target/linux/ar71xx/generic/profiles/ (02-ath5k.mk 02-madwifi.mk): ar71xx: replace the madwifi profile with an ath5k profile
Apr 12 21:12:14 <cshore> philipp64|laptop: why not use sfdisk....much better option, use a firstboot script
Apr 12 21:12:33 <philipp64|laptop> as long as it works, I don't care. :-)
Apr 12 21:13:10 <philipp64|laptop> as long as firstboot doesn't require python and GTK
Apr 12 21:13:30 <cshore> philipp64|laptop: say what?  whatever gave you that idea?
Apr 12 21:14:14 <cshore> philipp64|laptop: firstboot is for embedded system and is already there.  Adding sfdisk stuff could be done with a shell script, or you could for robustness write some C code.
Apr 12 21:14:15 <philipp64|laptop> that's what CentOS/Fedora firstboot requires.
Apr 12 21:14:35 <philipp64|laptop> it was tongue-in-cheek.
Apr 12 21:14:42 <cshore> philipp64|laptop: ah, ok
Apr 12 21:16:27 <cshore> philipp64|laptop: all you're really after is an automatic 'use the rest of the disk for a third partition and format it' script
Apr 12 21:16:53 <cshore> philipp64|laptop: you should be able to figure it out, and use /etc/config/fstab to mount it during init.d
Apr 12 21:17:53 <cshore> philipp64|laptop: on the first flash, and 'don't format if the partition already exists'
Apr 12 21:17:57 <CIA-83> jow * r26627 /trunk/include/quilt.mk: [include] silence error when package has no patches (patchwork 321)
Apr 12 21:18:43 <cshore> philipp64|laptop: for that matter what you want is to only rewrite the rootfs and kernel on upgrade, and not the entire disk
Apr 12 21:21:05 <philipp64|laptop> yup
Apr 12 21:21:10 <cshore> for that you need during sysupgrade to create a roofs on tmpfs, make sure you have all essential to sysupgrade binaries and libraries, pivot to the ramdisk, then do dd as required for sda1 (kernel) and sda2 (rootfs), leaving sda3 and parittion table untouched
Apr 12 21:22:07 <philipp64|laptop> sounds good. now script it. :-)
Apr 12 21:22:31 <cshore> philipp64|laptop: send me hardware to develop on and I will ;-)
Apr 12 21:22:38 <philipp64|laptop> I'm afraid to break it.
Apr 12 21:23:12 <philipp64|laptop> I have some here kicking around...
Apr 12 21:24:03 <loswillios> wow, kexec from an usb device would be nice
Apr 12 21:25:23 <cshore> loswillios: it'll get in there eventually....
Apr 12 21:26:30 <cshore> loswillios: if I ever stop delaying paying work and have time to do it, that is
Apr 12 21:29:52 <CIA-83> nbd * r26628 /branches/backfire/package/kernel/modules/netdevices.mk: kernel: include firmware in the e100 package (backport of r26539)
Apr 12 21:36:07 <CIA-83> nbd * r26629 /packages/net/tcpdump/patches/100-tcpdump_mini.patch: tcpdump: add back LINUX_SLL support to tcpdump-mini to fix ppp packet dumping (fixes #6236)
Apr 12 21:42:11 <loswillios> cshore: cool
Apr 12 21:47:43 <RealOpty> xMff, u find my msg?
Apr 12 21:48:48 <xMff> RealOpty: no?
Apr 12 21:49:23 <RealOpty> pure-ftpd has a new release :)
Apr 12 21:50:12 <RealOpty> xMff, know if filezilla is in the feeds? or even capable of running on brcm47 devices?
Apr 12 21:51:21 <xMff> ok, yes, don't know
Apr 12 21:51:28 <xMff> oops
Apr 12 21:51:33 <xMff> ok, no, don't know
Apr 12 21:51:42 <RealOpty> lol ty :D
Apr 12 21:51:59 <xMff> I'd say its too fat
Apr 12 21:52:19 <RealOpty> thats what i was thinkin
Apr 12 21:54:24 <trine> Kaloz, ping
Apr 12 21:55:15 <russell--> one thing that is kind of sucking about ath5k is that /etc/config/wireless gets confused if the macaddr of the radio isn't in the first block ... this makes creating pre-cooked images somewhat problematical
Apr 12 21:56:05 <russell--> if i create a block without the macaddr (but with other things configured), it gets bypassed (or seemed to the one time i tried that) and a second radio is configured
Apr 12 21:56:57 <xMff> russell--: tryied "option phy phy0" instead of option macaddr?
Apr 12 21:59:46 <russell--> i will
Apr 12 21:59:58 <russell--> thanks for the pointer
Apr 12 22:00:07 <xMff> that is the common way to do it for predeployments
Apr 12 22:00:12 <xMff> there are two downsides:
Apr 12 22:00:40 <xMff> in case of multiple radios the order is random (but consistent accross reboots), so far not worse than madwifi
Apr 12 22:00:52 <xMff> and the phy index shifts with module reloads
Apr 12 22:00:53 <russell--> ok
Apr 12 22:01:14 <xMff> e.g. phy0 -> phy1 -> phy2 -> ...
Apr 12 22:01:18 <russell--> yeah
Apr 12 22:01:39 <PrimasMike_> xMff, this is PrimasMike
Apr 12 22:01:59 <xMff> PrimasMike_: hi again
Apr 12 22:02:00 <russell--> i just have a limited memory, and i am pretty sure i'll forget to tweak something on one of these images i'm remotely flashing ;-)
Apr 12 22:02:24 <PrimasMike_> I have read a bitabout the SSH stuff and have a few more questions
Apr 12 22:02:31 <russell--> like, i forgot to bake batman-adv into this last one ... fortunately on my desk ;-)
Apr 12 22:03:08 <PrimasMike_> if I understand this correctly, why would I need VPN and SSH
Apr 12 22:03:26 <PrimasMike_> wouldn't they do the same thing?
Apr 12 22:03:43 <xMff> PrimasMike_: exactly they would
Apr 12 22:04:38 <xMff> PrimasMike_: but a vpn allows you to overcome nat barriers and the like
Apr 12 22:05:03 <PrimasMike_> I lost that link to the wireshark forwarding.
Apr 12 22:05:06 <PrimasMike_> looking for it
Apr 12 22:05:09 <xMff> PrimasMike_: and it can make the router accessible where it otherwise wouldn't be
Apr 12 22:05:21 <xMff> or only through additional measures like dyndns
Apr 12 22:05:49 <PrimasMike_> do you have that link handy?
Apr 12 22:07:21 <xMff> (19:58:16) xMff: http://linuxexplore.wordpress.com/2010/05/30/remote-packet-capture-using-wireshark-tcpdump/
Apr 12 22:11:18 <cshore> nbd: for git am can you feed it the patchwork mbox url to get the patch and thus avoid having to save the patch somewhere?
Apr 12 22:11:19 <PrimasMike_> thanks,   I was off looking...
Apr 12 22:11:53 <nbd> cshore: i do this: 'wget -O- <mbox-url> | git am'
Apr 12 22:12:10 <nbd> or git am -p0 if the submitter was using svn
Apr 12 22:12:12 <cshore> nbd: I just thought of that after I asked...thanks for confirming
Apr 12 22:12:38 <xMff> if you have libwww-perl isntalled you can also use "GET"
Apr 12 22:12:51 <xMff> at least debian and ubuntu install this shortcut
Apr 12 22:13:15 <xMff> ... instead of wget -O- I mean
Apr 12 22:13:16 <PrimasMike_> OK,  so if I have an established VPN from router to router (using  openwrt), the does the "tcpdump -s 0 -U -n -w - -i eth0 not port 22" command pipe the traffic?
Apr 12 22:13:59 <cshore> PrimasMike: no, but you can use netcat or such
Apr 12 22:14:18 <xMff> or ssh
Apr 12 22:14:36 <cshore> PrimasMike: the command you did will just dump to standard out
Apr 12 22:14:51 <PrimasMike_> ok
Apr 12 22:15:05 <cshore> xMff: well if you can avoid encrypting twice I think it's better (hence netcat)
Apr 12 22:15:16 <xMff> true
Apr 12 22:15:21 <PrimasMike_> understood
Apr 12 22:15:39 <PrimasMike_> that was why I was thinking of the VPN only
Apr 12 22:16:06 <PrimasMike_> SSH requires I set up a SSH server at my host
Apr 12 22:16:27 <PrimasMike_> I was thinking of only using routers with a client to home back
Apr 12 22:16:49 <PrimasMike_> so the VPN client seemed to do the job
Apr 12 22:17:21 <cshore> PrimasMike: I prefer that too because it limited the listener to one host (the vpn server)
Apr 12 22:17:32 <cshore> *limits
Apr 12 22:18:11 <PrimasMike_> cshore, thanks for jumping in.  xMff has been helping us this morning.  I am in California.
Apr 12 22:18:38 <PrimasMike_> he has provide a number of great suggestions to simplify what we are doing
Apr 12 22:19:03 <PrimasMike_> for your sake, quickly ... we are trying to create a remote sniffing probe in the router
Apr 12 22:19:12 <cshore> PrimasMike: I saw
Apr 12 22:19:17 <cshore> PrimasMike: I was just busy
Apr 12 22:19:25 <PrimasMike_> great
Apr 12 22:19:33 <cshore> PrimasMike: well still am, but keep letting myself get distracted
Apr 12 22:19:40 <PrimasMike_> some people get this quickly and other ... never get it
Apr 12 22:19:54 <PrimasMike_> I appreciate it
Apr 12 22:20:47 <PrimasMike_> xMff / cshore  is the VPN approach doable?
Apr 12 22:21:22 <cshore> you're not listening on the wan, just listening to some other interface with pcap and then sending the pcap stream through the vpn, right?
Apr 12 22:21:28 <cshore> (e.g. with netcat)
Apr 12 22:22:02 <PrimasMike_> listening on LAN and routing across the WAN securley
Apr 12 22:22:20 <cshore> for testing purposes,and will do a pcap, socket thing for the real deal?
Apr 12 22:23:51 <PrimasMike_> yes
Apr 12 22:24:25 <PrimasMike_> for development, I need to get "sniffed data" across the network quickly for proof of concept
Apr 12 22:24:31 <cshore> sounds reasonable to me....
Apr 12 22:25:04 <PrimasMike_> sorry, which way sounds reasonable?
Apr 12 22:25:20 <russell--> nbd: you can probably close this now: https://dev.openwrt.org/ticket/8978 (my iftop problem)
Apr 12 22:26:10 <cshore> doing proof of concept with tcdump <-> netcat <-> VPN client <-> VPN server <-> netcat <-> wireshark
Apr 12 22:26:13 <nbd> oh, right
Apr 12 22:26:29 <PrimasMike_> ok
Apr 12 22:27:19 <cshore> when you've proved it works, you can do libpcap app <-> socket with SSL <-> socket listener <-> wireshark
Apr 12 22:28:26 <cshore> actually libcap socket app with SSL <-> SSL socket listener <-> wireshark
Apr 12 22:28:33 <PrimasMike_> yes, my guy had started with that approach and we were running into missing traffic
Apr 12 22:29:25 <PrimasMike_> so back to the easy approach
Apr 12 22:29:32 <cshore> PrimasMike: well it sounded like he was trying to route packets instead of send a pcap stream
Apr 12 22:29:49 <PrimasMike_> tcdump <-> netcat <-> VPN client <-> VPN server <-> netcat <-> wireshark
Apr 12 22:30:22 <PrimasMike_> what is the command line for tcpdump to route the traffic to netcat
Apr 12 22:30:26 <cshore> PrimasMike: the main advantage of that is that it's just configuration instead of coding
Apr 12 22:30:55 <PrimasMike_> PERFECT !
Apr 12 22:31:48 <PrimasMike_> When I originally tasked my guy with this , I envisioned that it was something simple for proof of concept
Apr 12 22:32:52 <PrimasMike_> he got some bad direction from some forums and we went down the long and winding road
Apr 12 22:33:28 <PrimasMike_> is there a special tcpdump command line?
Apr 12 22:33:45 <cshore> tcpdump -s0 -w- -i eth0 | netcat ip port (or netcat -p port ip depending on the version of netcat)
Apr 12 22:33:45 <cshore> and on the other end netcal -l -p port | wireshark -  or somesuch
Apr 12 22:34:06 <cshore> the important thing is the -w-  that means write to stdout
Apr 12 22:34:27 <cshore> everything else is standard tcpdump cli
Apr 12 22:40:40 <cshore> the listener has to be started first
Apr 12 22:40:50 <PrimasMike_> how does the stdout get routed to the VPN
Apr 12 22:41:16 <cshore> netcat ip port (takes stdin and outputs to a socket at ip:port)
Apr 12 22:41:36 <PrimasMike_> so....
Apr 12 22:41:44 <cshore> sometimes know as nc, and command line depends on the version of netcatp
Apr 12 22:41:54 <cshore> *netcat
Apr 12 22:42:13 <xMff> so ip:port happens to be a host on the other end of your vpn
Apr 12 22:42:17 <PrimasMike_> when the remote router starts, the VPN client attaches back to our server
Apr 12 22:42:47 <PrimasMike_> then the netcat connects to the VPN IP
Apr 12 22:42:57 <xMff> .. of the remote router
Apr 12 22:43:01 <PrimasMike_> y
Apr 12 22:43:10 <cshore> Ah ,better:
Apr 12 22:43:36 <cshore> tcdump -w - | netcat -l port  on the router
Apr 12 22:43:40 <PrimasMike_> the remote router's IP would be a "Local" IP of our host network
Apr 12 22:43:55 <cshore> that way the router listens on it's VPN IP
Apr 12 22:44:02 <PrimasMike_> y
Apr 12 22:44:14 <PrimasMike_> sound right?
Apr 12 22:44:53 <cshore> well actually it'd be the IP of the VPN (which is usually different than the local host network)
Apr 12 22:45:04 <PrimasMike_> true
Apr 12 22:45:31 <PrimasMike_> in our proof of concept, we are hosting everythin on 1 server
Apr 12 22:45:46 <cshore> right, so just use the VPN IP and you'll be fine
Apr 12 22:45:57 <PrimasMike_> so the sniffer and the VPN server (Windows 2008) are all the same
Apr 12 22:46:42 <PrimasMike_> sorry,  the VPN server may be the host router
Apr 12 22:46:53 <PrimasMike_> I have to check how he did this.
Apr 12 22:47:11 <cshore> it'd be better if the listener was the 2008 server
Apr 12 22:47:32 <cshore> and have the random router connect to the known server
Apr 12 22:47:35 <PrimasMike_> that is what I had assumed as well
Apr 12 22:47:48 <PrimasMike_> but then I thought... I am not sure what my guy did
Apr 12 22:47:51 <PrimasMike_> I have to check
Apr 12 22:48:21 <PrimasMike_> so we can assume that he will change it that way for discussion
Apr 12 22:48:28 <PrimasMike_> as we both agree that is better
Apr 12 22:49:18 <PrimasMike_> does the openwrt client connect to windows 2008?
Apr 12 22:49:24 <PrimasMike_> VPN client that is
Apr 12 22:50:17 <xMff> if you want to connect to windows you have the choice between pptp and ipsec
Apr 12 22:50:33 <xMff> both are crappy in their own ways
Apr 12 22:50:39 <PrimasMike_> lolo
Apr 12 22:50:44 <cshore> well, you have to pick a supported VPN type.  e.g. you can install OpenVPN on the server, or you can use the built in pptp or ipsec
Apr 12 22:51:09 <xMff> yes, I'd almost say that openvpn on windows 2008 is easier to handle
Apr 12 22:51:27 <PrimasMike_> that is what we were looking at
Apr 12 22:52:13 <PrimasMike_> since I don't recall him installing that, I am assuming he is either using the routers or Windows 2008
Apr 12 22:52:50 <PrimasMike_> can I ask again about the stdout quesiton
Apr 12 22:53:11 <cshore> PrimasMike: sorry could you repeat the question?
Apr 12 22:53:20 <PrimasMike_> how to get from tcpdump to netcat
Apr 12 22:53:29 <xMff> with a pipe
Apr 12 22:53:43 <cshore> tcpdump blah -w - | netcat -l port
Apr 12 22:54:15 <cshore> the | character mean take stdout from the first command and send it to stdin of the second one
Apr 12 22:54:27 <PrimasMike_> and I should see all the traffic?
Apr 12 22:54:29 <PrimasMike_> understood
Apr 12 22:54:33 <PrimasMike_> pipe
Apr 12 22:54:36 <xMff> not you
Apr 12 22:54:47 <xMff> the terminal remains empty, but netcat will "see" it
Apr 12 22:54:55 <xMff> and send it over the network
Apr 12 22:56:43 <PrimasMike_> so if we put a sniffer on the WAN port (mirrored through an old hub-[not switch]) we should see encrypted data
Apr 12 22:57:14 <xMff> yes
Apr 12 22:57:33 <xMff> some connection from your router to your windows server, most likely using udp on port 1194
Apr 12 22:57:47 <xMff> that'd be the openvpn tunnel connection
Apr 12 22:57:53 <PrimasMike_> y
Apr 12 22:59:14 <PrimasMike_> actually, for troubleshooting purposes, we have a way of generating traffic on a hub (that we have this remote router) and another sniffer on the WAN of the router
Apr 12 22:59:59 <PrimasMike_> we could simply install openvpn or something on that PC/Snifrer so the router connects directly to it
Apr 12 23:00:40 <PrimasMike_> our first POC needs to be routing the packets through the remote router with tcpdump / netcat
Apr 12 23:01:52 <PrimasMike_> xMff I am keeping you up again.  Sorry
Apr 12 23:02:07 <PrimasMike_> I just looked at the time
Apr 12 23:02:58 <PrimasMike_> is there a way to save this chat session from the web?  or cut an dpaste the only option
Apr 12 23:03:14 <cshore> hmmm....using Windows wireshark might complicate the reception end of things.  Does windows have mkfifo equivalent?
Apr 12 23:03:46 <PrimasMike_> actually we are using ethertest,
Apr 12 23:04:06 <cshore> ah, does it accept input on stdin?
Apr 12 23:04:07 <PrimasMike_> and we are able to see incoming data on the ndis driver
Apr 12 23:04:12 <PrimasMike_> so we see everything
Apr 12 23:04:36 <cshore> PrimasMike: does it understand pcap streams?
Apr 12 23:04:58 <PrimasMike_> they are IP packets right?
Apr 12 23:05:11 <cshore> PrimasMike: not exactly
Apr 12 23:05:54 <PrimasMike_> I just checked and it says that it can read pcap files generated by tcpcump
Apr 12 23:05:56 <cshore> PrimasMike: their encapsulated IP packets (i.e. the sniffed packets are a stream instead the packets send over the remote connection)
Apr 12 23:06:17 <cshore> *instead=inside
Apr 12 23:06:56 <cshore> PrimasMike: ok, can it read a file that is currently being written to?
Apr 12 23:07:08 <cshore> and keep reading while it gets added to?
Apr 12 23:07:20 <cshore> kind of like a linux FIFO
Apr 12 23:09:00 <cshore> because you want as it's happening, not spool and read later, right?
Apr 12 23:09:08 <PrimasMike_> reading
Apr 12 23:12:23 <PrimasMike_> right, we need real time
Apr 12 23:12:55 <PrimasMike_> why wouldn't it be in packets?
Apr 12 23:15:21 <cshore> because it's not naked (i.e. it's not being sent on the wire, but through a pcap stream that includes all information about the packet, without changing or routing it)
Apr 12 23:15:58 <cshore> as soon you have naked packets over tcp/ip they'll try to be routed
Apr 12 23:16:21 <cshore> they have to be encapsulated to cross unchanged and unrouted
Apr 12 23:18:08 <cshore> basically the IP address, port and other header information have to be treated as data instead of as things to be acted on
Apr 12 23:18:37 <cshore> since those are vital to understanding what was going on with the packet at the source
Apr 12 23:19:29 <CIA-83> acinonyx * r26630 /packages/net/rsync/ (Makefile files/ files/rsyncd.conf files/rsyncd.init):
Apr 12 23:19:29 <CIA-83> [packages] rsync: Add initscript for rsync daemon
Apr 12 23:19:29 <CIA-83> Add an initscript to the rsync package for use as a daemon, and a sample rsyncd.conf to show a simple setup.
Apr 12 23:19:29 <CIA-83> Signed-off-by: Ian Leonard <antonlacon@gmail.com>
Apr 12 23:19:30 <CIA-83> acinonyx * r26631 /packages/net/rsync/files/rsyncd.init: [packages] rsync: Remove trailing whitespace error from init script
Apr 12 23:19:38 <CIA-83> acinonyx * r26632 /trunk/package/kernel/modules/fs.mk:
Apr 12 23:19:38 <CIA-83> [package] kernel/modules: fix kmod-fs-btrfs deps / zlib_deflate / makefile
Apr 12 23:19:38 <CIA-83> btrfs needs zlib_deflate, which was built but not included
Apr 12 23:19:38 <CIA-83> Signed-off-by: Bastian Bittorf <bittorf@bluebottle.com>
Apr 12 23:19:43 <CIA-83> acinonyx * r26633 /packages/utils/ (pciutils/Makefile usbutils/Makefile): [packages] {pciutils,usbutils}: save space when installing pciutils and usbutils v1 (thanks Peter Wagner)
Apr 12 23:19:48 <CIA-83> acinonyx * r26634 /packages/net/rsync/Makefile: [packages] rsync: Update copyright notice date
Apr 12 23:19:54 <CIA-83> acinonyx * r26635 /trunk/package/kernel/modules/ (lib.mk other.mk): [package] kernel/modules: Add "Libraries" submenu and move library packages there
Apr 12 23:19:58 <CIA-83> acinonyx * r26636 /trunk/package/kernel/modules/ (fs.mk lib.mk): [package] kernel/modules: Add zlib package
Apr 12 23:25:18 <PrimasMike_> understood
Apr 12 23:25:38 <PrimasMike_> but when they get encapsulated, they become the "payload"
Apr 12 23:25:53 <cshore> right
Apr 12 23:26:15 <PrimasMike_> so a packet in a packet
Apr 12 23:26:19 <cshore> yes
Apr 12 23:26:55 <cshore> except it's not 1 packet : 1 packet
Apr 12 23:26:56 <xMff> if you count the vpn its a packet in a packet in a packet :P
Apr 12 23:27:35 <PrimasMike_> so when the payload is removed, don't we have an IP packet again
Apr 12 23:28:07 <xMff> you mean if the encapsulation is removed?
Apr 12 23:28:14 <PrimasMike_> y
Apr 12 23:28:21 <xMff> yes you do
Apr 12 23:28:36 <xMff> but that does not mean it magically starts to move
Apr 12 23:28:57 <PrimasMike_> so why does my host sniffer have to look at streaing data then?
Apr 12 23:29:02 <PrimasMike_> streaming
Apr 12 23:29:04 <xMff> actually it will be just a char array in your receiver application
Apr 12 23:29:57 <PrimasMike_> somehow we lost the simple approach.  What did I say wrong
Apr 12 23:30:12 <xMff> no we didn't
Apr 12 23:31:24 <PrimasMike_> I am hoping that the host system will just forward a "non-routable" packet out an interface that my sniffer can read
Apr 12 23:31:43 <xMff> what is your sniffer?
Apr 12 23:32:01 <PrimasMike_> ethertest
Apr 12 23:32:12 <PrimasMike_> but can be wireshark for discussion
Apr 12 23:32:27 <cshore> xMff: does windows have a mkfifo like thing?
Apr 12 23:32:58 <xMff> cshore: it has stdin and stdout, on nt maybe even named pipes but I wouldn't rely on that
Apr 12 23:33:52 <xMff> PrimasMike_: what you describe at simple (make a tool sniff on some interface) is actually way harder than make the tool read a pcap stream from stdin or a buffer file or a fifo
Apr 12 23:33:52 <cshore> xMff: because I don't think sniffers read pcap stream from stdin - they want a file (even if a fifo)
Apr 12 23:34:47 <xMff> you could write a receiver deamon that spawns a tap interface, de-encapsulates the pcap data stream and throw the unpacked packets onto the tap devicew
Apr 12 23:34:58 <xMff> then you can make any tool sniff there
Apr 12 23:35:06 <xMff> but again, thats not easy anymore
Apr 12 23:35:10 <xMff> especially not on windows
Apr 12 23:35:33 <CIA-83> acinonyx * r26637 /trunk/package/kernel/modules/crypto.mk: [package] kernel/modules: Add kmod-zlib dependency to kmod-crypto-deflate
Apr 12 23:36:16 <xMff> I somehow understand your idea to just clone packets and throw them as-is onto a vpn link
Apr 12 23:36:21 <xMff> but this is not going to work
Apr 12 23:36:40 <xMff> not on Linux and especially not on Windows
Apr 12 23:36:50 <PrimasMike_> this is the problem we have been facing
Apr 12 23:36:56 <PrimasMike_> seems easy, but not
Apr 12 23:36:58 <cshore> PrimasMike: any chance you can run a VM with Linux?  That would let you use the article xMff linked verbatim
Apr 12 23:37:15 <PrimasMike_> yes
Apr 12 23:37:25 <PrimasMike_> we can use two routers
Apr 12 23:37:48 <PrimasMike_> we can use a linux VM at out host site
Apr 12 23:38:21 <cshore> PrimasMike: the linux VM would be for the wireshark side of things
Apr 12 23:38:40 <PrimasMike_> y
Apr 12 23:39:35 <PrimasMike_> the real requirement for us now is we need to use ethertest because it has special decoders and a .DLL to export our data
Apr 12 23:39:47 <cshore> PrimasMike: on the VM you have an OpenVPN server (to which the sniffing router connects)
Apr 12 23:39:58 <PrimasMike_> for routing POC, we can use wireshark to test the routing
Apr 12 23:40:00 <cshore> PrimasMike: oh, and that's Windows only, right?
Apr 12 23:40:07 <PrimasMike_> y
Apr 12 23:41:06 <cshore> damn.  With wireshark and Linux it's simple
Apr 12 23:41:18 <cshore> Windows I'm not sure about decoding the pcap in realtime
Apr 12 23:41:53 <PrimasMike_> I dont' understand because wireshare looks for packets as wel
Apr 12 23:42:11 <cshore> take a look at http://linuxexplore.wordpress.com/2010/05/30/remote-packet-capture-using-wireshark-tcpdump/
Apr 12 23:42:20 <PrimasMike_> I saw that
Apr 12 23:42:26 <cshore> the key thing you can't do in Windows is mkfifo
Apr 12 23:42:28 <xMff> the problem is that all those programs are made to read from a network interface or a file
Apr 12 23:42:28 <PrimasMike_> xMff showed that
Apr 12 23:42:46 <xMff> network interface is not possible as you need to decode the data first
Apr 12 23:43:05 <CIA-83> acinonyx * r26638 /trunk/package/kernel/modules/crypto.mk: [package] kernel/modules: Fix r26637
Apr 12 23:43:16 <xMff> file is impractical as you want it in realtime, not - say - decode 2GB and then lounch your sniffer on that
Apr 12 23:43:24 <cshore> that creates a file that is able to be read and written at the same time, so you can keep sending data to it, while at the same time reading it and decoding it
Apr 12 23:43:44 <xMff> so you need a way to make the program thing its reading from a file while it is actually a fifo, means the program is reading one and while you constantly fill the other
Apr 12 23:44:08 <xMff> *reading one end
Apr 12 23:44:23 <PrimasMike_> I understand what you are discussing
Apr 12 23:44:41 <PrimasMike_> I did that stuff 20 years ago but have no idea now
Apr 12 23:45:19 <PrimasMike_> they have a way of reading files
Apr 12 23:45:34 <xMff> to make it short
Apr 12 23:45:46 <xMff> you need an equivalent of "mkfifo" for windows
Apr 12 23:46:06 <xMff> it has the capability for named pipes, you just need some script/command/c programm to create such a pipe file
Apr 12 23:46:19 <xMff> which you can then pass to wireshark or ethertest for reading
Apr 12 23:46:49 <PrimasMike_> windows has to have a way of redirecting I/O
Apr 12 23:46:57 <PrimasMike_> I did it 20 years ago
Apr 12 23:47:11 <PrimasMike_> they couldn't have screwed it up that bad
Apr 12 23:47:26 * cshore laughs hysterically
Apr 12 23:48:31 <cshore> PrimasMike: listen to xMff: you need mkfifo-equivalent
Apr 12 23:48:52 <cshore> PrimasMike: not just stdin/out redirection
Apr 12 23:49:33 <CIA-83> acinonyx * r26639 /trunk/package/kernel/modules/lib.mk: [package] kernel/modules: Move zlib_deflate module to higher autoloading priority
Apr 12 23:49:57 <cshore> PrimasMike: if etherest or wireshark read pcaps from stdin there wouldn't be a problem
Apr 12 23:50:18 <PrimasMike_> they mention something about that
Apr 12 23:50:25 <xMff> http://gnuwin32.sourceforge.net/packages/coreutils.htm
Apr 12 23:50:33 <xMff> that one provides an mkfifo.exe
Apr 12 23:50:37 <PrimasMike_> but I think it only refers to reading files
Apr 12 23:50:53 <xMff> so   mkfifo.exe  some_pipe.pcap
Apr 12 23:51:25 <xMff> netcat.exe -l 1234 > some_pipe.pcap
Apr 12 23:51:33 <xMff> wireshark.exe some_pipe.pcap
Apr 12 23:52:14 <PrimasMike_> sorry, not following you ??
Apr 12 23:53:36 <PrimasMike_> ah, got it now
Apr 12 23:54:02 <xMff> sorry, I have to sleep now, I'll be back tomorrow
Apr 12 23:54:25 <PrimasMike_> you guys have been aswesome
Apr 12 23:54:38 <PrimasMike_> totally appreciate your help
Apr 12 23:55:01 <PrimasMike_> we have some work to do
Apr 12 23:55:08 * russell-- thinks true help won't arrive until you abandon win7 for linux
Apr 12 23:55:32 <PrimasMike_> have to convince my customers first
Apr 12 23:55:53 <PrimasMike_> we use linux for much of our stuff
Apr 12 23:56:54 <PrimasMike_> Thailand has their "water holiday"
Apr 12 23:57:21 <PrimasMike_> for the next three days.  So PrimasRich will be soaking wet and not working too hard
Apr 12 23:58:27 <PrimasMike_> If you guys ever get a chance to go to Thailand, this holiday is a fun one.  The whole city is open to spray / dump water on anyone walking by
Apr 13 00:00:32 <PrimasMike_> russell, are you in Germany as well?
Apr 13 00:03:03 <philipp64|laptop> nbd and xMff: I'm looking at /lib/network/config.sh where setup_interface() calls dhcp... and wondering, if we kept "state" in /var instead of /tmp, could we grovel the old IP address out of /var/state/network?
Apr 13 00:04:41 <cshore> philipp64|laptop: /var is a symlink to /tmp in OpenWRT
Apr 13 00:04:53 <solca> philipp64|laptop: as Nuno said on the ML if your board does not have a RTC you can't validate the DHCP lease
Apr 13 00:04:57 <philipp64|laptop> yeah, we need to fix that first off.
Apr 13 00:05:06 <solca> until you gain network conectivity
Apr 13 00:05:15 <philipp64|laptop> most of my boards do.
Apr 13 00:05:45 <cshore> but the majority of OpenWRT boards don't
Apr 13 00:06:07 <nbd> philipp64|laptop: it is intentional that the state is not kept on flash
Apr 13 00:06:12 <philipp64|laptop> ok, so we look for /sys/devices/rtc or whatever...
Apr 13 00:06:29 <philipp64|laptop> nbd: where else would we keep it?
Apr 13 00:06:41 <philipp64|laptop> or /dev/rtc ...
Apr 13 00:07:02 <cshore> philipp64|laptop: we don't keep transient state
Apr 13 00:07:17 <cshore> philipp64|laptop: across rebotos
Apr 13 00:07:26 <philipp64|laptop> "we don't" or "we haven't because we couldn't in the past"?
Apr 13 00:08:00 <cshore> philipp64|laptop: because most OpenWRT boards have limited flash and it's a bad idea to randomly write state to flash
Apr 13 00:08:11 <nbd> /var/state contains all kinds of runtime stuff
Apr 13 00:08:20 <nbd> writing there should not trigger flash writes
Apr 13 00:08:24 <nbd> nor should the data be kept
Apr 13 00:08:38 <nbd> if dhcp leases should be kept, then there needs to be a separate option for that
Apr 13 00:08:43 <solca> doesn't a good DHCP server will try to assign you the same address if possible?
Apr 13 00:08:51 <nbd> that saves *only* the ip address to /etc/config/network
Apr 13 00:08:58 <nbd> solca: yes
Apr 13 00:09:04 <philipp64|laptop> solca: Comcast DHCP servers (for instance) are well-known to be anti-social.
Apr 13 00:09:52 <philipp64|laptop> they sometimes fail to renew your lease so you'll get a new IP address... (1) makes it harder to do p2p file-sharing, and (2) means that a 3rd party VoIP service will drop your calls when your lease gets renewed.
Apr 13 00:10:01 <philipp64|laptop> they do it to be malicious.
Apr 13 00:10:19 <philipp64|laptop> or at least to make sure that only their services work, and no one else's. sigh.
Apr 13 00:10:37 <philipp64|laptop> I would not count on an ISP's DHCP server to do the right thing.
Apr 13 00:12:31 <PrimasMike_> cshore, thank you for your help
Apr 13 00:12:42 <cshore> PrimasMike: you're welcome
Apr 13 00:12:56 <philipp64|laptop> nbd: ideally you'd save the entire lease (i.e. transaction id, server IP address, expiration date, DNS servers, etc) and simply renew it via REQUEST... rather than starting a whole new DISCOVERY cycle.
Apr 13 00:12:56 <solca> philipp64|laptop: by the time you reconnect your apps (p2p or voip) will need to recover anyways so having a different IP is not that bad?
Apr 13 00:13:06 <PrimasMike_> I have a lot of reading to do now
Apr 13 00:13:24 <cshore> philipp64|laptop: part of your problem is your hardware and use cases fall outside the main focus of openwrt
Apr 13 00:13:32 <PrimasMike_> are you in EU as well?
Apr 13 00:13:32 <philipp64|laptop> on my Geos, it reboots fast enough that TCP connections won't get dropped if I get back the same IP address... i.e. you have a 90 second window.
Apr 13 00:14:14 <cshore> philipp64|laptop: for change to make sense for OpenWRT it has to work for our main uses cases first
Apr 13 00:14:15 <philipp64|laptop> cshore: outside the current main focus, which is based on the current generation of platforms... it's a reasonably assumption that future platforms will be more capable, yes?
Apr 13 00:14:44 <solca> doing NAT on a router and then rebooting will break TCP anyways
Apr 13 00:14:45 <philipp64|laptop> cshore: lowest-common-denominator isn't exactly a spur to development now, is it? :-(
Apr 13 00:15:02 <philipp64|laptop> solca: not true.
Apr 13 00:15:37 <philipp64|laptop> as long as the outbound packet repunches the hole, before an inbound packet causes a unreachable...
Apr 13 00:15:40 <cshore> philipp64|laptop: being able to do embedded stuff in a true embedded system rather than a desktop that happens to be small is interesting for me
Apr 13 00:15:49 <solca> philipp64|laptop: unless you save iptables state too?
Apr 13 00:16:07 <philipp64|laptop> my Geode boards are 16cm on a side...
Apr 13 00:16:31 <cshore> philipp64|laptop: and are horribly expensive for embedded platforms
Apr 13 00:16:31 <solca> I know that freebsd have an option in it's IPF to dump state tracking
Apr 13 00:16:50 <philipp64|laptop> not exactly "desktop"... the next generation of embedded Atom boards from Kontron are the size of a deck of playing cards.
Apr 13 00:16:53 <cshore> philipp64|laptop: $20 router vs $400 x86 beast
Apr 13 00:16:59 <philipp64|laptop> $70
Apr 13 00:17:58 * solca thinks that saving conntrack state on flash would be horrible :)
Apr 13 00:18:47 <philipp64|laptop> solca: you don't necessarily need to dump conntrack state.
Apr 13 00:18:49 <cshore> philipp64|laptop: x86 = power sucking monsters even if the have a small form factor
Apr 13 00:18:58 <philipp64|laptop> cshore: < 5W
Apr 13 00:19:15 <philipp64|laptop> I play with this stuff every day...
Apr 13 00:19:40 <cshore> ok, how many ports, how much ram, does it have switch, what about wireless?
Apr 13 00:20:02 <solca> philipp64|laptop: unless I'm missing something if you don't preserve conntrack state between reboots all your TCP sessions would be b0rk3d
Apr 13 00:20:08 <philipp64|laptop> solca: some NAT implementations will leave the source port as is, if it isn't already in use.
Apr 13 00:20:16 <cshore> oh, and what flash does it have for $70 ?
Apr 13 00:20:56 <solca> philipp64|laptop: yea minimalistically it could work on simple cases but you were talking about the other cases right?
Apr 13 00:21:18 <philipp64|laptop> FRI has 2 Ethernet ports, 4GB NAND (production option), 512MB DDR2, 1 full mini-PCIe slot, 1 usb-only mini-PCIe slot... 3 mini USB connectors... LVDS as an option...
Apr 13 00:21:45 <philipp64|laptop> it also has a micro-SD slot.
Apr 13 00:21:59 <philipp64|laptop> (optionally a SIM slot instead)
Apr 13 00:22:26 <cshore> ok, so it's about the equivalent of RS Pro or so (maybe a bit better), and similar price once you include everything
Apr 13 00:22:38 <philipp64|laptop> solca: what simple cases are we talking about?
Apr 13 00:22:59 <philipp64|laptop> gotta go... HOA meeting.
Apr 13 00:23:00 <Acinonyx> philipp64|laptop: I think TCP connections will be droped no matter what implementation is used
Apr 13 00:23:06 <philipp64|laptop> back in 90 minutes...
Apr 13 00:23:11 <Acinonyx> UDP may survive though
Apr 13 00:23:21 <philipp64|laptop> Acinonyx: that's not been my experience.
Apr 13 00:23:50 <philipp64|laptop> that is to say, TCP connections have stayed up.
Apr 13 00:24:01 <cshore> philipp64|laptop: do you have a link?
Apr 13 00:24:29 <philipp64|laptop> remember: NAT uses a 5-tuple, so you only remap the source port if you have to to maintain uniqueness...  most of the time, you don't need to.
Apr 13 00:24:42 <solca> philipp64|laptop: nevermind... although it could be a good idea for "big" routers but if you preserve both DHCP lease info and conntrack state
Apr 13 00:24:52 <philipp64|laptop> cshore: there was one, but it got pulled down from the intel website.
Apr 13 00:25:17 <cshore> philipp64|laptop: ok, so where can you get boards like this?
Apr 13 00:25:57 <cshore> philipp64|laptop: if it really is what you say, this could be what I need
Apr 13 00:26:38 <cshore> $70 + a miniPCI FXS/FXO would be better than broadcrap
Apr 13 00:26:48 <philipp64|laptop> I'll see if I can find the Intel MM number and get back to you all.
Apr 13 00:27:17 <philipp64|laptop> cshore: especially if you have CODEC firmware that's only released in x86 binary format.
Apr 13 00:27:39 <philipp64|laptop> of course if that's the case, you might be constrained to using eglibc/glibc...
Apr 13 00:27:47 <philipp64|laptop> ok, HOA... biab.
Apr 13 00:28:29 <cshore> philipp64|laptop: the reason I find the price so hard to believe is that a broadcom board with 1FXS/1FXO and less power is $150 in high volume prices
Apr 13 00:29:15 <cshore> for $70 + $195 (FXS/FXO miniPCI) single unit price the geode would be way better
Apr 13 00:30:09 <Acinonyx> philipp64|laptop: IIRC, conntrack needs to see a SYN packet
Apr 13 00:30:53 <Acinonyx> if a SYN is not sent, then it will not NAT masquerade
Apr 13 00:36:10 <Acinonyx> gnight
Apr 13 01:35:45 <PrimasMike> cshore, hello
Apr 13 01:35:56 <cshore> PrimasMike: hello
Apr 13 01:36:24 <PrimasMike> been looking at the piping and redirecting in windows
Apr 13 01:36:33 <cshore> PrimasMike: yes?
Apr 13 01:36:54 <PrimasMike> not much luck yet, but was thinking back to the original direction
Apr 13 01:37:15 <PrimasMike> since this is only poc, what if we just used two routers
Apr 13 01:37:53 <PrimasMike> and the host router just forwarded the packet to the LAN port that we were sniffing
Apr 13 01:38:57 <cshore> I don't know as you can actually do that
Apr 13 01:39:19 <cshore> at least I wouldn't know how
Apr 13 01:39:36 <PrimasMike> is Xmff the best resource for this question?
Apr 13 01:39:46 <cshore> especially for non tcp/ip protocols
Apr 13 01:40:03 <cshore> I think he'll tell you what he's been trying to tell, which is that it won't work
Apr 13 01:40:37 <PrimasMike> I guess I didn't get that
Apr 13 01:41:07 <cshore> The whole reason for the pcap was that you can't do what you want
Apr 13 01:41:53 <cshore> you want to emit aribitrary tcp/ip packets from an interface
Apr 13 01:42:07 <cshore> which have not connection with the underlying ethernet
Apr 13 01:42:50 <cshore> and which don't fit the tcp/ip protocol rules for generation packets on a particular interface
Apr 13 01:42:51 <PrimasMike> actually I want to encapsulate traffic across a secure network
Apr 13 01:43:09 <cshore> yeah, but on the far side you want to do what I'm saying
Apr 13 01:43:20 <cshore> you want to emit the packets again on the other side
Apr 13 01:43:26 <russell--> PrimasMike: can you step way back and say wtf you are trying to do?
Apr 13 01:43:34 <PrimasMike> theoretically I just want to stuff the packet in the payload
Apr 13 01:43:42 <cshore> and I don't think the drivers are designed to allow that
Apr 13 01:44:33 <PrimasMike> in theory, I thought that it would work much like the wireless repeater code
Apr 13 01:44:39 <cshore> russell--: he wants to sniff packets on one port, send them over a remote link, and emit them on the other end so he can sniff them
Apr 13 01:44:51 <cshore> sorry not port
Apr 13 01:44:55 <cshore> interface
Apr 13 01:45:13 <neutronscott> kismet drone?
Apr 13 01:45:14 <russell--> and what is the requirement for the sniffer?
Apr 13 01:45:20 <PrimasMike> it should be the same process with the exception that I am using the WAN (VPN) instead of wifi
Apr 13 01:45:51 <russell--> i mean, what is the human interface?
Apr 13 01:46:08 <PrimasMike> russell, the sniffer has a proprietery decoder that decodes a protocol in the payload
Apr 13 01:46:11 <cshore> wifi is different than ethernet
Apr 13 01:46:29 <cshore> russell--: the sniffer on the remote side is ethertest on Windows
Apr 13 01:46:30 <PrimasMike> Layer 1
Apr 13 01:46:58 <PrimasMike> ys
Apr 13 01:47:00 <PrimasMike> yes
Apr 13 01:47:00 <russell--> how does this involve openwrt?
Apr 13 01:47:21 <PrimasMike> was trying to use the VPN client to secure the transport
Apr 13 01:47:42 <PrimasMike> and possibly modify the code from the wifi repeater
Apr 13 01:47:53 <PrimasMike> that is how this started on "paper"
Apr 13 01:47:55 <cshore> the packets coming in on the router, get sent over VPN, and and got to a receiver
Apr 13 01:48:19 <cshore> the router runs OpenWRT
Apr 13 01:48:48 <russell--> what is ethertest?
Apr 13 01:49:16 <cshore> russell--: a windows wireshark type thing that runs the proprietary decoder he needs
Apr 13 01:50:33 * russell-- knows nothing about ethertest ... what are its interfaces?
Apr 13 01:50:56 <cshore> pcap file, or sniffing packets on an interface and I have no idea what else
Apr 13 01:51:00 <PrimasMike> Ethertest is a standard sniffer that works like the rest
Apr 13 01:51:17 <cshore> russell--: but they want real time, not spooled
Apr 13 01:51:23 <PrimasMike> bluetooth, serial, ethernet, etc
Apr 13 01:51:27 <russell--> standard sniffers are open-source!
Apr 13 01:52:08 <PrimasMike> these guys have some proprietary ways of writing decoders and DLLs
Apr 13 01:52:12 <russell--> i don't understand why closed source people ask open source people to solve their problems
Apr 13 01:52:38 <PrimasMike> we already invested in this for now, and will be changing it in the future
Apr 13 01:52:55 <russell--> just saying, i have no idea how to solve that
Apr 13 01:53:01 <PrimasMike> the answer is that all systems must interoperate
Apr 13 01:53:26 <PrimasMike> some are open and others are Microsoft... lol
Apr 13 01:54:21 <PrimasMike> BTW, this is not their problem.  this is our solution for customers which uses their product as one piece of the solution.
Apr 13 01:54:46 <PrimasMike> I am trying to get openwrt as another piece to install at the customer site
Apr 13 01:54:56 <philipp64|laptop> damn... wrong night for the HOA.
Apr 13 01:55:41 <PrimasMike> guys if I am interrupting something, I will stop
Apr 13 01:55:52 <cshore> PrimasMike: and you don't like the answer xMff and I have told you and keep trying to do something that we keep telling you can be done because it sounds simpler but is really not
Apr 13 01:56:00 <cshore> *can't
Apr 13 01:56:04 <philipp64|laptop> cshore: it might be part of Intel's plan for global world domination to have a loss-leader...
Apr 13 01:56:16 <cshore> philipp64|laptop: that would make sense
Apr 13 01:56:17 <philipp64|laptop> can't rule out the possibility.
Apr 13 01:56:39 <cshore> philipp64|laptop: or the price just for the board, not including P/S, case, etc, etc
Apr 13 01:57:26 <PrimasMike> cshore, I am not dismissing what was suggested.  On the contrary, I was researching it all day
Apr 13 01:58:07 <PrimasMike> I couldn't find the piping from a file to ndis
Apr 13 01:58:26 <PrimasMike> I couldn't find the fifo input for ethertest
Apr 13 01:59:02 <cshore> PrimasMike: huh, you want to pipe info from stdin to a named pipe, have ethertest read the named pipe like a file
Apr 13 01:59:02 <PrimasMike> I couldn't find the pcap file input for ethertest
Apr 13 01:59:17 <gzanan> Does openwrt not support ai_family?
Apr 13 01:59:34 <gzanan> Exception: [SocketCore.cc:308] errorCode=1 Failed to bind a socket, cause: ai_family not supported
Apr 13 02:00:10 <cshore> PrimasMike: but the docs say it can do it?
Apr 13 02:00:45 <PrimasMike> sorry, I didn't find that file
Apr 13 02:02:26 <PrimasMike> was that a question to me or did you see this in the doc?
Apr 13 02:03:01 <cshore> PrimasMike: that was a question to you
Apr 13 02:03:13 <cshore> PrimasMike: you said you read it could do pcap
Apr 13 02:03:57 <PrimasMike> they have the ability to read capture files
Apr 13 02:04:14 <PrimasMike> .cfa, wireshark, etc.
Apr 13 02:04:18 <PrimasMike> but this is not real time
Apr 13 02:04:41 <PrimasMike> so I was thinking of piping the fifo file to ndis
Apr 13 02:04:43 <cshore> can you try reading the named pipe like a file
Apr 13 02:05:06 <cshore> that's what you do with wireshark to get the real-time pcap file read/write
Apr 13 02:05:07 <PrimasMike> we will be trying that when PrimasRich wakes up
Apr 13 02:06:14 <PrimasMike> yea, but in ethertest, they have a UI that lets you select file or ndis
Apr 13 02:06:40 <PrimasMike> I am not sure they designed it to accept a fifo type file as real time
Apr 13 02:07:11 <cshore> isn't ndis the windows ethernet driver thingy....I don't think that helps you
Apr 13 02:07:40 <PrimasMike> yes
Apr 13 02:08:06 <PrimasMike> that is the generic name for the network driver class
Apr 13 02:09:12 <cshore> PrimasMike: you may need to write a Win32-TAP based driver that takes a pcap file and emits packets
Apr 13 02:10:06 <cshore> PrimasMike: I think that's what you wanted to do with the second router, but you can't do it with physical hardware
Apr 13 02:10:19 <cshore> PrimasMike: but with the virtual TAP driver you might be able to
Apr 13 02:10:50 <cshore> PrimasMike: *pcap file = pcap stream
Apr 13 02:10:59 <PrimasMike> ok
Apr 13 02:11:17 <cshore> PrimasMike: that's a lot harder than the FIFO solution if it works
Apr 13 02:11:30 <cshore> if the FIFO doesn't work then you don't have much choice I guess
Apr 13 02:12:50 <PrimasMike> was my idea of using the wireless repeater code that far off?
Apr 13 02:13:49 <cshore> PrimasMike: I don't think that will work....you need the TAP driver to be on the ethertest box otherwise you won't get unalderated packets
Apr 13 02:14:21 <PrimasMike> what if the TAP was on the host router?
Apr 13 02:14:52 <cshore> you mean the router next to the ethertest box?
Apr 13 02:15:02 <PrimasMike> y
Apr 13 02:15:22 <PrimasMike> just creat a tunnel
Apr 13 02:15:41 <cshore> PrimasMike: doesn't help you....the packets won't route out to ethertest interface
Apr 13 02:15:57 <cshore> at least not unalderated
Apr 13 02:16:06 <cshore> PrimasMike: you need them unchanged
Apr 13 02:16:19 <cshore> PrimasMike: means not getting routed through anything else
Apr 13 02:16:57 <cshore> PrimasMike: assuming they didn't just results in unreachable errors and such
Apr 13 02:17:21 <PrimasMike> we could probably handle MAC changes
Apr 13 02:17:28 <PrimasMike> but have to think...
Apr 13 02:28:26 <PrimasMike> cshore
Apr 13 02:29:07 <PrimasMike> I think we could handle the packet manipulation when routed if we use the VPN
Apr 13 02:29:25 <PrimasMike> because the VPN would give us the unique identifier that we need
Apr 13 02:30:10 <PrimasMike> the payload of the original packet is what is important
Apr 13 02:31:26 <cshore> PrimasMike: then maybe use relayd to get the packet to an interface where it can be seen by the sniffer
Apr 13 02:38:49 <PrimasMike> ok
Apr 13 02:39:01 <PrimasMike> is this on the router box as well as tcpdump?
**** ENDING LOGGING AT Wed Apr 13 02:59:57 2011