I upgraded from r33203, which I installed on or around the 2012-08-17.  This worked very well.

I updated on the 2012-08-30 to r33275 and suddenly I cannot access my SMTPS or IMAP servers from the internet.

I will switch back to the r33203 version and see what happens.

TTYL

Between those versions there should be nothing special in the trunk:
https://dev.openwrt.org/changeset?new=3 … 3203@trunk
https://dev.openwrt.org/changeset?new=3 … 3@packages

I think that I made mainly some 3G/USB related package selection changes to my own code in that time.
The only other thing is compiling dhcpv6 support into dnsmasq, the DHCP service in Openwrt. But that should have no impact on ipv4 traffic and would require manual config to turn dhcpv6 on.

Hi, well I switched back to r33203 and everything is working again.

From my perspective, it would appear that port 993 (IMAPS) was blocked when I used r33275. There may also have been a problem with port 587 (SMTP submit (SMTPS)), however this may have been more a user perception problem than a real one, I cannot be 100% sure on this one.

So what do we need do to determine what broke!

(Last edited by zzz2002 on 5 Sep 2012, 15:10)

I tested setting a server to port 993 in a a LAN host behind NAT, and after configuring the port-forward, the incoming traffic reached the server quite normally. So, I wonder if that may have been something in your config.

I do not use NAT for my servers they all have fixed public IPs. n.n.n.177/28. I assume that because of this I did not need port forwarding, at least I had not needed it in the past.

I'm using 33311 with port 993 and no issues here. Have you tried that newest build?

I can't understand why you think you don't need port forwarding. NAT only protects outgoing connections.

I have not needed it to date, and it seems a llittle redundant to port forward something like 99.99.99.178 port 993 to 99.99.99.178 port 993.

My network config

config interface 'loopback'
    option ifname 'lo'
    option proto 'static'
    option ipaddr '127.0.0.1'
    option netmask '255.0.0.0'

config interface 'servers'
    option proto 'static'
    option ifname 'eth0.2'
    option ipaddr '99.99.99.177'
    option netmask '255.255.255.240'
    option ip6addr '2001:dead:dead:10::1/64'

config interface 'guest'
    option ifname 'wlan0-1'
    option proto 'static'
    option ipaddr '192.168.20.1'
    option netmask '255.255.255.240'
    option ip6addr '2001:dead:dead:20::1/64'

config interface 'lan'
    option proto 'static'
    option netmask '255.255.255.224'
    option ip6addr '2001:dead:dead:30::1/64'
    option type 'bridge'
    option _orig_ifname 'eth0.1'
    option _orig_bridge 'true'
    option ifname 'eth0.1'
    option ipaddr '192.168.30.1'

config interface 'wan'
    option ifname 'eth1'
    option password 'password'
    option username 'me@someisp.net'
    option proto 'pppoe'

config interface 'henet'
    option proto '6in4'
    option peeraddr '88.88.88.58'
    option ip6addr '2001:dead:dead::2/64'
    option tunnelid 'tunnelid'
    option username 'he-net-userid'
    option password 'password'

config switch
    option name 'rtl8366s'
    option reset '1'
    option enable_vlan '1'
    option blinkrate '2'
    option enable_vlan4k '1'
    option max_length '3'

config switch_vlan
    option device 'rtl8366s'
    option vlan '1'
    option ports '0 1 5t'

config switch_vlan
    option device 'rtl8366s'
    option vlan '2'
    option ports '2 3 5t'

config switch_port
    option device 'rtl8366s'
    option port '1'
    option led '6'

config switch_port
    option device 'rtl8366s'
    option port '2'
    option led '9'

config switch_port
    option device 'rtl8366s'
    option port '5'
    option led '2'

and my firewall

config rule
    option target 'ACCEPT'
    option name '6in4'
    option family 'ipv4'
    option proto '41'
    option src 'wan'

config rule
    option target 'ACCEPT'
    option name 'ICMPv6'
    option family 'ipv6'
    option proto 'icmp'
    list icmp_type 'router-solicitation'
    list icmp_type 'router-advertisement'
    list icmp_type 'neighbour-solicitation'
    list icmp_type 'neighbour-advertisement'
    option src 'servers'

config rule
    option target 'ACCEPT'
    option proto 'udp'
    option dest_port '53 67 123'
    option name 'Input'
    option src 'guest'

config rule
    option target 'ACCEPT'
    option dest_port '22 23 80'
    option proto 'tcp'
    option name 'Router-Admin-Access'
    option src 'lan'

config rule
    option target 'ACCEPT'
    option name 'DNS'
    option proto 'udp'
    option dest_port '53'
    option src '*'
    option dest 'servers'

