Odd iPhone DHCP behavior.

I'm getting strange ARP/DHCP behavior with an iphone on a local network. The output from arpwatch (on a linux system) shows:
May 14 12:23:43 milonga arpwatch: bogon 0.0.0.0 0:1b:63<protected> eth0
May 14 12:23:44 milonga arpwatch: bogon 0.0.0.0 0:1b:63<protected> eth0
May 14 12:23:44 milonga arpwatch: bogon 0.0.0.0 0:1b:63<protected> eth0
May 14 12:23:44 milonga arpwatch: bogon 169.254.14.<number> 0:1b:63<protected> eth0
May 14 12:23:45 milonga arpwatch: bogon 169.254.14.<number> 0:1b:63<protected> eth0
May 14 12:23:46 milonga arpwatch: bogon 0.0.0.0 0:1b:63<protected> eth0
May 14 12:23:46 milonga arpwatch: bogon 0.0.0.0 0:1b:63<protected> eth0
May 14 12:23:47 milonga arpwatch: bogon 0.0.0.0 0:1b:63<protected> eth0
May 14 12:23:47 milonga arpwatch: new station 192.168.<number> 0:1b:63<protected> eth0
May 14 12:23:48 milonga arpwatch: bogon 169.254.14.<number> 0:1b:63<protected> eth0
May 14 12:24:51 milonga arpwatch: bogon 0.0.0.0 0:1b:63<protected> eth0
May 14 12:24:52 milonga arpwatch: bogon 0.0.0.0 0:1b:63<protected> eth0
May 14 12:24:52 milonga arpwatch: bogon 0.0.0.0 0:1b:63<protected> eth0
May 14 12:24:53 milonga arpwatch: bogon 169.254.14.<number> 0:1b:63<protected> eth0
May 14 12:24:53 milonga arpwatch: bogon 169.254.14.<number> 0:1b:63<protected> eth0
May 14 12:24:54 milonga arpwatch: bogon 0.0.0.0 0:1b:63<protected> eth0
May 14 12:24:55 milonga arpwatch: bogon 0.0.0.0 0:1b:63<protected> eth0
May 14 12:24:55 milonga arpwatch: bogon 0.0.0.0 0:1b:63<protected> eth0
May 14 12:24:55 milonga arpwatch: new station 192.168.<number> 0:1b:63<protected> eth0
May 14 12:24:56 milonga arpwatch: bogon 169.254.14.<number> 0:1b:63<protected> eth0
As you can see, the iPhone seems to get several DHCP addresses in a very short time and go to a self-assigned number in between. Does anyone know of a reason for this behavior? It knows about the network (which is using WPA) and the network limits access to known MAC addresses (this one is allowed).
This seems to cause problems with internal routing on the network (not sure what that might be). The DHCP server is a SonicWall firewall.

Yes, I've noticed this; it seems to initially broadcast, then switch over the previously assigned address. You wouldn't happen to be using WDS would you?
The only thing I've been able to figure out is that if it sees both wireless access points it seems to ARP on both, select the one with the stronger strength, and then attach to it.
You can backtrack on this by assigning a DHCP client ID and watching your logs. You'll notice it only supplies the Client ID to the station with the strongest signal strength. This seems to be a real problem if you have two in range and one is "borderline" and flutters in and out of range.
To workaround, assuming you are using WDS and have a central DHCP server, you can reserve an IP for the phone -- so even when the fluttering is happening it will always get the same IP for the MAC address.

