OpenWrt Forum Archive

Topic: Custom x86 Image (NO LONGER MAINTAINED)

The content of this topic has been archived between 6 Sep 2015 and 6 May 2018. Unfortunately there are posts – most likely complete pages – missing.

Alex Atkin UK wrote:

I just wanted to feedback that those changes I made to the ppp-up script DID work.

I have both simulated (pulling the ethernet cable out) and seen a real-world connection loss of the PPP link, and it comes back up quickly without any fuss.

I have also had traffic monitoring running on the router for a while now, that too seems to be working flawlessly.

I'm almost nervous at the idea of switching from the test build to a newer one, its working so smoothly.

Can you post the changes you made to the various scripts so I can look at integrating things into the build?

I'm still stuck on a problem with shadow.  Hopefully soon...

Sorry for the delay, its been working so well I lost track.

I simply changed line 56 in /lib/netifd/proto/ppp.sh from:
                $demand maxfail 1 \
to:
                $demand maxfail 10 holdoff 0 \

Basically it tells pppd to retry 10 times before quitting (as for some reason my connection always failed the first attempt so was in an endless loop on the default setting) and holdoff 0 tells pppd to immediately retry the connection upon failure rather than waiting. 

No doubt other values would work too, but its proven to be perfectly stable for my connection so I see no reason to fiddle with it further.

Alex Atkin UK wrote:

Sorry for the delay, its been working so well I lost track.

No worries, I've been swamped very bad at work (50-60 work weeks for 6 weeks running) and my personal life.  I've been in a similar boat: it works well enough for my needs that I forgot how long it has been since a build was pushed.

I did try another build today but it died again on shadow.  Thinking I may go ahead and get a chroot online to ensure builds are in a bit better controlled environment.  Also, I may be switching off to following the beta / release tags going forward now that it looks like attitude adjustment is getting close.  I figure most people will want to be on a stable core long-term.

As soon as I have everything back in order I'll be posting back with updated builds.

Alex Atkin UK wrote:

I simply changed line 56 in /lib/netifd/proto/ppp.sh from:
                $demand maxfail 1 \
to:
                $demand maxfail 10 holdoff 0 \

Basically it tells pppd to retry 10 times before quitting (as for some reason my connection always failed the first attempt so was in an endless loop on the default setting) and holdoff 0 tells pppd to immediately retry the connection upon failure rather than waiting. 

No doubt other values would work too, but its proven to be perfectly stable for my connection so I see no reason to fiddle with it further.

Good to know.  I've been using the default values myself and it takes <= 5 minutes for my pppoe connection to kick free and bring everything online.  I may have to look at fiddling with the values as soon as I can get a build working again...

My connection seems to come up VERY fast. 

I wouldn't be surprised if its only 30 seconds to boot the whole router and be online, although I haven't timed it so don't hold me to that.  I certainly would think its under a minute.

Alex Atkin UK wrote:

My connection seems to come up VERY fast. 

I wouldn't be surprised if its only 30 seconds to boot the whole router and be online, although I haven't timed it so don't hold me to that.  I certainly would think its under a minute.

I will definitely poke around my settings then.  The faster the better smile

Now that I have said that, my DSL dropped last night and it seemed to take minutes for the PPPoE link to come back up.

Although perhaps that was related to the maxfail 10 setting and as such more related to how long it took for the connection to be considered dropped?  I might try reducing the value to 5.

Its just so rare for the DSL sync to drop, when I forced it to drop the PPP link by unplugging ethernet it seemed to come back up quickly.  I suppose it makes sense that the whole ethernet link going down is more definitive than the DSL dropping which would just show as packet loss.

@Alex thanks for the ping today.

I've synced up the attitude adjustment sources and applied my various patches and such.  I just kicked off a build.  Hopefully I'll have something built within the next 12 hours or so (takes awhile to build....).  I am not building against the truck anymore.  Given 12.09 is rc1 I want to target the main releases branch.