config rule
    option target 'ACCEPT'
    option dest_port '53'
    option proto 'udp'
    option name 'DNS'
    option dest 'wan'
    option src 'servers'

config rule
    option target 'ACCEPT'
    option dest_port '80 443'
    option proto 'tcp'
    option name 'HTTP(S)'
    option src '*'
    option dest 'wan'

config rule
    option target 'ACCEPT'
    option name 'HTTP(S)'
    option proto 'tcp'
    option dest_port '80 443'
    option src '*'
    option dest 'servers'

config rule
    option target 'ACCEPT'
    option proto 'tcp'
    option dest_port '587 993'
    option name 'eMail - server2'
    option src 'wan'
    option dest 'servers'

config rule
    option target 'ACCEPT'
    option proto 'tcp'
    option dest_port '587 993'
    option name 'eMail'
    option src 'lan'
    option dest 'servers'

config rule
    option target 'ACCEPT'
    option name 'SMTP'
    option proto 'tcp'
    option dest_port '25'
    option src 'wan'
    option dest 'servers'

config rule
    option target 'ACCEPT'
    option proto 'tcp'
    option dest_port '25'
    option name 'SMTP'
    option dest 'wan'
    option src 'servers'

config rule
    option target 'ACCEPT'
    option name 'NTP'
    option dest_port '123'
    option proto 'udp'
    option dest 'wan'
    option src 'servers'

config rule
    option target 'ACCEPT'
    option proto 'tcp'
    option dest_port '993'
    option name 'IMAPS'
    option dest 'servers'
    option src 'guest'

config rule
    option target 'ACCEPT'
    option proto 'udp'
    option name 'Input'
    option dest_port '53 67 123 1900'
    option src 'lan'

config rule
    option target 'ACCEPT'
    option proto 'tcp'
    option dest_port '22 23'
    option name 'Server-Admin-Access'
    option src 'lan'
    option dest 'servers'

config defaults
    option syn_flood '1'
    option drop_invalid '1'
    option input 'DROP'
    option output 'DROP'
    option forward 'DROP'

config zone
    option masq '1'
    option mtu_fix '1'
    list masq_src '!servers'
    list masq_dest '!servers'
    option conntrack '1'
    option forward 'DROP'
    option input 'DROP'
    option output 'ACCEPT'
    option name 'wan'
    option network 'henet wan'

config zone
    option network 'lan'
    option output 'ACCEPT'
    option input 'ACCEPT'
    option forward 'DROP'
    option name 'lan'

config zone
    option output 'ACCEPT'
    option network 'servers'
    option forward 'DROP'
    option input 'DROP'
    option name 'servers'

config zone
    option output 'ACCEPT'
    option network 'guest'
    option forward 'DROP'
    option input 'ACCEPT'
    option name 'guest'

config include
    option path '/etc/firewall.user'

config forwarding
    option dest 'wan'
    option src 'guest'

config forwarding
    option dest 'wan'
    option src 'lan'

config forwarding
    option dest 'servers'
    option src 'lan'

You're using a firewall rule and a network forwarding target, which is a bit different from my config. But ... are both rules not working, i.e. is it your lan, wan or both that need the port forward?

taking a look at the code I submitted I see that I have a duplicate firewall rule. Looking back in the admin logs I see that at one time access to ports 587 & 993 was restricted to traffic routed to the mail servers only, ie there was an allowed address line that appears to have been removed. however, as this was something like 5 months ago and everything worked without it I am not sure that this is the problem.

Everything from inside the "lan" seems to be working , no problems that I am aware of.

The problem is that if I try to get my email while I am on the road. It would appear that I can not get from the WAN to the Servers.

Patch for that has been added with r33357, so I have dropped my own patch for the issue.

Trunk 33379: usb-modeswitch updated to 1.2.4 (it is not yet in the main Openwrt repository)

I have removed the haveged package that I used for increasing hardware entropy for /dev/random, as r33559 finally declares bug #9631 closed and increased kernel support for entropy.
https://dev.openwrt.org/changeset/33559
https://dev.openwrt.org/ticket/9631

Attitude Adjustment 12.09 release branch has been created yesterday in the SVN source code repository. As of today, the AA source code is identical to Trunk except the version ID strings.

As long as AA and Trunk are identical, I will probably build only AA. Trunk's kernel version will probably be bumped up rather soon, as Linux 3.6 has been released by now. After that change it will make more sense to build also new Trunk versions. Trunk has not yet been renamed for the next release, but that will probably be done soon.

Backfire 10.03.SVN r33275 will remain as my final Backfire build.