Similar Messages

  • Odd iPhone Calendar Behavior With CSV Calendar Dates After 3.1

    In April I downloaded the Chicago Cubs schedule as a CSV file and imported it into Outlook. The dates synced to my (and my wife's) 3G phones via MobileMe and we were good to go. Yesterday I did the same with the Chicago Bears schedule, and just noticed that BOTH the Bears games AND the Cubs games are showing five hour late on our iPhone calendars (i.e., today's 3:15 CDT Bears game shows an 8:15 p.m. CDT start time on our phones). This appears to have happened after upgrading to 3.1. The times are correct in Outlook, and they are also correct on the calendar at mobileme.com.
    FWIW, I factory reset my phone this week and started over (did not restore the backup) in a failed attempt to correct the numerous 3.1 issues. I also verified that both phones have the correct timezone settings in BOTH locations in settings, and also confirmed the time zone settings in my PC and at mobileme.com. I also tried setting a normal (not imported from a CSV file) appointment in Outlook to test this problem, and both phones report the correct start time.

    I'm seeing the same instability with the calendar app. I first noticed all my mobile me calendars were gone so I backed up my iCal on my desktop and then synced the desktop with mobile me which took a few tries. This restored my iPhone calendar but it's been buggy ever since. I'm going to try a restore and if that doesn't help I'll go back to syncing through iTunes. I've also noticed some lag and crashes with other apps (apple & third party) since the 3.1 upgrade.

  • Odd Calc Order Behavior

    Hello all,
    I've put together a hybrid analysis cube and I'm experiencing some odd calc order behavior. It appears the years are calculating backwards.
    I load my 2007 end balances and calc forward three years. 2008 is correct, but 2009 and 2010 are incorrect. They are incorrect inasmuch as the calcs that require 2008/2009 end balances are incorrect. So I run the script again and now 2009 is right, but 2010 is incorrect. Then I run it once more and 2010 is correct.
    It appears the end balances for 2008 and 2009 aren't available for 2009 and 2010, respectively. Thus, I think 2010 is calcing first, but with no 2009 end bals, so it's off. Then 2009 goes, again no end bals, so it's off. Then 2008 calcs, and since 2007 end bals are in there, it's calcing correctly. Thus, I have to calc again two times for 2009 and 2010 to be correct.
    Here's my script:
    Fix (@IRSiblings("2008"),"ScenarioMbr")
    CALC ALL EXCEPT DIM("Years","Scenario");
    Endfix
    ScenarioMbr is a level 0 descendant of the Scenario dimension.
    Thanks for any help anyone has.

    I would suggest checking on your outline order. It sounds like your ending balance hasn't been calculated by the time the beginning balance needs it (as evidenced by your three passes). The order of members in your FIX statement has no bearing on the calculation order. By this, I mean make sure that your Years dimension is ordered as follows...
    Years
    + 2007
    + 2008
    + 2009
    + 2010
    Also, make sure that your periods (where your months are is, assuming it is a different dimension) is located above your Years dimension.
    Lastly, how are you facilitating getting your Ending balances into your Beginning balances? Sometimes the sequencing for this type of work is improtant as well. For example, if your Ending Balance is a two-pass, it will not be ready until a second pass is done.
    IF this doesn't help, maybe provide one of the BegBal members that isn't working, your outline order, the order of the Years dimension, and the dense/sparse settings (assuming BSO).
    Good Luck!!

  • Odd Junk Mail Behavior

    I've been experiencing odd Junk Mail behavior on my Mac; I've got the Mail app set so it puts the emails it thinks is Junk in the Junk folder. I do this because I've noticed that certain legitimate emails keep ending up in the Junk folder automatically.
    I've also noticed that some of the emails in the Junk folder have not actually been flagged as Junk Mail, they were not colored brown by the Junk Mail rule and there is no button available to tell Mail it's not Junk. How do I stop Mail from flagging something as Junk when it doesn't seem to tag it as Junk but it still ends up in the Junk folder?
    I see emails tagged as Junk in the Junk folder that are legit, so I click the "Not Junk" button and move them back to the proper mail folder. But the next time I get mail from the same source, it gets flagged and tagged as Junk again. I thought the Mail app learns from the training we give it. How do I resolve this situation?
    I've already set the Junk filtering to not filter emails from recipients who are in my Address Book.

    Either you’ve messed with the Preferences > Junk Mail > Advanced settings, or those settings have become corrupt, or you have one or more rules that have a bearing on this.
    Assuming it isn’t the latter, try this:
    1. Go to Preferences > Junk Mail, disable junk mail filtering, then enable it again. This resets the rule that governs what the junk filter does.
    2. Choose either Training or Automatic mode (it doesn’t matter) and leave the other options checked. Click Advanced to see how the junk filter rule is defined now if you want, but don’t touch anything there.
    3. Reset the junk filter database (Preferences > Junk Mail > Reset).

  • Odd Exchange notes behavior

    I'm trying to get access to Notes from Microsoft Exchange on my iPhone 2g with the 2.0 firmware, but am noticing some odd behavior.
    The phone is set to receive push email from my work Exchange webmail server. It is currently sending and receiving emails just fine. However, if I create a note on a desktop running Outlook and then tell the phone to sync the notes folder (which it sees), nothing shows up.
    On the other hand, if I send myself an email to the same account, then move the message into the notes folder via the iPhone, the messages will appear in the notes folder on both the device and the Outlook client.
    But if I move that same email via the Outlook client and sync the folder on the iPhone, the email will not show up. Am I missing something?

    Either you’ve messed with the Preferences > Junk Mail > Advanced settings, or those settings have become corrupt, or you have one or more rules that have a bearing on this.
    Assuming it isn’t the latter, try this:
    1. Go to Preferences > Junk Mail, disable junk mail filtering, then enable it again. This resets the rule that governs what the junk filter does.
    2. Choose either Training or Automatic mode (it doesn’t matter) and leave the other options checked. Click Advanced to see how the junk filter rule is defined now if you want, but don’t touch anything there.
    3. Reset the junk filter database (Preferences > Junk Mail > Reset).

  • Odd Camera Shifting Behavior

    I have the iPhone 5. I notce an odd behavior with Apple's Camera app. When I start off taking pictures, the app behaves fine. But later on when I frame the image that I would like to take a photo of, just as I press the shutter button, the Camera app shifts the image about 1/4+ inch (on screen) to the right and takes a picture of that. It will keep doing this until I restart the phone, then everything is fine again.
    Has anyone experience this before with their iPhone?

    Either you’ve messed with the Preferences > Junk Mail > Advanced settings, or those settings have become corrupt, or you have one or more rules that have a bearing on this.
    Assuming it isn’t the latter, try this:
    1. Go to Preferences > Junk Mail, disable junk mail filtering, then enable it again. This resets the rule that governs what the junk filter does.
    2. Choose either Training or Automatic mode (it doesn’t matter) and leave the other options checked. Click Advanced to see how the junk filter rule is defined now if you want, but don’t touch anything there.
    3. Reset the junk filter database (Preferences > Junk Mail > Reset).

  • E1200 odd roque DHCP server problem

    My local network connected to AT&T Uverse has both len and wiress connections.  with some devices specified in the DHCP reservations list.  all has worked fine for a while now. the UVerse modems do not support DHCP reservation configurations.
    last weekend, one of my Linux machines (in the DHCP reservation list) suddenly changed its address from 192.168.2.34 (dhcp server at 192.168.2.1 as confgured) to 192.168.1.105 (dhcp server at 192.168.1.251). I couldn't find the second DHCP server, and eventually put iptables on my linux box to drop packets from that server and get back up and running..  spent sat/sunday fixing this.
    Monday it happened again!.. even tho the iptables was still set to drop the packets!.. I found a dhcp roque utility for windows and started isolating parts of my network til I was down to two machines.. one windows and the E1200.
    I ended up using the admin UI on the E1200 to restore the router to default and reconfigure back to operation, and the rogue DHCP server is gone!... I did NOT try to power off/on the router.  
    I do not know how this happened. Altho the E1200 was in the UVerse modem DMZ (so I could get DDNS to work) , I changed the userid and password, did not have wireless admin access or Wan admin acces enabled. It seems 'unlikely' that the router had been hacked, but I have no other explanation unless there is a pretty serious firmware bug. I have found other reports of similar behavior on other vendors routers, which seem to be caused by a loss of the wan link AND having DHCP reservation machines.
    I have not tried to recreate the scenario. any ideas welcomed.

    config
    ATT Pace modem, DHCP on, wireless on, address range 192.168.1.2- 192.168.1.40, dhcp server at 192.1.1
    ethernet cable from ATT modem to 1200 'wan' port.
    1200 DCHP on, base address 192.168.2.1, dhcp range 192.168.2.2-192.168.2.200, wireless on
    out of E1200
    ethernet to local machine
    ethernet to Insteon automation hub
    ethernet to 4 port ethernet switch on other side of room
       switch to local windows machine (dhcp reservation address 192.168.2.106)
       switch to back of Dlink 1522 Access point, providing wireless to TV, Blueray player and roku box, access point address 192.168.2.5 in E1200 DHCP reservations list. DHCP off on 1522
          back of dlink (4 port switch) ethernet to linux machine. 2 ft away.
          back of dlink (4 port switch) to NAS storage device.
    Brother multi-function laser configured fixed address Wirless to 1200 (192.168.2.195), need wireless for tablet/iphone/ipad print support.
    so we have 1 ethernet network, and 3 wifi networks. (all 2.4mhz)
    (my dauther and son-in-law here as they move back to local area from Chicago, have connectivity issues with wireless on 1200, due to house walls, not so much on UVerse modem.  1522 dedicated to entertainment systems.
    Only the ethernet connected Linux box experienced this dhcp problem.
    the roque dhcp server was at 192.168.1.251, and provided ip address 192.168.1.105
    note that AT&T DHCP is 192.168.1.255

  • Nexus 5000 - Odd Ethernet interface behavior (link down inactive)

    Hi Guys,
    This would sound really trivial but it is very odd behavior.
    - We have a server connected to a 2, Nexus 5000s (for resiliancy)
    - When there is no config on the ethernet interfaces whatsoever, the ethernet interface is UP / UP, there is minimal amount of traffic on the link etc. E.g.
    Ethernet1/16 is up
      Hardware: 1000/10000 Ethernet, address: 000d.ece7.85d7 (bia 000d.ece7.85d7)
      Description: shipley-p1.its RK14/A13
      MTU 1500 bytes, BW 10000000 Kbit, DLY 10 usec,
         reliability 255/255, txload 1/255, rxload 1/255
      Encapsulation ARPA
      Port mode is access
      full-duplex, 10 Gb/s, media type is 1/10g
      Beacon is turned off
      Input flow-control is off, output flow-control is off
      Rate mode is dedicated
      Switchport monitor is off
      Last link flapped 00:00:07
      Last clearing of "show interface" counters 05:42:32
      30 seconds input rate 0 bits/sec, 0 packets/sec
      30 seconds output rate 96 bits/sec, 0 packets/sec
      Load-Interval #2: 5 minute (300 seconds)
        input rate 0 bps, 0 pps; output rate 8 bps, 0 pps
      RX
        0 unicast packets  0 multicast packets  0 broadcast packets
        0 input packets  0 bytes
        0 jumbo packets  0 storm suppression packets
        0 runts  0 giants  0 CRC  0 no buffer
        0 input error  0 short frame  0 overrun   0 underrun  0 ignored
        0 watchdog  0 bad etype drop  0 bad proto drop  0 if down drop
        0 input with dribble  0 input discard
        0 Rx pause
      TX
        0 unicast packets  163 multicast packets  0 broadcast packets
        163 output packets  15883 bytes
        0 jumbo packets
        0 output errors  0 collision  0 deferred  0 late collision
        0 lost carrier  0 no carrier  0 babble
        0 Tx pause
      1 interface resets
    - As soon as I configure the link to be an access port, the link goes down, flagging "inactivity" E.g.
    sh int e1/16
    Ethernet1/16 is down (inactive)
      Hardware: 1000/10000 Ethernet, address: 000d.ece7.85d7 (bia 000d.ece7.85d7)
      Description: shipley-p1.its RK14/A13
      MTU 1500 bytes, BW 10000000 Kbit, DLY 10 usec,
         reliability 255/255, txload 1/255, rxload 1/255
      Encapsulation ARPA
      Port mode is access
      auto-duplex, 10 Gb/s, media type is 1/10g
      Beacon is turned off
      Input flow-control is off, output flow-control is off
      Rate mode is dedicated
      Switchport monitor is off
      Last link flapped 05:38:03
      Last clearing of "show interface" counters 05:41:33
      30 seconds input rate 0 bits/sec, 0 packets/sec
      30 seconds output rate 0 bits/sec, 0 packets/sec
      Load-Interval #2: 5 minute (300 seconds)
        input rate 0 bps, 0 pps; output rate 0 bps, 0 pps
      RX
        0 unicast packets  0 multicast packets  0 broadcast packets
        0 input packets  0 bytes
        0 jumbo packets  0 storm suppression packets
        0 runts  0 giants  0 CRC  0 no buffer
        0 input error  0 short frame  0 overrun   0 underrun  0 ignored
        0 watchdog  0 bad etype drop  0 bad proto drop  0 if down drop
        0 input with dribble  0 input discard
        0 Rx pause
      TX
        0 unicast packets  146 multicast packets  0 broadcast packets
        146 output packets  13083 bytes
        0 jumbo packets
        0 output errors  0 collision  0 deferred  0 late collision
        0 lost carrier  0 no carrier  0 babble
        0 Tx pause
      0 interface resets
    - This behavior is seen on both 5Ks
    - I've tried using a different set of ports, changed SFPs, and fibre cabling to no avail
    - I can't seem to understand this behavior?!  In that, why would configuring the port cause the link to go down?
    - If anyone has experience this before, or could shed some light on this behavior, it would be appreciated.
    sh ver
    Cisco Nexus Operating System (NX-OS) Software
    TAC support: http://www.cisco.com/tac
    Copyright (c) 2002-2010, Cisco Systems, Inc. All rights reserved.
    The copyrights to certain works contained herein are owned by
    other third parties and are used and distributed under license.
    Some parts of this software are covered under the GNU Public
    License. A copy of the license is available at
    http://www.gnu.org/licenses/gpl.html.
    Software
      BIOS:      version 1.2.0
      loader:    version N/A
      kickstart: version 4.2(1)N1(1)
      system:    version 4.2(1)N1(1)
      power-seq: version v1.2
      BIOS compile time:       06/19/08
      kickstart image file is: bootflash:/n5000-uk9-kickstart.4.2.1.N1.1.bin
      kickstart compile time:  4/29/2010 19:00:00 [04/30/2010 02:38:04]
      system image file is:    bootflash:/n5000-uk9.4.2.1.N1.1.bin
      system compile time:     4/29/2010 19:00:00 [04/30/2010 03:51:47]
    thanks
    Sheldon

    I had identical issue
    Two interfaces on two different FEXes were INACTIVE. I have two Nexus 5596 in vPC and A/A FEXes.
    I also use config-sync feature.
    Very same configuration was applied to other ports on other FEXes and they were working with no problems.
    interface Ethernet119/1/1
      inherit port-profile PP-Exchange2003
    I checked VLAN status associated with this profile and it was active (of course it was, other ports were ok).
    I solved it by removing port profile from this port and re-applied it... voila, port changed state to up!
    Very very strange.

  • Odd Port 139 Behavior

    Hi everyone,
    I've been running in to some trouble with my university's IT department. They say that my Mac Mini (1.66GHz CoreDuo) has times when it's trying to connect to something via port 139 (netbios-ssn). They claim that it averages over 1 attempt per second. However, in all of my snooping, using Activity Monitor, Network Utility, and Little Snitch, I've never noticed anything odd. I do admit that I might not be observing it at the correct times, but I would like to get to the bottom of this. Currently my IT department has my computer "quarantined" and won't authorize it to access the network again until I can sort this out.
    Have any of you heard of something like this before (the 139 connection attempts)?
    Any help is GREATLY appreciated.
    Thanks,
    Dave DeLong

    At least for me, anytime I use a file dialog I get a message from little snitch telling me that it's trying to connect to port 139 - so any time I try to open or save a document, etc. Little Snitch tells me that the program I'm using is trying to connect via port 139.
    Same for when I try to choose a network printer.
    The snitch tells me about connect attempts over port 139 quite often, but not once per second.
    Finder is doubtless doing its own queries to "discover" what's out there on the network.
    I have a hard time believing it's even an issue, as every Mac, Linux, and Unix box that tries to connect to the windows shares on the network are going to have similar behavior. The Engineering department alone would be *+up in arms+* over such a policy. **** hath no fury like a few dozen EE students whose computers are banned.
    First because it's asinine - a connection attempt over port 139 is fairly innocent; you have to discover what's on the CIFS/SMB (ie. Windows shares) network somehow. Pretty much every non-Microsoft device (including Macs) that can access Windows shares uses "samba", which can be set to periodically ping the network to discover shares on the network. The whole point is so things "plug and play" without the IT manager having to do anything.
    SMB/CIFS is a very chatty protocol to begin with...

  • Odd battery/charge behavior

    Something odd happened today with my MBP (2011)...  I'm working away with it while it's plugged into power and all of a sudden it starts charging... but I never unplugged it or lost power or anything (and it's on a mondo UPS anyway).
    It's been showing 98% instead of 100%, but showing "fully charged" with a green light and from reading the articles from Apple this is totally normal.  I did manage to get it to show 100% after a SMC reset, but after a subsequent reboot it went back to 98%.  Anyway, it actually looks like it's going to charge to 100% now (99% and still showing orange light).
    Has anyone seen this behavior?  Normal?  Something to consider going to Apple store about?
    Thanks.

    I understand the system will charge when it needs to, but in all my days with MacBook's and the like I've never seen one up and start charging AFTER being plugged in for several days and without any provocation (i.e. unplugging it for a few minutes).
    My battery info all looks really good and the condition says "normal" so as long as "normal" is the same as "good" then it's probably fine.  Still odd, but fine.

  • Odd Smart Mailbox Behavior

    I receive a lot of mail with attachments so I created a Smart Mailbox with the following conditions -- ALL must be met:
    1. Contains Attachments
    2. Date Received is not in the last 2 weeks
    My goal is to keep my mail intact for 2 weeks, and then delete the attachments so I can save disk space.
    The Smart Mailbox works but not as I expected. I would assume that every day there would be at least one message that meets the conditions since I receive at least one attachment per day. What actually occurs is that the Smart Mailbox only shows mail every two weeks but some of the messages are older than two weeks -- as old as four weeks. The behavior seems odd to me.
    Any suggestions?
      Mac OS X (10.4.3)  

    If it's "not in the last 2 weeks" then it'll show messages older than the last 2 weeks. Do you want to show messages that are 2 weeks old? If yes, then change "not in the last 2 weeks" to "is exactly 2 weeks".

  • Odd file move behavior

    On my startup disk, I have a movie file (.mov) and a folder I want to collect movies in. Straightforward enough.
    So I click/drag the .mov file onto the folder. It shows me the green + icon, and when I let go, it COPIES the file into the folder, not by simply MOVING the file from the disktop to the folder. Wha?
    When I grab that same file in the folder and move it to the disktop, it works as expected, insisting that it must be DUPLICATED, replacing the disktop, original file.
    OK. So instead of doing that, I decide to trash the original file, then move the version out of the folder and back to the disktop.
    In order to do that, I use the contextual menu that drops down with Control+mouse click. It now asks me for my administrator password to do the trash move. (???)
    Once the original has been tossed, the file will now move from folder to disktop and back to folder with complete impunity. But if I try this with another .mov file, the process starts all over again.
    No extra key combo during the original move gets rid of the + icon.
    Permissions were repaired. No change.
    Log off was cycled, no change.
    Obviously somehow this disk has picked up wierdness when Leopard replaced well-tempered Tiger on it, but where is the checkbox that dumps this odd behavior?
    No Right-click on the mighty mouse will bring down the contextual menu at all.

    Yea! The Mac is back on track!
    It took extra innings and a visit to 1 800 APL CARE to get to the bottom of it, but this therapy should be on everyone's A-list: The Install disk's version of Disk Utility is significantly different from any version you can install on your hard drives. Or so it would appear.
    Where the Disk Utility can be there for you on two different hard drives connected to the same computer, running it from different drives is not at all the same - in visible results - as running it directly from the OS X Install Disk.
    You can have several disks with OS X on them and run Disk Utility on your main startup disk from those, but they won't find all the messy permissions that are gumming up your system.
    It took yet another previous back up Restore cycle, an extra clean install, followed immediately by an Install Disk run of Disk Utility's First Aid/Repair Disk Permissions to clear the cobwebs. Frequent re-weedings (after any program installs or upgrades from anybody, including Apple's own) finds more things to fix. Not always, but frequently.
    The Install Disk's Disk Utility--it's not just for breakfast any more.

  • Odd open with behavior

    Hi,
    Normally, when right-clicking a file, for example, a pdf, in ID, and selecting a particular program to open that file with (say, AI) would start the chosen program.  Lately, things haven't been working as expected, at least in one document.  Opening a linked file, either with the right-click on the file or from the links dock, results in some really odd behavior, all ending with the wrong program being chosen.  Sometimes, the program is in the list, for whatever reason ID decides that it should be in the list, which is a mystery to me, but sometimes, the program isn't even in the list.  Such as, my GIS program. I've tried another document, and it seems to behave ok.  I tried restarting the computer, etc., still happens.  Any suggestions?  Thanks for the time; you folks are always a tremendous help.
    PS, if I go to Bridge, everything is smooth, like butter.
    db

    I'm using CS4, all up to date on a Windows XP SP3 machine dual-core 2.66ghz  4gig RAM, 500 Gig HD.  The document itself is pretty low-key.  Five placed Word files.  I'm zapping the embedded images and replacing with linked originals.  Very basic graphics.  I'm an archaeologist, so mainly maps and photos, no transparencies, fancy masks, or anything of the like.
    Thanks,
    db

  • Odd edit box behavior

    I've seen some odd behavior today a couple times when I've tried to edit a message.
    The Edit box pops up but not with the text of the message I'm editing, but from an edit much earlier in the day.
    The first time it happened, I tried to make an edit, but it wouldn't submit it.  It just said there was an unknown error.
    The second time, it took the edit but had the old message body and message subject from a completely unrelated thread.
    EDIT:  I just went in to edit this message and all behaved just fine.
    Message Edited by Ravens Fan on 03-12-2009 01:11 PM

    Test post 
    derfglhjdflghjd lfghdlfghladhgldaghdfg
    derfglhjdflghjd lfghdlfghladhgldaghdfg
    derfglhjdflghjd lfghdlfghladhgldaghdfg
    derfglhjdflghjd lfghdlfghladhgldaghdfg
    derfglhjdflghjd lfghdlfghladhgldaghdfg
    derfglhjdflghjd lfghdlfghladhgldaghdfg
    derfglhjdflghjd lfghdlfghladhgldaghdfg
    derfglhjdflghjd lfghdlfghladhgldaghdfg
    derfglhjdflghjd lfghdlfghladhgldaghdfg
    derfglhjdflghjd lfghdlf
    derfglhjdflghjd lfghdlfghladhgldaghdfg
    derfglhjdflghjd lfghdlfghladhgldaghdfg
    derfglhjdflghjd lfghdlfghladhgldaghdfg
    derfglhjdflghjd lfghdlfghladhgldaghdfg
    derfglhjdflghjd lfghdlfghladhgldaghdfg
    derfglhjdflghjd lfghdlfghladhgldaghdfg
    derfglhjdflghjd lfghdlfghladhgldaghdfg
    derfglhjdflghjd lfghdlfghladhgldaghdfg
    derfglhjdflghjd lfghdlfghladhgldaghdfg
    derfglhjdflghjd lfghdlfghladhgldaghdfg
    derfglhjdflghjd lfghdlfghladhgldaghdfg
    derfglhjdflghjd lfghdlfghladhgldaghdfg
    derfglhjdflghjd lfghdlfghladhgldaghdfg
    derfglhjdflghjd lfghdlfghladhgldaghdfg
    derfglhjdflghjd lfghdlfghladhgldaghdfg
    derfglhjdflghjd lfghdlfghladhgldaghdfg
    derfglhjdflghjd lfghdlfghladhgldaghdfg
    derfglhjdflghjd lfghdlfghladhgldaghdfg
    derfglhjdflghjd lfghdlfghladhgldaghdfg
    derfglhjdflghjd lfghdlfghladhgldaghdfg
    derfglhjdflghjd lfghdlfghladhgldaghdfg
    derfglhjdflghjd lfghdlfghladhgldaghdfg
    derfglhjdflghjd lfghdlfghladhgldaghdfg
    derfglhjdflghjd lfghdlfghladhgldaghdfg
    derfglhjdflghjd lfghdlfghladhgldaghdfg
    derfglhjdflghjd lfghdlfghladhgldaghdfg
    derfglhjdflghjd lfghdlfghladhgldaghdfg
    derfglhjdflghjd lfghdlfghladhgldaghdfg
    derfglhjdflghjd lfghdlfghladhgldaghdfg
    derfglhjdflghjd lfghdlfghladhgldaghdfg
    ghladhgldaghdfg
    Test post 
    derfglhjdflghjd lfghdlfghladhgldaghdfg
    derfglhjdflghjd lfghdlfghladhgldaghdfg
    derfglhjdflghjd lfghdlfghladhgldaghdfg
    derfglhjdflghjd lfghdlfghladhgldaghdfg
    derfglhjdflghjd lfghdlfghladhgldaghdfg
    derfglhjdflghjd lfghdlfghladhgldaghdfg
    derfglhjdflghjd lfghdlfghladhgldaghdfg
    derfglhjdflghjd lfghdlfghladhgldaghdfg
    derfglhjdflghjd lfghdlfghladhgldaghdfg
    derfglhjdflghjd lfghdlf
    derfglhjdflghjd lfghdlfghladhgldaghdfg
    derfglhjdflghjd lfghdlfghladhgldaghdfg
    derfglhjdflghjd lfghdlfghladhgldaghdfg
    derfglhjdflghjd lfghdlfghladhgldaghdfg
    derfglhjdflghjd lfghdlfghladhgldaghdfg
    derfglhjdflghjd lfghdlfghladhgldaghdfg
    derfglhjdflghjd lfghdlfghladhgldaghdfg
    derfglhjdflghjd lfghdlfghladhgldaghdfg
    derfglhjdflghjd lfghdlfghladhgldaghdfg
    derfglhjdflghjd lfghdlfghladhgldaghdfg
    derfglhjdflghjd lfghdlfghladhgldaghdfg
    derfglhjdflghjd lfghdlfghladhgldaghdfg
    derfglhjdflghjd lfghdlfghladhgldaghdfg
    derfglhjdflghjd lfertertetertertghdlfghladhgldaghdfg
    derfglhjdflghjd lfghdlfghladhgldaghdfg
    derfglhjdflghjd lfghdlfghladhgldaghdfg
    derfglhjdflghjd lfghdlfghladhgldaghdfg
    derfglhjdflghjd lfghdlfghladhgldaghdfg
    derfglhjdflghjd lfghdlfghladhgldaghdfg
    derfglhjdflghjd lfghdlfghladhgldaghdfg
    derfglhjdflghjd lfghdlfghladhgldaghdfg
    derfglhjdflghjd lfghdlfghladhgldaghdfg
    derfglhjdflghjd lfghdlfghladhgldaghdfg
    derfglhjdflghjd lfghdlfghladhgldaghdfg
    derfglhjdflghjd lfghdlfghladhgldaghdfg
    derfglhjdflghjd lfghdlfghladhgldaghdfg
    derfglhjdflghjd lfghdlfghladhgldaghdfg
    derfglhjdflghjd lfghdlfghladhgldaghdfg
    derfglhjdflghjd lfghdlfghladhgldaghdfg
    derfglhjdflghjd lfghdlfghladhgldaghdfg
    ghladhgldaghdfg
    Test post 
    derfglhjdflghjd lfghdlfghladhgldaghdfg
    derfglhjdflghjd lfghdlfghladhgldaghdfg
    derfglhjdflghjd lfghdlfghladhgldaghdfg
    derfglhjdflghjd lfghdlfghladhgldaghdfg
    derfglhjdflghjd lfghdlfghladhgldaghdfg
    derfglhjdflghjd lfghdlfghladhgldaghdfg
    derfglhjdflghjd lfghdlfghladhgldaghdfg
    derfglhjdflghjd lfghdlfghladhgldaghdfg
    derfglhjdflghjd lfghdlfghladhgldaghdfg
    derfglhjdflghjd lfghdlf
    derfglhjdflghjd lfghdlfghladhgldaghdfg
    derfglhjdflghjd lfghdlfghladhgldaghdfg
    derfglhjdflghjd lfghdlfghladhgldaghdfg
    derfglhjdflghjd lfghdlfghladhgldaghdfg
    derfglhjdflghjd lfghdlfghladhgldaghdfg
    derfglhjdflghjd lfghdlfghladhgldaghdfg
    derfglhjdflghjd lfghdlfghladhgldaghdfg
    derfglhjdflghjd lfghdlfghladhgldaghdfg
    derfglhjdflghjd lfghdlfghladhgldaghdfg
    derfglhjdflghjd lfghdlfghladhgldaghdfg
    derfglhjdflghjd lfghdlfghladhgldaghdfg
    derfglhjdflghjd lfghdlfghladhgldaghdfg
    derfglhjdflghjd lfghdlfghladhgldaghdfg
    derfglhjdflghjd lfghdlfghladhgldaghdfg
    derfglhjdflghjd lfghdlfghladhgldaghdfg
    derfglhjdflghjd lfghdlfghladhgldaghdfg
    derfglhjdflghjd lfghdlfghladhgldaghdfg
    derfglhjdflghjd lfghdlfghladhgldaghdfg
    derfglhjdflghjd lfghdlfghladhgldaghdfg
    derfglhjdflghjd lfghdlfghladhgldaghdfg
    derfglhjdflghjd lfghdlfghladhgldaghdfg
    derfglhjdflghjd lfghdlfghladhgldaghdfg
    derfglhjdflghjd lfghdlfghladhgldaghdfg
    derfglhjdflghjd lfghdlfghladhgldaghdfg
    derfglhjdflghjd lfghdlfghladhgldaghdfg
    derfglhjdflghjd lfghdlfghladhgldaghdfg
    derfglhjdflghjd lfghdlfghladhgldaghdfg
    derfglhjdflghjd lfghdlfghladhgldaghdfg
    derfglhjdflghjd lfghdlfghladhgldaghdfg
    derfglhjdflghjd lfghdlfghladhgldaghdfg
    ghladhgldaghdfg
    Ben
    Ben Rayner
    I am currently active on.. MainStream Preppers
    Rayner's Ridge is under construction

  • Odd I/O behavior

    Again with the odd behavior. I found the code below while studying for a Java certification exam.
    ************************ START ************************
    import java.io.*;
    class OutputTest {
    public OutputTest() {
    super();
    public static void main(java.lang.String[] args) throws IOException {
    File file=new File("out");
    FileOutputStream fout1=new FileOutputStream(file);
    FileOutputStream fout2=new FileOutputStream(file);
    PrintWriter pw=new PrintWriter(fout1,true);
    fout1.write('A');
    fout2.write('B');
    pw.println("CD");
    fout1.close();
    fout2.close();
    pw.close();
    ************************ END ************************
    The contents of the file "out" after running this code is "BCD". Does anyone know why write access to one file is allowed by more than one output stream and/or writer? I assumed that the file would be locked when opened by fout1. Is this expected behavior?

    A guess on the behaviour.
    Both streams are buffered in java. fout1 writes to its buffer, fout2 writes to its buffer. When fout1 closes its buffer is flushed. When fout2 is closed its buffer is flushed which causes it to overwrite the stuff from fout1.
    Why it is allowed is a different matter. Perhaps because it is simply to hard to code or too expensive to check. Or simply forgotten. Or because sometimes this behaviour is desired - for example if both flush at the end of every line, then there is no problem.

Maybe you are looking for