My expectation is to get the USB networking setup for you while making sure any missing packages get re-installed.  It looks like there was some mild shuffle in the last month or so.



Edit 1: Dangit.... Dies out on shadow again.  I noticed there is now an attitude adjustment branch for the packages tree as well.  I am in the process of syncing that all up and I'll be re-trying a build.  Hopefully I can get through a build today.

(Last edited by mcrosson on 4 Dec 2012, 18:59)

Aaaaand, my power went out 1/2 way through my build.  Working on getting it back in order.  I managed to get everything switched over to the attitude adjustment trees and the kernel has as many USB network / wifi adapters as I could find enabled.  I will be re-running the build as soon as the packages are down downloading (cleaned my build root without backing up package downloads....)

A short breakdown of progress thus far:

- Turned on USB networking drivers
- Switched to attitude adjustment branch instead of trunk (this will be rc1+ for version)
- Switched to 12.09 packages branches (looks to be what comes with attitude adjustment)
- Switched to luci 0.11 branch (looks to be what comes with attitude adjustment)
- Updated various bits and pieces to match development's since the last build
- All tree's, changes, etc pushed to bitbucket as I went along with the builds

I trust you pulled in IMQ support too?

Alex Atkin UK wrote:

I trust you pulled in IMQ support too?

The IMQ support was part of my local patches that were applied pre-build.  The only thing I did was reset to use the attitude adjustment repo's which is what I was developing against.  The latest trunk sources are semi-broken in areas and I thought it would be wise to aim at the stable tree's rather than the bleeding edge.

New build is up on the nusku.net mirror.  Box mirror should be up within a couple hours. 

The build should include what you needed.  I've not had a chance to try out the build in virtualbox yet but I would wager it's working.  Definitely backup your config / tweaks / filesystem before applying an update per usual.

Switched to the new build, everything looking good so far.  It picked up my cheap USB LAN adapter and assigned it as eth2.

I still had to edit  /lib/netifd/proto/ppp.sh from:

                $demand maxfail 1 \
to:
                $demand maxfail 5 holdoff 0 \

Before PPPoE would connect to my ISP.

I have debugging enabled now though, I see clearly that my ISP just seems to take AGES to respond to the PPPoE connection request:

Dec  9 20:29:22 Router daemon.debug pppd[7841]: Send PPPOE Discovery V1T1 PADI session 0x0 length 12
Dec  9 20:29:22 Router daemon.debug pppd[7841]:  dst ff:ff:ff:ff:ff:ff  src ##:##:##:7c:32:58
Dec  9 20:29:22 Router daemon.debug pppd[7841]:  [service-name] [host-uniq  a1 1e 00 00]
Dec  9 20:29:23 Router kern.info kernel: [  524.112132] e1000e: eth0 NIC Link is Up 100 Mbps Full Duplex, Flow Control: Rx/Tx
Dec  9 20:29:23 Router kern.info kernel: [  524.112738] ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
Dec  9 20:29:27 Router daemon.debug pppd[7841]: Send PPPOE Discovery V1T1 PADI session 0x0 length 12
Dec  9 20:29:27 Router daemon.debug pppd[7841]:  dst ff:ff:ff:ff:ff:ff  src ##:##:##:7c:32:58
Dec  9 20:29:27 Router daemon.debug pppd[7841]:  [service-name] [host-uniq  a1 1e 00 00]
Dec  9 20:29:32 Router daemon.debug pppd[7841]: Send PPPOE Discovery V1T1 PADI session 0x0 length 12
Dec  9 20:29:32 Router daemon.debug pppd[7841]:  dst ff:ff:ff:ff:ff:ff  src ##:##:##:7c:32:58
Dec  9 20:29:32 Router daemon.debug pppd[7841]:  [service-name] [host-uniq  a1 1e 00 00]
Dec  9 20:29:37 Router daemon.warn pppd[7841]: Timeout waiting for PADO packets
Dec  9 20:29:37 Router daemon.err pppd[7841]: Unable to complete PPPoE Discovery
Dec  9 20:29:37 Router daemon.debug pppd[7841]: Send PPPOE Discovery V1T1 PADI session 0x0 length 12
Dec  9 20:29:37 Router daemon.debug pppd[7841]:  dst ff:ff:ff:ff:ff:ff  src ##:##:##:7c:32:58
Dec  9 20:29:37 Router daemon.debug pppd[7841]:  [service-name] [host-uniq  a1 1e 00 00]
Dec  9 20:29:42 Router daemon.debug pppd[7841]: Send PPPOE Discovery V1T1 PADI session 0x0 length 12
Dec  9 20:29:42 Router daemon.debug pppd[7841]:  dst ff:ff:ff:ff:ff:ff  src ##:##:##:7c:32:58
Dec  9 20:29:42 Router daemon.debug pppd[7841]:  [service-name] [host-uniq  a1 1e 00 00]
Dec  9 20:29:42 Router daemon.debug pppd[7841]: Recv PPPOE Discovery V1T1 PADO session 0x0 length 55
Dec  9 20:29:42 Router daemon.debug pppd[7841]:  dst ##:##:##:7c:32:58  src ##:##:##:22:a0:29
Dec  9 20:29:42 Router daemon.debug pppd[7841]:  [host-uniq  a1 1e 00 00] [service-name] [AC-name ac3.dr.originbroadband.net] [service-name origin-dr]
Dec  9 20:29:42 Router daemon.debug pppd[7841]: Send PPPOE Discovery V1T1 PADR session 0x0 length 12
Dec  9 20:29:42 Router daemon.debug pppd[7841]:  dst ##:##:##:22:a0:29  src ##:##:##:7c:32:58
Dec  9 20:29:42 Router daemon.debug pppd[7841]:  [service-name] [host-uniq  a1 1e 00 00]
Dec  9 20:29:42 Router daemon.debug pppd[7841]: Recv PPPOE Discovery V1T1 PADO session 0x0 length 55
Dec  9 20:29:42 Router daemon.debug pppd[7841]:  dst ##:##:##:7c:32:58  src ##:##:##:22:9f:f5
Dec  9 20:29:42 Router daemon.debug pppd[7841]:  [host-uniq  a1 1e 00 00] [service-name] [AC-name ac1.dr.originbroadband.net] [service-name origin-dr]
Dec  9 20:29:42 Router daemon.debug pppd[7841]: Recv PPPOE Discovery V1T1 PADO session 0x0 length 55
Dec  9 20:29:42 Router daemon.debug pppd[7841]:  dst ##:##:##:7c:32:58  src ##:##:##:20:9a:7c
Dec  9 20:29:42 Router daemon.debug pppd[7841]:  [host-uniq  a1 1e 00 00] [service-name] [AC-name ac4.dr.originbroadband.net] [service-name origin-dr]
Dec  9 20:29:42 Router daemon.debug pppd[7841]: Recv PPPOE Discovery V1T1 PADO session 0x0 length 55
Dec  9 20:29:42 Router daemon.debug pppd[7841]:  dst ##:##:##:7c:32:58  src ##:##:##:22:a0:1c
Dec  9 20:29:42 Router daemon.debug pppd[7841]:  [host-uniq  a1 1e 00 00] [service-name] [AC-name ac2.dr.originbroadband.net] [service-name origin-dr]
Dec  9 20:29:42 Router daemon.debug pppd[7841]: Recv PPPOE Discovery V1T1 PADS session 0x3c18 length 12
Dec  9 20:29:42 Router daemon.debug pppd[7841]:  dst ##:##:##:7c:32:58  src ##:##:##:22:a0:29
Dec  9 20:29:42 Router daemon.debug pppd[7841]:  [host-uniq  a1 1e 00 00] [service-name]
Dec  9 20:29:42 Router daemon.debug pppd[7841]: PADS: Service-Name: ''
Dec  9 20:29:42 Router daemon.info pppd[7841]: PPP session is 15384
Dec  9 20:29:42 Router daemon.warn pppd[7841]: Connected to ##:##:##:22:a0:29 via interface eth0
Alex Atkin UK wrote:

Switched to the new build, everything looking good so far.  It picked up my cheap USB LAN adapter and assigned it as eth2.

I still had to edit  /lib/netifd/proto/ppp.sh from:

                $demand maxfail 1 \
to:
                $demand maxfail 5 holdoff 0 \

Before PPPoE would connect to my ISP.

I have debugging enabled now though, I see clearly that my ISP just seems to take AGES to respond to the PPPoE connection request:

I haven't tried the new build yet on my live box.  I am hoping to get it upgraded this weekend.  Does PPPoE eventually connect for you at least?  I've been having long connection times via PPPoE on an earlier beta build myself.

With that modification, as you can see from above it takes about 20 seconds for PPPoE to connect.  A lot longer than I would expect, but its tolerable.

Alex Atkin UK wrote:

With that modification, as you can see from above it takes about 20 seconds for PPPoE to connect.  A lot longer than I would expect, but its tolerable.

I'll make it a point to keep an eye out for updates once a week or so and get new builds up.  Hopefully it is a known problem and gets addressed in the sources at some point soon.

My only motivation for upgrading to the current build was to get the USB Ethernet support.  I will likely not upgrade again for a while unless I discover a serious problem with the current build or a major bugfix in a new one.

I'm almost certain the problem with PPPoE taking a while to connect is specific to my connection, as you can see its 14 seconds before pppd gets a response from my ISP which is why I have to patch the ppp.sh script or it doesn't connect at all.  So unless you too are getting the "Timeout waiting for PADO packets" messages in syslog then its likely a different issue.

Alex Atkin UK wrote:

My only motivation for upgrading to the current build was to get the USB Ethernet support.  I will likely not upgrade again for a while unless I discover a serious problem with the current build or a major bugfix in a new one.

Sounds good.  When the next build is run I'll be posting back so anyone watching the thread knows there is an update.

Hello All. I Would love to test your version. I have a JetWay JNC9MGL-525 Intel Atom D525 (1.8GHz, Dual-Core) It have dual nic so you don't have to fight with usb adapters. It have none wlan adapter but I have a 1 x Mini PCIe port so I suppose it's possible to use something like this: http://www.newegg.com/Product/Product.a … ini%20PCIe

I'm going to test your build. Happy Hollidays!

seebaastian wrote:

It have none wlan adapter but I have a 1 x Mini PCIe port so I suppose it's possible to use something like this: http://www.newegg.com/Product/Product.a … ini%20PCIe

From what I see in your link I think it should work.  I have enabled most/all of the Intel wireless drivers in the build.  The only trick would be: does that card support AP mode?

seebaastian wrote:

I'm going to test your build.

Let me know how it goes, the build should be in good working order at this juncture.

Be careful, its generally only specific Atheros and Broadcom cards which support Access Point mode.  Pretty sure none of the Intel WiFi chipsets have support for it.

The compatible Atheros chipsets should be:

AR5008:
    AR5418+AR5133 (>= 2.6.27) AR5418 = DB 11n PCIe, AR5133 = 3x3 DB 11n
    AR5416+AR5133 (>= 2.6.27) AR5416 = DB 11n PCI
    AR5416+AR2133 (>= 2.6.27) AR2133 = 3x3 SB 11n

AR9001:
    AR9160 (>= 2.6.27) DB 11n
    AR9102 (>= 2.6.30, AHB) 2x2 SB 11n
    AR9103 (>= 2.6.30, AHB) 3x3 SB 11n