Current versions:
Attitude Adjustment 12.09 beta2 SVN r33629  (http://koti.welho.com/hnyman1/Openwrt/a … 012-10-06/)
(Trunk SVN r33618, not yet updated after the Trunk / Attitude Adjustment separation)

I have wondered since ages, where does the initial date & time after a firmware flash come from. For me that date has been 09 Sep 2011 for a while. I thought that it might be something related to u-boot or Linux kernel or something in the core Openwrt system and have searched for documentation. But I couldn't figure it out :-(

Then after the Attitude Adjustment branch was created two days ago and I built the first firmware with that, I noticed that the router's initial system date was now 05 Oct 2012. But there was supposedly no difference in the source code between trunk and AA branch, or between Luci trunk and Luci 0.11. What the hell? Where is the new date coming from?

I figured out that is must be somehow related to the timestamp of some file in my build host, as the date (and time) matched the time when I had set up the new AA and Luci 0.11 sources. I reverted to brute force and recursively listed all files in my buildhost and looked for a date/time match between the initial system date and files there. Finally I found a file called "luci_fixtime" in Luci sources (/luci/trunk/modules/admin-core/root/etc/init.d/luci_fixtime). That file's timestamp matched the "inital system date" respectively in my trunk and in AA. So that must be it.
http://luci.subsignal.org/trac/browser/ … ci_fixtime

It gets copied to /etc/init.d/luci_fixtime in the final firmware.

That file is used to store the current date & time to in a warm reboot. But initially it uses its own date, coming directly from the build host. That part is not documented anywhere to my knowledge, but after finding the file and reading it, it can be figured out. Changing the date/time (e.g. with "touch") enables me to set the initial date & time for a firmware.

The file had last time been modified in SVN on 8 Sep 2011 and I had svn updated it on 9 Sep 2011, so 9 Sep 2011 was the initial date for my trunk.

That file is only in the full Luci sources, not in the contrib/package/luci set included in a normal build. But as I have the full Luci source in my local repository, I can touch the file there (/luci/branches/luci-0.11/modules/admin-core/root/etc/init.d/luci_fixtime).

I have now added a line to my build script that touches the file just before "make world" and sets the initial system date to the build hour. As I use the same script for trunk and AA, I wanted to make the script branch independent, so I use "/feeds/luci.tmp/location" as the pointer to the respective Luci source. That complicates the line a bit:

touch -t `date "+%Y%m%d%H00"` `cat feeds/luci.tmp/location`/../../modules/admin-core/root/etc/init.d/luci_fixtime

From now on, my firmware will have the build date and hour as the initial system date after a flash.

Trunk r33667: First build of the newly renamed "Barrier Breaker" trunk. Still almost identical to the Attitude Adjustment branch.

(Last edited by hnyman on 8 Oct 2012, 20:04)

Hi
I can't download / opdate opkg more, other that have the same problem ??.

I get this message:
Downloading http://downloads.openwrt.org/snapshots/ … ckages.gz.
wget: server returned error: HTTP/1.1 404 Not Found
Collected errors:
* opkg_download: Failed to download http://downloads.openwrt.org/snapshots/ … ckages.gz, wget returned 1.

That problem concerns all users. There was a major RAID problem at Openwrt servers a week ago, and the snapshot builds have not yet been fixed after that. Opkg uses those as the package source dir.

I have updated the Attitude Adjustment 12.09 build (r33897) to match the beta2 released today.
See http://koti.welho.com/hnyman1/Openwrt

The build fetches packages from the beta2 packages repository.

(Last edited by hnyman on 26 Oct 2012, 16:08)

hnyman -- would you please be so kind as to build, just one, fully NFS enabled WNDR3700(v2) version against Attitude Attachment, once it becomes stable? I missed your last NFS build b/c I was on vacation, and on Mac OS X 10.8, I have never been able to build a version on my own. Such a AA build would enable me to restructure the network services in my LAN, and make it possible to use any AA package. If it should be impossible for you, please just disregard this message.

It might be possible. Do you mean just NFS client functionality, or are you looking also for NFS server functionality?

With NFS client functionality, I could move services like minidlna (and others) from my super-busy NAS system to the almost-idle OpenWRT router, which would be really helpful. On the other hand, a NFS server wouldn't hurt, although I haven't thought about possible uses yet.

I included NFS client support in my current r34013 build of Attitude Adjustment.
(I am not sure if the feature will be permanent, but is there at least for that build...)

With some "--force-depends", it was even possible to install the NFS kernel server here, just in case. Most excellent, I sure do appreciate it!! Thank you so much.

For those of us who don't want file services on our router, this is undesirable. Perhaps the nfs_kmod could be an installable option. And, nfs-utils already is, so does not need to be built-in.

I don't need it myself, so most likely I will remove it again for the next build. It increases the flash size by 200 kB and although this impact is negligible for 3700v2/3800, it decreases the available free flash size in 3700v1 by 10% :-(