AR9002:
    AR9220 (>= 2.6.27, an AR9280 card over PCI) 2x2 DB 11n PCI
    AR9280 (>= 2.6.27) 2x2 DB 11n PCIe
    AR9281 (>= 2.6.27) 2x2 SB 11n PCIe
    AR9285 (>= 2.6.29) 1x1 SB 11n PCIe
    AR9287 (>= 2.6.32) 2x2 SB 11n PCIe

AR9003:
    AR9380 (>= 2.6.36) 3x3 DB 11n PCIe
    AR9382 (>= 2.6.36) 2x2 DB 11n PCIe

AR9004:
    AR9485 (>= 2.6.39) 1x1 SB 11n PCIe
    AR9462 (>= 3.2) 2x2 DB 11n

I highly recommend a 2x2 or 3x3 card, basically a 1x1 can do 150Mbit, 2x2 300Mbit and 3x3 450Mbit.  Personally I am using one of these in 5Ghz mode, but it works equally well in 2.4Ghz (normal WiFi) mode too.

As for why I use USB network adapters, that is so that I do not waste gigabit ports in my network switch with low usage devices. 

If you bridge several ethernet adapters together then it effectively becomes an ethernet switch.  Yes it takes some of the CPU power, but as the Atom has plenty to spare and I am only using it for low bandwidth devices (one of which is the second port of my VDSL modem so I can telnet in and bring up the line stats, etc), its far better than wasting a full blown Gigabit port on the switch. 

Also if you are only a couple of ethernet ports short, its a lot cheaper (about $3 a port if you get them from China via eBay) than having to upgrade an 8 port switch to 16 ports, which I would have to do as generally you are only supposed to have three unmanaged switches on an ethernet network.  I already have three as its two routers (for two other WiFi networks) and an 8 port Gigabit switch.  Obviously the routers I cannot swap out, the best you ever get is 5 ports on any router, so this was the only practical option.

Hello Guys,

I've tested your version and It rocks! Great Job! keep working. Nevertheless I've found something that it's important. The VPNC package is missing! I want to build that but to be honest my skills are far away to that. It would be awesome to have that package!. In my test I used a USB drive compatible with a dm9601.

thanks a lot!

Sebastián

(Last edited by seebaastian on 11 Jan 2013, 23:53)

seebaastian wrote:

Nevertheless I've found something that it's important. The VPNC package is missing! I want to build that but to be honest my skills are far away to that.

I'll take a look and see if I can include it in the next build I run.  Keep an eye on the thread and I'll post back once a new build gets published.


Edit 1: Turns out there was less to the code sync than I had expected.  Running a new build now.  Attitude Adjustment rc1 + fixes from SVN, added VPNC as a package to the build.

Should be up within the next 48 hours or so.

(Last edited by mcrosson on 13 Jan 2013, 08:05)

mcrosson wrote:

I'll take a look and see if I can include it in the next build I run.  Keep an eye on the thread and I'll post back once a new build gets published.


Edit 1: Turns out there was less to the code sync than I had expected.  Running a new build now.  Attitude Adjustment rc1 + fixes from SVN, added VPNC as a package to the build.

Should be up within the next 48 hours or so.


Thanks A lot man! I'm going to test! I try to build one my self but for some reason my build fail...

seebaastian wrote:

Thanks A lot man! I'm going to test! I try to build one my self but for some reason my build fail...

New build is mirrored, includes the VPNC package as well as a sync with upstream.  r55d4b4f3b34171cdeb6124ed2b14c56bea970b9c is the release directory.

If you want to build my release you'll need to use the helper scripts under bin in the master branch.  You will want to look at the pre_process, patch, build and publish scripts.  You'll also want the openwrt-attitude_adjustment and feed_thing-blah branches for the feeds.  I have the master branch cloned to one location and the openwrt-attitude_adjustment branch at another location so I can run the helper scripts from master against the openwrt-attitude_adjustment sources.

I found a problem in my build, I cannot login from tty1.  It just reports login incorrect even though its the identical information I use from SSH which works fine.

Any ideas?